Skip to main content
Legacy Enterprise Edition (Archived)

Extension management

Qoder CN provides extension management with support for custom commands to meet the extension needs of enterprise coding scenarios.
This feature is currently supported only for Visual Studio Code and JetBrains IDE plug-ins. It does not apply to Qoder CN IDE.
Applies to: Enterprise Standard Edition, Enterprise Dedicated Edition
Qoder CN admins and organization-wide global admins (Dedicated Edition) can manage custom commands and view related information and data in the Extension Management section of the Qoder CN console. Developers within the visibility scope of a custom command can see the commands they are authorized to use when they invoke commands with / in Qoder CN.
  • To use the enterprise-level custom command feature, make sure Qoder CN is upgraded to V1.4.0 or later.
  • After a command is enabled or modified, it takes about 5 to 10 minutes to take effect before developers can use it in Qoder CN.

Manage custom commands

View custom commands

Qoder CN admins and organization-wide global admins (Dedicated Edition) can log on to the Qoder CN console and click the Extension Management module on the left to view the created custom commands and official Qoder CN commands. The top of the Extension Management page provides a search box and a Create Command button. You can filter by the All, Custom Commands, and Official Commands tabs. Each command is displayed as a card that shows its name, description, number of users, and enabled/disabled status. Click a command card to enter the command details page, where you can view basic information about the command, the visibility scope of members, dialog configuration, and other information. You can also view usage data for the command.

Create a custom command

In Extension Management, click Create Command to enter the Create Custom Command page.

Step 1: Fill in basic information

  • Command name: the display name of the command. 1 to 64 characters. Chinese, English, and numbers are supported.
  • Command name (English): the English name of the command. 1 to 64 characters. Only uppercase and lowercase letters, digits, underscores, and spaces are allowed. This is the name that developers will see when they invoke the command with / in the Qoder CN chat window. Make sure it is standardized and readable.
  • Command description: within 200 characters. Describe the usage scenario and function of the command.
  • Command icon: the identification icon of the command. You can freely combine colors and icons.
  • Visibility scope of the command:
    • Public - all authorized developers in the enterprise: after selection, all developers who are authorized to use Qoder CN in the enterprise can use the command.
    • Private - available only to the command's visible members: after selection, you can add visible members after the command is created.

Step 2: Dialog configuration

For example, in the Prompt field, write the system prompt and output format requirements for a code-naming scenario (such as list length and naming rules). In Context Assembly, set both #userInput and #selectedCode to Required, and write an assembly template such as "Based on the requirements in #userInput, generate a variable name for #selectedCode." After the configuration is complete, click Create Now.
  • Prompt: within 5,000 characters. You can enter system identity prompts, requirement prompts, and so on.
  • Context assembly: currently provides #userInput and #selectedCode as context options, and supports prompt assembly design.
  • Include dialog history: after enabling this option, the current dialog context will be included when the command is triggered.

Set the availability scope

After a command is created, you can configure or modify the visibility scope on the command details page.
  • When the scope is Public - all authorized developers in the enterprise, click View to go to the Access Management page and view authorized developers.
  • When the scope is Private - available only to the command's visible members, clicking will open the visible members management drawer, where you can add or remove visible members. Note that only developers who are already authorized in Access Management can be added here.

Enable or disable a command

  • Make sure to enable the command so that developers within the availability scope can invoke it in Qoder CN.
  • After a command is enabled, it takes about 5 to 10 minutes to take effect before developers can use it in Qoder CN.
After a command is created, we recommend that you test it before enabling it for a large group of users. Refer to the following steps:
  1. Change the visibility scope of the command to Private - available only to the command's visible members.
  2. Add the command's visible members, adding only the developers who need to participate in testing.
  3. Turn on the enable switch of the command.
  4. Have the developers in the visibility scope test the command in Qoder CN.
After testing is complete, configure the availability scope based on the developers who need to use the command. When you need to disable a command, click the switch to turn it off. After it is disabled, developers will not see the command when they invoke commands with / in Qoder CN.

Modify command information and configuration

On the command details page, click the Modify button in the upper-right corner to modify command information.

Delete a command

On the command details page, click the Delete button in the upper-right corner. After you confirm, the command is deleted. This action cannot be undone. Proceed with caution.

Developers use commands

Developers within the visibility scope of a command can invoke it by entering / in the Qoder CN intelligent chat window. After invocation, the command list displays built-in commands (such as /explain code, /generate unit test, /generate comment) and custom commands (such as /dao, /generate api docs).

Scenario example

Custom command configuration

Command nameAutomatic generation of API development documentation
Command name (English)generate api docs
Command descriptionIn distributed systems and front-end/back-end separated architectures (SOA mode), requirement development is API-oriented. Therefore, after an API is developed, matching API documentation is required so that service consumers can quickly develop and perform joint debugging. This command helps developers quickly generate API development documentation.
Command iconSelect one as needed
Visibility scope of the commandSelect as needed
PromptYou are a Java expert with years of Java development experience and an expert in documentation writing. Based on the specified Spring MVC RestController code, and the comments available in the code and your understanding of the interface, generate an API document. Generate the corresponding API document according to the following template: Title: interface name. Type: API type (such as GET, POST, or PUT) and URL. Input parameters: a table with parameters in the first column, types in the second column, and descriptions in the third column. Output parameters: a table with parameters in the first column, types in the second column, and descriptions in the third column. Error codes: a table with error codes in the first column and error code descriptions in the second column.
Context assemblyGenerate an API interface document for the following code #selectedCode. The output format is markdown.

Usage example

Guides
Tutorials
  • Coding with Qoder CN
Developer Reference