generator-agent 1.0.7 → 1.0.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.vscode/extensions.json +8 -0
- package/.vscode/launch.json +17 -0
- package/.vscode-test.mjs +5 -0
- package/.vscodeignore +10 -0
- package/CHANGELOG.md +9 -0
- package/README.md +49 -43
- package/eslint.config.mjs +25 -0
- package/extension.js +36 -0
- package/jsconfig.json +13 -0
- package/package.json +32 -61
- package/test/extension.test.js +15 -0
- package/vsc-extension-quickstart.md +42 -0
- package/.agents/generators.json +0 -7
- package/.agents/generators.md +0 -19
- package/.github/agents/Generators.agent.md +0 -121
- package/.vscode/agents.json +0 -11
- package/.vscode/settings.json +0 -6
- package/Generator_Patterns/Conditional.md +0 -84
- package/Generator_Patterns/Dynamic.md +0 -129
- package/Generator_Patterns/PathConfig.properties +0 -4
- package/Generator_Patterns/README.md +0 -118
- package/Generator_Patterns/Reference.md +0 -98
- package/Generator_Patterns/Remote.md +0 -259
- package/Generator_Patterns/Static.md +0 -99
- package/NPM_PUBLISHING.md +0 -69
- package/generator-agent-1.0.0.vsix +0 -0
- package/main.js +0 -175
- package/post-install.js +0 -122
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
// A launch configuration that launches the extension inside a new window
|
|
2
|
+
// Use IntelliSense to learn about possible attributes.
|
|
3
|
+
// Hover to view descriptions of existing attributes.
|
|
4
|
+
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
|
|
5
|
+
{
|
|
6
|
+
"version": "0.2.0",
|
|
7
|
+
"configurations": [
|
|
8
|
+
{
|
|
9
|
+
"name": "Run Extension",
|
|
10
|
+
"type": "extensionHost",
|
|
11
|
+
"request": "launch",
|
|
12
|
+
"args": [
|
|
13
|
+
"--extensionDevelopmentPath=${workspaceFolder}"
|
|
14
|
+
]
|
|
15
|
+
}
|
|
16
|
+
]
|
|
17
|
+
}
|
package/.vscode-test.mjs
ADDED
package/.vscodeignore
ADDED
package/CHANGELOG.md
ADDED
package/README.md
CHANGED
|
@@ -1,59 +1,65 @@
|
|
|
1
|
-
#
|
|
1
|
+
# generator README
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
This is the README for your extension "generator". After writing up a brief description, we recommend including the following sections.
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## Features
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
```
|
|
10
|
-
bash :
|
|
7
|
+
Describe specific features of your extension including screenshots of your extension in action. Image paths are relative to this README file.
|
|
11
8
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
cd Generator-Agent
|
|
15
|
-
|
|
16
|
-
```
|
|
9
|
+
For example if there is an image subfolder under your extension project workspace:
|
|
17
10
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
- Press `Ctrl+Shift+P`
|
|
21
|
-
- Type "Reload Window" and press Enter
|
|
11
|
+
\!\[feature X\]\(images/feature-x.png\)
|
|
22
12
|
|
|
23
|
-
|
|
13
|
+
> Tip: Many popular extensions utilize animations. This is an excellent way to show off your extension! We recommend short, focused animations that are easy to follow.
|
|
24
14
|
|
|
25
|
-
|
|
26
|
-
2. Select the "Generators" agent.
|
|
27
|
-
3. Start prompting.
|
|
15
|
+
## Requirements
|
|
28
16
|
|
|
29
|
-
|
|
17
|
+
If you have any requirements or dependencies, add a section describing those and how to install and configure them.
|
|
18
|
+
|
|
19
|
+
## Extension Settings
|
|
20
|
+
|
|
21
|
+
Include if your extension adds any VS Code settings through the `contributes.configuration` extension point.
|
|
22
|
+
|
|
23
|
+
For example:
|
|
24
|
+
|
|
25
|
+
This extension contributes the following settings:
|
|
26
|
+
|
|
27
|
+
* `myExtension.enable`: Enable/disable this extension.
|
|
28
|
+
* `myExtension.thing`: Set to `blah` to do something.
|
|
29
|
+
|
|
30
|
+
## Known Issues
|
|
31
|
+
|
|
32
|
+
Calling out known issues can help limit users opening duplicate issues against your extension.
|
|
33
|
+
|
|
34
|
+
## Release Notes
|
|
35
|
+
|
|
36
|
+
Users appreciate release notes as you update your extension.
|
|
37
|
+
|
|
38
|
+
### 1.0.0
|
|
39
|
+
|
|
40
|
+
Initial release of ...
|
|
41
|
+
|
|
42
|
+
### 1.0.1
|
|
43
|
+
|
|
44
|
+
Fixed issue #.
|
|
45
|
+
|
|
46
|
+
### 1.1.0
|
|
30
47
|
|
|
31
|
-
|
|
32
|
-
- Dynamic generator
|
|
33
|
-
- Conditional generator
|
|
34
|
-
- Reference generator
|
|
35
|
-
- Remote generator
|
|
48
|
+
Added features X, Y, and Z.
|
|
36
49
|
|
|
37
|
-
|
|
50
|
+
---
|
|
38
51
|
|
|
39
|
-
|
|
52
|
+
## Working with Markdown
|
|
40
53
|
|
|
41
|
-
|
|
42
|
-
|------|--------|------------------------------------------------------|
|
|
43
|
-
| 1 | Install| Follow the Quick Install steps |
|
|
44
|
-
| 2 | Setup | Copy `.github/agents` folder to your project root |
|
|
45
|
-
| 3 | Open | Launch GitHub Copilot Chat in VS Code |
|
|
46
|
-
| 4 | Select | Choose "Generators" agent |
|
|
47
|
-
| 5 | Prompt | Start using the agent with your requests |
|
|
54
|
+
You can author your README using Visual Studio Code. Here are some useful editor keyboard shortcuts:
|
|
48
55
|
|
|
49
|
-
|
|
56
|
+
* Split the editor (`Cmd+\` on macOS or `Ctrl+\` on Windows and Linux)
|
|
57
|
+
* Toggle preview (`Shift+Cmd+V` on macOS or `Shift+Ctrl+V` on Windows and Linux)
|
|
58
|
+
* Press `Ctrl+Space` (Windows, Linux, macOS) to see a list of Markdown snippets
|
|
50
59
|
|
|
51
|
-
|
|
52
|
-
- **Reload Window**: `Ctrl+Shift+P` → "Reload Window"
|
|
53
|
-
- **Copilot Chat**: `Ctrl+Shift+I` (Open Copilot Chat panel)
|
|
60
|
+
## For more information
|
|
54
61
|
|
|
55
|
-
|
|
62
|
+
* [Visual Studio Code's Markdown Support](http://code.visualstudio.com/docs/languages/markdown)
|
|
63
|
+
* [Markdown Syntax Reference](https://help.github.com/articles/markdown-basics/)
|
|
56
64
|
|
|
57
|
-
|
|
58
|
-
2. Provide clear prompts for better generation results
|
|
59
|
-
3. Test generated output before using in production
|
|
65
|
+
**Enjoy!**
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
import globals from "globals";
|
|
2
|
+
|
|
3
|
+
export default [{
|
|
4
|
+
files: ["**/*.js"],
|
|
5
|
+
languageOptions: {
|
|
6
|
+
globals: {
|
|
7
|
+
...globals.commonjs,
|
|
8
|
+
...globals.node,
|
|
9
|
+
...globals.mocha,
|
|
10
|
+
},
|
|
11
|
+
|
|
12
|
+
ecmaVersion: 2022,
|
|
13
|
+
sourceType: "module",
|
|
14
|
+
},
|
|
15
|
+
|
|
16
|
+
rules: {
|
|
17
|
+
"no-const-assign": "warn",
|
|
18
|
+
"no-this-before-super": "warn",
|
|
19
|
+
"no-undef": "warn",
|
|
20
|
+
"no-unreachable": "warn",
|
|
21
|
+
"no-unused-vars": "warn",
|
|
22
|
+
"constructor-super": "warn",
|
|
23
|
+
"valid-typeof": "warn",
|
|
24
|
+
},
|
|
25
|
+
}];
|
package/extension.js
ADDED
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
// The module 'vscode' contains the VS Code extensibility API
|
|
2
|
+
// Import the module and reference it with the alias vscode in your code below
|
|
3
|
+
const vscode = require('vscode');
|
|
4
|
+
|
|
5
|
+
// This method is called when your extension is activated
|
|
6
|
+
// Your extension is activated the very first time the command is executed
|
|
7
|
+
|
|
8
|
+
/**
|
|
9
|
+
* @param {vscode.ExtensionContext} context
|
|
10
|
+
*/
|
|
11
|
+
function activate(context) {
|
|
12
|
+
|
|
13
|
+
// Use the console to output diagnostic information (console.log) and errors (console.error)
|
|
14
|
+
// This line of code will only be executed once when your extension is activated
|
|
15
|
+
console.log('Congratulations, your extension "generator" is now active!');
|
|
16
|
+
|
|
17
|
+
// The command has been defined in the package.json file
|
|
18
|
+
// Now provide the implementation of the command with registerCommand
|
|
19
|
+
// The commandId parameter must match the command field in package.json
|
|
20
|
+
const disposable = vscode.commands.registerCommand('generator.helloWorld', function () {
|
|
21
|
+
// The code you place here will be executed every time your command is executed
|
|
22
|
+
|
|
23
|
+
// Display a message box to the user
|
|
24
|
+
vscode.window.showInformationMessage('Hello World from Generator-Agent!');
|
|
25
|
+
});
|
|
26
|
+
|
|
27
|
+
context.subscriptions.push(disposable);
|
|
28
|
+
}
|
|
29
|
+
|
|
30
|
+
// This method is called when your extension is deactivated
|
|
31
|
+
function deactivate() {}
|
|
32
|
+
|
|
33
|
+
module.exports = {
|
|
34
|
+
activate,
|
|
35
|
+
deactivate
|
|
36
|
+
}
|
package/jsconfig.json
ADDED
package/package.json
CHANGED
|
@@ -1,63 +1,34 @@
|
|
|
1
1
|
{
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
6
|
-
|
|
7
|
-
"
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
"
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
"
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
"description": "Generator Agent responsible for generating generators",
|
|
35
|
-
"isSticky": true
|
|
36
|
-
}
|
|
37
|
-
]
|
|
38
|
-
},
|
|
39
|
-
"repository": {
|
|
40
|
-
"type": "git",
|
|
41
|
-
"url": "https://github.com/ishwaryaramesh200-byte/Generator-Agent.git"
|
|
42
|
-
},
|
|
43
|
-
"categories": [
|
|
44
|
-
"Other"
|
|
45
|
-
],
|
|
46
|
-
"keywords": [
|
|
47
|
-
"agent",
|
|
48
|
-
"generator",
|
|
49
|
-
"automation"
|
|
50
|
-
],
|
|
51
|
-
"galleryBanner": {
|
|
52
|
-
"color": "#C80000",
|
|
53
|
-
"theme": "dark"
|
|
54
|
-
},
|
|
55
|
-
"devDependencies": {
|
|
56
|
-
"@types/vscode": "^1.80.0",
|
|
57
|
-
"@vscode/vsce": "^3.7.1"
|
|
58
|
-
},
|
|
59
|
-
"publishConfig": {
|
|
60
|
-
"access": "public",
|
|
61
|
-
"registry": "https://registry.npmjs.org/"
|
|
62
|
-
}
|
|
2
|
+
"name": "generator-agent",
|
|
3
|
+
"displayName": "Generator-Agent",
|
|
4
|
+
"description": "Create a generator for given use case",
|
|
5
|
+
"version": "1.0.8",
|
|
6
|
+
"engines": {
|
|
7
|
+
"vscode": "^1.109.0"
|
|
8
|
+
},
|
|
9
|
+
"categories": [
|
|
10
|
+
"Other"
|
|
11
|
+
],
|
|
12
|
+
"activationEvents": [],
|
|
13
|
+
"main": "./extension.js",
|
|
14
|
+
"contributes": {
|
|
15
|
+
"commands": [{
|
|
16
|
+
"command": "generator.helloWorld",
|
|
17
|
+
"title": "Hello World"
|
|
18
|
+
}]
|
|
19
|
+
},
|
|
20
|
+
"scripts": {
|
|
21
|
+
"lint": "eslint .",
|
|
22
|
+
"pretest": "npm run lint",
|
|
23
|
+
"test": "vscode-test"
|
|
24
|
+
},
|
|
25
|
+
"publish": "npm publish --access public",
|
|
26
|
+
"devDependencies": {
|
|
27
|
+
"@types/vscode": "^1.109.0",
|
|
28
|
+
"@types/mocha": "^10.0.10",
|
|
29
|
+
"@types/node": "22.x",
|
|
30
|
+
"eslint": "^9.39.2",
|
|
31
|
+
"@vscode/test-cli": "^0.0.12",
|
|
32
|
+
"@vscode/test-electron": "^2.5.2"
|
|
33
|
+
}
|
|
63
34
|
}
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
const assert = require('assert');
|
|
2
|
+
|
|
3
|
+
// You can import and use all API from the 'vscode' module
|
|
4
|
+
// as well as import your extension to test it
|
|
5
|
+
const vscode = require('vscode');
|
|
6
|
+
// const myExtension = require('../extension');
|
|
7
|
+
|
|
8
|
+
suite('Extension Test Suite', () => {
|
|
9
|
+
vscode.window.showInformationMessage('Start all tests.');
|
|
10
|
+
|
|
11
|
+
test('Sample test', () => {
|
|
12
|
+
assert.strictEqual(-1, [1, 2, 3].indexOf(5));
|
|
13
|
+
assert.strictEqual(-1, [1, 2, 3].indexOf(0));
|
|
14
|
+
});
|
|
15
|
+
});
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Welcome to your VS Code Extension
|
|
2
|
+
|
|
3
|
+
## What's in the folder
|
|
4
|
+
|
|
5
|
+
* This folder contains all of the files necessary for your extension.
|
|
6
|
+
* `package.json` - this is the manifest file in which you declare your extension and command.
|
|
7
|
+
* The sample plugin registers a command and defines its title and command name. With this information VS Code can show the command in the command palette. It doesn’t yet need to load the plugin.
|
|
8
|
+
* `extension.js` - this is the main file where you will provide the implementation of your command.
|
|
9
|
+
* The file exports one function, `activate`, which is called the very first time your extension is activated (in this case by executing the command). Inside the `activate` function we call `registerCommand`.
|
|
10
|
+
* We pass the function containing the implementation of the command as the second parameter to `registerCommand`.
|
|
11
|
+
|
|
12
|
+
## Get up and running straight away
|
|
13
|
+
|
|
14
|
+
* Press `F5` to open a new window with your extension loaded.
|
|
15
|
+
* Run your command from the command palette by pressing (`Ctrl+Shift+P` or `Cmd+Shift+P` on Mac) and typing `Hello World`.
|
|
16
|
+
* Set breakpoints in your code inside `extension.js` to debug your extension.
|
|
17
|
+
* Find output from your extension in the debug console.
|
|
18
|
+
|
|
19
|
+
## Make changes
|
|
20
|
+
|
|
21
|
+
* You can relaunch the extension from the debug toolbar after changing code in `extension.js`.
|
|
22
|
+
* You can also reload (`Ctrl+R` or `Cmd+R` on Mac) the VS Code window with your extension to load your changes.
|
|
23
|
+
|
|
24
|
+
## Explore the API
|
|
25
|
+
|
|
26
|
+
* You can open the full set of our API when you open the file `node_modules/@types/vscode/index.d.ts`.
|
|
27
|
+
|
|
28
|
+
## Run tests
|
|
29
|
+
|
|
30
|
+
* Install the [Extension Test Runner](https://marketplace.visualstudio.com/items?itemName=ms-vscode.extension-test-runner)
|
|
31
|
+
* Open the Testing view from the activity bar and click the Run Test" button, or use the hotkey `Ctrl/Cmd + ; A`
|
|
32
|
+
* See the output of the test result in the Test Results view.
|
|
33
|
+
* Make changes to `test/extension.test.js` or create new test files inside the `test` folder.
|
|
34
|
+
* The provided test runner will only consider files matching the name pattern `**.test.js`.
|
|
35
|
+
* You can create folders inside the `test` folder to structure your tests any way you want.
|
|
36
|
+
|
|
37
|
+
## Go further
|
|
38
|
+
|
|
39
|
+
* [Follow UX guidelines](https://code.visualstudio.com/api/ux-guidelines/overview) to create extensions that seamlessly integrate with VS Code's native interface and patterns.
|
|
40
|
+
* [Publish your extension](https://code.visualstudio.com/api/working-with-extensions/publishing-extension) on the VS Code extension marketplace.
|
|
41
|
+
* Automate builds by setting up [Continuous Integration](https://code.visualstudio.com/api/working-with-extensions/continuous-integration).
|
|
42
|
+
* Integrate to the [report issue](https://code.visualstudio.com/api/get-started/wrapping-up#issue-reporting) flow to get issue and feature requests reported by users.
|
package/.agents/generators.json
DELETED
package/.agents/generators.md
DELETED
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
# Generators
|
|
2
|
-
|
|
3
|
-
You are a Generator Configuration Agent responsible for creating data generators based on specifications.
|
|
4
|
-
|
|
5
|
-
## Instructions
|
|
6
|
-
|
|
7
|
-
1. Read and understand generator patterns and type definitions
|
|
8
|
-
2. Create generators based on schemas and dependencies
|
|
9
|
-
3. Ensure all references are valid
|
|
10
|
-
4. Follow naming conventions
|
|
11
|
-
5. Use the correct generator type
|
|
12
|
-
|
|
13
|
-
## Capabilities
|
|
14
|
-
|
|
15
|
-
- Static generator creation
|
|
16
|
-
- Dynamic generator creation
|
|
17
|
-
- Conditional generator creation
|
|
18
|
-
- Reference generator creation
|
|
19
|
-
- Remote generator creation
|
|
@@ -1,121 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: GeneratorAgent
|
|
3
|
-
description: Creates generators using the OpenAPI specification and defined generator patterns. Ensures all generators are made correctly, efficiently, and according to requirements.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Role
|
|
7
|
-
Responsible for building generators that follow strict rules and guidelines based on OpenAPI and specified patterns.
|
|
8
|
-
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
## What to do
|
|
12
|
-
|
|
13
|
-
1. Read all generator type definitions in the Generator_Patterns folder to understand their rules and structures, then use them to create generators based on the OAS file’s schema and dependencies.
|
|
14
|
-
|
|
15
|
-
2. Analyze the user prompt to identify only the dependencies explicitly requested by the user. Do not add extra setup dependencies on your own.
|
|
16
|
-
|
|
17
|
-
3. For user-requested dependencies, ensure generators extract the required values from API responses so downstream generators can consume them clearly and correctly.
|
|
18
|
-
|
|
19
|
-
4. Always create a new generator file instead of modifying existing ones. If you need to modify or add to an existing generator, request explicit user permission before proceeding.
|
|
20
|
-
|
|
21
|
-
5. Refer to the `PathConfig.properties` file to find the paths for OAS files and existing generator files. Always use these paths when reading or referencing OAS or generator files.
|
|
22
|
-
|
|
23
|
-
6. Use only the dependencies explicitly provided in the user prompt. Do not include every parameter listed in the OAS, and do not auto-create additional dependency generators unless the user explicitly asks.
|
|
24
|
-
|
|
25
|
-
7. Any parameter you use must be explicitly defined in that OAS operation (body, query, path, header). Never invent fields, wrapper keys, or placeholders. Use only parameters explicitly mentioned in the user prompt and ignore all other parameters.
|
|
26
|
-
|
|
27
|
-
8. You may use tools if necessary to generate the generators correctly.
|
|
28
|
-
---
|
|
29
|
-
|
|
30
|
-
## Generator
|
|
31
|
-
|
|
32
|
-
1. Generator names must use snake_case (all lowercase, underscores), be clear, consistent, and meaningful, matching the resource and purpose. Use singular for single values (e.g., entity_id), plural for lists (e.g., entity_ids). All generator names must be unique and kept short and meaningful.
|
|
33
|
-
|
|
34
|
-
2. Maintain order in generator creation based on dependencies. If Generator A depends on Generator B, ensure that Generator B is created before Generator A.
|
|
35
|
-
|
|
36
|
-
3. Ensure that all generators strictly follow the definitions and rules specified in the generator type definition files.
|
|
37
|
-
|
|
38
|
-
4. Choose the correct generator type strictly according to its definition file.
|
|
39
|
-
|
|
40
|
-
5. For the "name" field inside a generator, use the resource name from PathConfig in snake_case: plural for lists, singular for single items (e.g., "resources", "resource", "records").
|
|
41
|
-
|
|
42
|
-
6. Follow exact reference syntax, dataPath format, and structural rules as defined in the type definition files and README.md.
|
|
43
|
-
|
|
44
|
-
7. Output must contain only the "generators" JSON object.
|
|
45
|
-
|
|
46
|
-
8. When using short-hand references like `$departments` or `$contacts`, ensure they reference generators defined in the same `test_data_generation_configurations.json` file unless the reference explicitly uses a relative cross-file path (for example `../Department/...`). This prevents accidental cross-file name collisions and keeps generated params local by default.
|
|
47
|
-
|
|
48
|
-
9. Operation ID format: Always specify `generatorOperationId` using the `<service>.<Entity>.<operation>` pattern (for example: "generatorOperationId": "support.Agent.getAgents").
|
|
49
|
-
|
|
50
|
-
10. When params are used in a dynamic generator, the parameter names should be the same as those defined in the OpenAPI specification.
|
|
51
|
-
|
|
52
|
-
11. If you use param input from body, query, path or header, please make sure the reference path is correct and the field exists in the OpenAPI specification. For example: "$.input.body:$.ticketId" for request body, "$.input.query:$.status" for query parameter, "$.input.path:$.agentId" for path parameter, "$.input.header:$.Authorization" for header.
|
|
53
|
-
|
|
54
|
-
12. If the same API with the same payload is needed more than once, call that API only once, store the entire response object, and extract all required values from that stored response.
|
|
55
|
-
|
|
56
|
-
13. When storing an entire object in a generator, the `dataPath` must use the `:$` format (for example: `$.response.body:$`).
|
|
57
|
-
|
|
58
|
-
---
|
|
59
|
-
|
|
60
|
-
## Generator Structure Rule
|
|
61
|
-
|
|
62
|
-
All generators must be created using the following structure:
|
|
63
|
-
|
|
64
|
-
```json
|
|
65
|
-
{
|
|
66
|
-
"generators": {
|
|
67
|
-
"<generator_name>": [
|
|
68
|
-
{}
|
|
69
|
-
]
|
|
70
|
-
}
|
|
71
|
-
}
|
|
72
|
-
```
|
|
73
|
-
|
|
74
|
-
- All dependencies for a generator must be included in the same array under the generator name.
|
|
75
|
-
- This ensures clarity, maintainability, and proper grouping of related generator steps.
|
|
76
|
-
- Generator name should be descriptive of the entity and purpose, following the snake_case convention.
|
|
77
|
-
---
|
|
78
|
-
|
|
79
|
-
## Generator Creation Rules
|
|
80
|
-
|
|
81
|
-
1. Create subfolder with PascalCase name (e.g., `CreateContact`, `CreateTicket`) in `Created_Generators` directory, add `test_data_generation_configurations.json` inside.
|
|
82
|
-
|
|
83
|
-
2. Only create the generator JSON file.
|
|
84
|
-
|
|
85
|
-
3. Always create new generator files instead of modifying existing ones. Request explicit permission before editing existing generators.
|
|
86
|
-
|
|
87
|
-
---
|
|
88
|
-
|
|
89
|
-
## Prompt Handling Rules
|
|
90
|
-
|
|
91
|
-
1. **Direct Prompt**: When user provides a direct prompt (e.g., "Create Contact", "Create Ticket"), implement the generator immediately without preamble like "Create generator for X".
|
|
92
|
-
|
|
93
|
-
2. **Explicit Request**: When user explicitly says "Create a generator for X" or similar, proceed as normal with full context.
|
|
94
|
-
|
|
95
|
-
3. **Skip Explanation**: For direct prompts, go straight to building the generator, no explanations.
|
|
96
|
-
|
|
97
|
-
4. **Clarify Ambiguity First**: If there is any confusion about which generator to use, which data to extract, or how required values should be sourced, ask the user first and generate only after confirmation.
|
|
98
|
-
|
|
99
|
-
5. **No Implicit Body Defaults**: For implied actions (for example, "add comments"), do not auto-fill request body fields that were not provided in the prompt. Ask the user for missing values first.
|
|
100
|
-
|
|
101
|
-
6. **Optional Param Choice**: In ambiguous enum/choice situations, ask the user with available options and include one extra option: **"Don't consider this param"**. If the user selects it, omit that parameter from the generator.
|
|
102
|
-
|
|
103
|
-
---
|
|
104
|
-
|
|
105
|
-
## Do Not:
|
|
106
|
-
|
|
107
|
-
1. Don't Invent new generator types or modify existing rules.
|
|
108
|
-
|
|
109
|
-
2. Don't modify or generate any section other than "generators" in the test_data_generation_configurations.json file.
|
|
110
|
-
|
|
111
|
-
3. Don't include explanations, comments, markdown, or extra text in the final output.
|
|
112
|
-
|
|
113
|
-
4. Don't edit OpenAPI specification files.
|
|
114
|
-
|
|
115
|
-
5. Never include any param or field in a generator unless it is explicitly defined in the OAS for that operation.
|
|
116
|
-
|
|
117
|
-
6. Don't auto-add setup generators (for example Contact/Department/Account) unless those dependencies are explicitly requested by the user.
|
|
118
|
-
|
|
119
|
-
7. Don't ask permission for read access to OAS or generator files, as you have full access to read any file in the specified paths.You have permission to read files outside of the workspace.
|
|
120
|
-
|
|
121
|
-
8. Don't give text response in chat window.Only output the generator JSON object as specified.
|
package/.vscode/agents.json
DELETED
package/.vscode/settings.json
DELETED
|
@@ -1,84 +0,0 @@
|
|
|
1
|
-
# CONDITIONAL Generator — Rule-Based Data Selection
|
|
2
|
-
|
|
3
|
-
---
|
|
4
|
-
|
|
5
|
-
## Overview
|
|
6
|
-
|
|
7
|
-
A **Conditional Generator** selects a data generator based on predefined conditions. It enables dynamic test data generation by evaluating input values or context and branching to different generator logic accordingly.
|
|
8
|
-
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
## When to Use
|
|
12
|
-
|
|
13
|
-
- When the value of a parameter depends on other input values or request context.
|
|
14
|
-
- To implement business rules, feature flags, or scenario-specific data.
|
|
15
|
-
- For fallback/default logic when no condition matches.
|
|
16
|
-
|
|
17
|
-
---
|
|
18
|
-
|
|
19
|
-
## Structure
|
|
20
|
-
|
|
21
|
-
A conditional generator contains:
|
|
22
|
-
- `type`: Must be `"conditional"`
|
|
23
|
-
- `conditions`: List of condition objects, each with:
|
|
24
|
-
- `when`: The condition to evaluate (key, operator, value)
|
|
25
|
-
- `then`: The generator or value to use if the condition matches
|
|
26
|
-
- `else`: (optional) The generator or value to use if no conditions match
|
|
27
|
-
|
|
28
|
-
---
|
|
29
|
-
|
|
30
|
-
## Example
|
|
31
|
-
|
|
32
|
-
```json
|
|
33
|
-
{
|
|
34
|
-
"generators": {
|
|
35
|
-
"snippet_id": [
|
|
36
|
-
{
|
|
37
|
-
"type": "conditional",
|
|
38
|
-
"conditions": [
|
|
39
|
-
{
|
|
40
|
-
"when": {
|
|
41
|
-
"key": "$.input.query:modules",
|
|
42
|
-
"equals": "tickets"
|
|
43
|
-
},
|
|
44
|
-
"then": {
|
|
45
|
-
"use": "$generators:#/generators/ticket_id"
|
|
46
|
-
}
|
|
47
|
-
},
|
|
48
|
-
{
|
|
49
|
-
"when": {
|
|
50
|
-
"key": "$.input.query:modules",
|
|
51
|
-
"equals": "contacts"
|
|
52
|
-
},
|
|
53
|
-
"then": {
|
|
54
|
-
"use": "$generators:#/generators/contact_id"
|
|
55
|
-
}
|
|
56
|
-
}
|
|
57
|
-
],
|
|
58
|
-
"else": "$generators:#/generators/activity_id"
|
|
59
|
-
}
|
|
60
|
-
]
|
|
61
|
-
}
|
|
62
|
-
}
|
|
63
|
-
```
|
|
64
|
-
|
|
65
|
-
---
|
|
66
|
-
|
|
67
|
-
## Best Practices
|
|
68
|
-
|
|
69
|
-
- Use input-based branching: reference request path, query, or body fields in `when`.
|
|
70
|
-
- Reference other generators in `then` using correct relative paths or `$generators:` syntax.
|
|
71
|
-
- Always provide an `else` clause if possible to avoid unexpected nulls.
|
|
72
|
-
- Keep conditions mutually exclusive and clear.
|
|
73
|
-
- Avoid deeply nested or overly complex chains for readability.
|
|
74
|
-
|
|
75
|
-
---
|
|
76
|
-
|
|
77
|
-
## Validation Checklist
|
|
78
|
-
|
|
79
|
-
- Ensure all referenced generators exist.
|
|
80
|
-
- Test each condition path for expected output.
|
|
81
|
-
|
|
82
|
-
---
|
|
83
|
-
|
|
84
|
-
*Last Updated: 17 February 2026*
|