@codemcp/workflows 6.2.1 → 6.3.0
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/package.json +2 -2
- package/packages/cli/dist/{cli-EMZS26KQ.js → cli-QV7U6L54.js} +29 -3
- package/packages/cli/dist/index.js +1 -1
- package/packages/cli/package.json +1 -1
- package/packages/cli/resources/templates/skills/application-design.md +29 -0
- package/packages/cli/resources/templates/skills/architecture.md +13 -0
- package/packages/cli/resources/templates/skills/coding.md +35 -0
- package/packages/cli/resources/templates/skills/starting-project.md +23 -0
- package/packages/cli/resources/templates/skills/task-handling.md +19 -0
- package/packages/cli/resources/templates/skills/testing.md +20 -0
- package/packages/cli/resources/workflows/bugfix.yaml +0 -13
- package/packages/cli/resources/workflows/skilled-bugfix.yaml +6 -14
- package/packages/cli/resources/workflows/skilled-epcc.yaml +7 -7
- package/packages/cli/resources/workflows/skilled-greenfield.yaml +6 -6
- package/packages/core/package.json +1 -1
- package/packages/core/resources/templates/skills/application-design.md +29 -0
- package/packages/core/resources/templates/skills/architecture.md +13 -0
- package/packages/core/resources/templates/skills/coding.md +35 -0
- package/packages/core/resources/templates/skills/starting-project.md +23 -0
- package/packages/core/resources/templates/skills/task-handling.md +19 -0
- package/packages/core/resources/templates/skills/testing.md +20 -0
- package/packages/core/resources/workflows/bugfix.yaml +0 -13
- package/packages/core/resources/workflows/skilled-bugfix.yaml +6 -14
- package/packages/core/resources/workflows/skilled-epcc.yaml +7 -7
- package/packages/core/resources/workflows/skilled-greenfield.yaml +6 -6
- package/packages/docs/.vitepress/dist/workflows/bugfix.yaml +0 -13
- package/packages/docs/.vitepress/dist/workflows/skilled-bugfix.yaml +6 -14
- package/packages/docs/.vitepress/dist/workflows/skilled-epcc.yaml +7 -7
- package/packages/docs/.vitepress/dist/workflows/skilled-greenfield.yaml +6 -6
- package/packages/docs/package.json +1 -1
- package/packages/mcp-server/package.json +1 -1
- package/packages/mcp-server/resources/templates/skills/application-design.md +29 -0
- package/packages/mcp-server/resources/templates/skills/architecture.md +13 -0
- package/packages/mcp-server/resources/templates/skills/coding.md +35 -0
- package/packages/mcp-server/resources/templates/skills/starting-project.md +23 -0
- package/packages/mcp-server/resources/templates/skills/task-handling.md +19 -0
- package/packages/mcp-server/resources/templates/skills/testing.md +20 -0
- package/packages/mcp-server/resources/workflows/bugfix.yaml +0 -13
- package/packages/mcp-server/resources/workflows/skilled-bugfix.yaml +6 -14
- package/packages/mcp-server/resources/workflows/skilled-epcc.yaml +7 -7
- package/packages/mcp-server/resources/workflows/skilled-greenfield.yaml +6 -6
- package/packages/visualizer/package.json +1 -1
- package/resources/templates/skills/application-design.md +29 -0
- package/resources/templates/skills/architecture.md +13 -0
- package/resources/templates/skills/coding.md +35 -0
- package/resources/templates/skills/starting-project.md +23 -0
- package/resources/templates/skills/task-handling.md +19 -0
- package/resources/templates/skills/testing.md +20 -0
- package/resources/workflows/bugfix.yaml +0 -13
- package/resources/workflows/skilled-bugfix.yaml +6 -14
- package/resources/workflows/skilled-epcc.yaml +7 -7
- package/resources/workflows/skilled-greenfield.yaml +6 -6
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@codemcp/workflows",
|
|
3
|
-
"version": "6.
|
|
3
|
+
"version": "6.3.0",
|
|
4
4
|
"description": "A Model Context Protocol server that acts as an intelligent conversation state manager and development guide for LLMs, featuring comprehensive long-term memory with persistent project artifacts",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "packages/cli/dist/index.js",
|
|
@@ -51,7 +51,7 @@
|
|
|
51
51
|
"typescript": "^5.9.3",
|
|
52
52
|
"vitepress": "^1.6.4",
|
|
53
53
|
"vitest": "4.0.18",
|
|
54
|
-
"@codemcp/workflows-core": "6.
|
|
54
|
+
"@codemcp/workflows-core": "6.3.0"
|
|
55
55
|
},
|
|
56
56
|
"lint-staged": {
|
|
57
57
|
"*.{ts,js,mts,cts,tsx,jsx}": [
|
|
@@ -370,9 +370,6 @@ var OpencodeConfigGenerator = class extends ConfigGenerator {
|
|
|
370
370
|
description: "Responsible vibe development agent with structured workflows",
|
|
371
371
|
mode: "primary",
|
|
372
372
|
prompt: systemPrompt,
|
|
373
|
-
tools: {
|
|
374
|
-
"workflows*": true
|
|
375
|
-
},
|
|
376
373
|
permission: {
|
|
377
374
|
workflows_reset_development: "ask",
|
|
378
375
|
workflows_start_development: "ask",
|
|
@@ -689,6 +686,29 @@ var SkillGenerator = class {
|
|
|
689
686
|
JSON.stringify(configContent, null, 2)
|
|
690
687
|
);
|
|
691
688
|
}
|
|
689
|
+
/**
|
|
690
|
+
* Copy all skill templates to the output directory
|
|
691
|
+
*/
|
|
692
|
+
async copySkillTemplates(outputDir) {
|
|
693
|
+
const skillTemplates = [
|
|
694
|
+
"starting-project.md",
|
|
695
|
+
"architecture.md",
|
|
696
|
+
"application-design.md",
|
|
697
|
+
"coding.md",
|
|
698
|
+
"testing.md",
|
|
699
|
+
"task-handling.md"
|
|
700
|
+
];
|
|
701
|
+
for (const template of skillTemplates) {
|
|
702
|
+
try {
|
|
703
|
+
const templatePath = this.resolveSkillTemplatePath(template);
|
|
704
|
+
const content = await readFile2(templatePath, "utf-8");
|
|
705
|
+
const outputPath = join4(outputDir, "skills", template);
|
|
706
|
+
await this.writeFile(outputPath, content);
|
|
707
|
+
} catch (error) {
|
|
708
|
+
console.warn(`\u26A0 Could not copy skill template ${template}: ${error}`);
|
|
709
|
+
}
|
|
710
|
+
}
|
|
711
|
+
}
|
|
692
712
|
/**
|
|
693
713
|
* Get the system prompt using existing generation logic
|
|
694
714
|
* Same approach as config-generator.ts
|
|
@@ -789,6 +809,7 @@ var ClaudeSkillGenerator = class extends SkillGenerator {
|
|
|
789
809
|
const skillContent = await this.getSkillTemplate();
|
|
790
810
|
await this.writeFile(paths.skillFile, skillContent);
|
|
791
811
|
await this.writeMcpConfig(paths);
|
|
812
|
+
await this.copySkillTemplates(outputDir);
|
|
792
813
|
}
|
|
793
814
|
};
|
|
794
815
|
var GeminiSkillGenerator = class extends SkillGenerator {
|
|
@@ -797,6 +818,7 @@ var GeminiSkillGenerator = class extends SkillGenerator {
|
|
|
797
818
|
const skillContent = await this.getSkillTemplate();
|
|
798
819
|
await this.writeFile(paths.skillFile, skillContent);
|
|
799
820
|
await this.writeMcpConfig(paths);
|
|
821
|
+
await this.copySkillTemplates(outputDir);
|
|
800
822
|
}
|
|
801
823
|
};
|
|
802
824
|
var OpenCodeSkillGenerator = class extends SkillGenerator {
|
|
@@ -805,6 +827,7 @@ var OpenCodeSkillGenerator = class extends SkillGenerator {
|
|
|
805
827
|
const skillContent = await this.getSkillTemplate();
|
|
806
828
|
await this.writeFile(paths.skillFile, skillContent);
|
|
807
829
|
await this.writeOpencodeMcpConfig(paths);
|
|
830
|
+
await this.copySkillTemplates(outputDir);
|
|
808
831
|
}
|
|
809
832
|
/**
|
|
810
833
|
* Write OpenCode-specific MCP configuration
|
|
@@ -834,6 +857,7 @@ var CopilotSkillGenerator = class extends SkillGenerator {
|
|
|
834
857
|
const skillContent = await this.getSkillTemplate();
|
|
835
858
|
await this.writeFile(paths.skillFile, skillContent);
|
|
836
859
|
await this.writeMcpConfig(paths);
|
|
860
|
+
await this.copySkillTemplates(outputDir);
|
|
837
861
|
}
|
|
838
862
|
};
|
|
839
863
|
var KiroSkillGenerator = class extends SkillGenerator {
|
|
@@ -842,6 +866,7 @@ var KiroSkillGenerator = class extends SkillGenerator {
|
|
|
842
866
|
const skillContent = await this.getPowerTemplate();
|
|
843
867
|
await this.writeFile(paths.skillFile, skillContent);
|
|
844
868
|
await this.writeKiroMcpConfig(paths);
|
|
869
|
+
await this.copySkillTemplates(outputDir);
|
|
845
870
|
}
|
|
846
871
|
/**
|
|
847
872
|
* Write Kiro-specific MCP configuration (command + args format)
|
|
@@ -861,6 +886,7 @@ var KiroCliSkillGenerator = class extends SkillGenerator {
|
|
|
861
886
|
const skillContent = await this.getSkillTemplate();
|
|
862
887
|
await this.writeFile(paths.skillFile, skillContent);
|
|
863
888
|
await this.writeKiroMcpConfig(paths);
|
|
889
|
+
await this.copySkillTemplates(outputDir);
|
|
864
890
|
}
|
|
865
891
|
/**
|
|
866
892
|
* Write Kiro-specific MCP configuration (command + args format)
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: application-design
|
|
3
|
+
description: General conventions when creating an application design
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
practices
|
|
7
|
+
|
|
8
|
+
# Application Design Conventions
|
|
9
|
+
|
|
10
|
+
**Organization:**
|
|
11
|
+
|
|
12
|
+
- Apply the Single Responsibility Principle
|
|
13
|
+
- Use packages with defined interfaces to apply open-close principle for components
|
|
14
|
+
|
|
15
|
+
**APIs:**
|
|
16
|
+
|
|
17
|
+
- Use RESTful conventions
|
|
18
|
+
- Handle 404s gracefully
|
|
19
|
+
|
|
20
|
+
**Validation:**
|
|
21
|
+
|
|
22
|
+
- Validate on client and server
|
|
23
|
+
- Provide immediate feedback
|
|
24
|
+
- Handle edge cases and malicious input
|
|
25
|
+
|
|
26
|
+
**Configurability**
|
|
27
|
+
|
|
28
|
+
- Only provide configurability if explicitly requested
|
|
29
|
+
- If needed, use the registry pattern
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architecture
|
|
3
|
+
description: General practices to consider when setting up a new application or enhancing it structurally
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Architecture conventions
|
|
7
|
+
|
|
8
|
+
**Organization:**
|
|
9
|
+
|
|
10
|
+
- SRP, separation of concerns, dependency injection
|
|
11
|
+
- Fail fast with clear error messages
|
|
12
|
+
- Use packages with defined interfaces to apply open-close principle for components
|
|
13
|
+
- Start with simple, testable components
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: coding
|
|
3
|
+
description: General practices to consider when writing code
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Coding conventions
|
|
7
|
+
|
|
8
|
+
**Code Quality:**
|
|
9
|
+
|
|
10
|
+
- Write self-documenting code with clear names. Prefer verbose names over comments
|
|
11
|
+
- Comment the intend (why), do not describe the code (how)
|
|
12
|
+
- KISS
|
|
13
|
+
- DRY
|
|
14
|
+
- Prefer simplicity (understandability over elegance)
|
|
15
|
+
|
|
16
|
+
**Error Handling:**
|
|
17
|
+
|
|
18
|
+
- Handle errors explicitly
|
|
19
|
+
- Use explicit error types
|
|
20
|
+
- Provide context in messages
|
|
21
|
+
- Use structured logging and debugger over console.log
|
|
22
|
+
|
|
23
|
+
**Performance:**
|
|
24
|
+
|
|
25
|
+
- Avoid premature optimization
|
|
26
|
+
- Use appropriate data structures
|
|
27
|
+
- Consider memory usage
|
|
28
|
+
- Profile before optimizing
|
|
29
|
+
|
|
30
|
+
**Security:**
|
|
31
|
+
|
|
32
|
+
- Follow OWASP security guidelines and dependency scanning
|
|
33
|
+
- Validate and sanitize inputs
|
|
34
|
+
- Use parameterized queries
|
|
35
|
+
- Never hardcode secrets
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: starting-project
|
|
3
|
+
description: How to set-up the skeleton of a new application
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Starting Project conventions
|
|
7
|
+
|
|
8
|
+
**Check existing structure:**
|
|
9
|
+
|
|
10
|
+
- Look for README.md, package.json, or project files
|
|
11
|
+
- Identify tech stack
|
|
12
|
+
|
|
13
|
+
**Setup patterns:**
|
|
14
|
+
|
|
15
|
+
- Set up gitignore and linting tools
|
|
16
|
+
- Create basic test structure with common framework
|
|
17
|
+
- Add standard build scripts and CI/CD templates
|
|
18
|
+
- Document setup and contribution guidelines
|
|
19
|
+
|
|
20
|
+
**Mandatory user interaction:**
|
|
21
|
+
|
|
22
|
+
- Ask the user for preferences on starter templates
|
|
23
|
+
- Before you write any package or launch a generator, ALWAYS present it to the user and wait for confirmation!
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: task-handling
|
|
3
|
+
description: Important conventions on how to author and work on tasks
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Task Writing Methodology
|
|
7
|
+
|
|
8
|
+
**SMART Tasks:**
|
|
9
|
+
|
|
10
|
+
- Use task description for SMART criteria
|
|
11
|
+
- Include all context for new team members
|
|
12
|
+
- Include instructions to research known sources of knowledge
|
|
13
|
+
- Specify dependencies and prerequisites
|
|
14
|
+
|
|
15
|
+
**Task Completion:**
|
|
16
|
+
|
|
17
|
+
- Record results and key findings when completing
|
|
18
|
+
- Document "how it was done" - methods, approaches, decisions
|
|
19
|
+
- Update plan file with key results in addition
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: testing
|
|
3
|
+
description: General practices when writing and executing tests
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Testing Best Practices
|
|
7
|
+
|
|
8
|
+
**Test Authoring:**
|
|
9
|
+
|
|
10
|
+
- Test behavior, not implementation
|
|
11
|
+
- Use testing pyramid (many unit, some integration, few E2E)
|
|
12
|
+
- Test edge cases and error conditions
|
|
13
|
+
- Keep tests simple and fast
|
|
14
|
+
|
|
15
|
+
**Test Organization:**
|
|
16
|
+
|
|
17
|
+
- Group related tests
|
|
18
|
+
- Use descriptive test names
|
|
19
|
+
- Follow AAA pattern (Arrange, Act, Assert)
|
|
20
|
+
- Keep test data minimal
|
|
@@ -40,19 +40,6 @@ states:
|
|
|
40
40
|
to: 'analyze'
|
|
41
41
|
transition_reason: 'Bug reproduced successfully, ready to analyze root cause'
|
|
42
42
|
|
|
43
|
-
- trigger: 'bug_not_reproducible'
|
|
44
|
-
to: 'reproduce'
|
|
45
|
-
instructions: >
|
|
46
|
-
Unable to reproduce the bug with current information. Gather more details about the environment,
|
|
47
|
-
conditions, or steps that might be missing. Contact the reporter for additional information if needed.
|
|
48
|
-
Continue attempting reproduction with new information.
|
|
49
|
-
transition_reason: 'Bug could not be reproduced, need more information'
|
|
50
|
-
|
|
51
|
-
- trigger: 'abandon_bug'
|
|
52
|
-
to: 'reproduce'
|
|
53
|
-
additional_instructions: 'Bug investigation abandoned. Clean up any reproduction work and prepare for new bug reports.'
|
|
54
|
-
transition_reason: 'Bug investigation abandoned'
|
|
55
|
-
|
|
56
43
|
analyze:
|
|
57
44
|
description: 'Analyze the bug and identify root cause'
|
|
58
45
|
default_instructions: Examine the code paths involved in the bug, identify the root cause, and understand why the issue occurs. Use debugging tools, add logging, and trace through the problematic code. Document your analysis and create tasks as needed.
|
|
@@ -39,21 +39,13 @@ states:
|
|
|
39
39
|
to: 'analyze'
|
|
40
40
|
transition_reason: 'Bug reproduced successfully, ready to analyze root cause'
|
|
41
41
|
|
|
42
|
-
- trigger: 'bug_not_reproducible'
|
|
43
|
-
to: 'reproduce'
|
|
44
|
-
instructions: >
|
|
45
|
-
Unable to reproduce the bug with current information. Gather more details about the environment,
|
|
46
|
-
conditions, or steps that might be missing. Contact the reporter for additional information if needed.
|
|
47
|
-
Continue attempting reproduction with new information.
|
|
48
|
-
transition_reason: 'Bug could not be reproduced, need more information'
|
|
49
|
-
|
|
50
42
|
analyze:
|
|
51
43
|
description: 'Analyze the bug and identify root cause'
|
|
52
44
|
default_instructions: |
|
|
53
45
|
Examine the code paths involved in the bug, identify the root cause, and understand why the issue occurs. Use debugging tools, add logging, and trace through the problematic code.
|
|
54
46
|
|
|
55
|
-
- Use
|
|
56
|
-
- Use
|
|
47
|
+
- Use your **architecture** skill if available, or ask the user about their architectural conventions
|
|
48
|
+
- Use your **application-design** skill if available, or ask the user about their application design practices
|
|
57
49
|
|
|
58
50
|
Document your analysis and create tasks as needed.
|
|
59
51
|
transitions:
|
|
@@ -83,8 +75,8 @@ states:
|
|
|
83
75
|
Implement the solution based on your analysis:
|
|
84
76
|
|
|
85
77
|
- Check whether there is a design document in the project and follow it
|
|
86
|
-
- Use
|
|
87
|
-
- Use
|
|
78
|
+
- Use your **coding** skill if available, or ask the user about their coding practices and patterns
|
|
79
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
88
80
|
|
|
89
81
|
Before implementing, assess the approach:
|
|
90
82
|
- How critical is this system? What is the blast radius if the fix causes issues?
|
|
@@ -117,7 +109,7 @@ states:
|
|
|
117
109
|
default_instructions: |
|
|
118
110
|
Test the fix thoroughly to ensure the original bug is resolved and no new issues were introduced.
|
|
119
111
|
|
|
120
|
-
- Use
|
|
112
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
121
113
|
- Verify the solution is robust and handles edge cases
|
|
122
114
|
transitions:
|
|
123
115
|
- trigger: 'fix_needs_adjustment'
|
|
@@ -162,7 +154,7 @@ states:
|
|
|
162
154
|
- Ask the user to review document updates
|
|
163
155
|
|
|
164
156
|
**STEP 3: Final Validation**
|
|
165
|
-
- Use
|
|
157
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
166
158
|
- Verify documentation accuracy with a final review
|
|
167
159
|
- Ensure bug fix is ready for production
|
|
168
160
|
- Update task progress and mark completed work as you finalize the bug fix
|
|
@@ -31,8 +31,8 @@ states:
|
|
|
31
31
|
- If uncertain about conventions or rules, ask the user about them
|
|
32
32
|
- Read relevant files and documentation
|
|
33
33
|
- Check whether there is a requirements document in the project and if so, read it carefully
|
|
34
|
-
- If the project is still empty, use
|
|
35
|
-
- Use
|
|
34
|
+
- If the project is still empty, use your **starting-project** skill if available, or ask the user about their project setup practices
|
|
35
|
+
- Use your **architecture** skill if available, or ask the user about their architectural conventions
|
|
36
36
|
|
|
37
37
|
Focus on understanding without writing code yet. Document your findings and create tasks as needed.
|
|
38
38
|
transitions:
|
|
@@ -48,8 +48,8 @@ states:
|
|
|
48
48
|
|
|
49
49
|
- Check whether there is a requirements document in the project and base your strategy on it
|
|
50
50
|
- Check whether there is a design document in the project and adhere to it; if not, elaborate design options and present them to the user
|
|
51
|
-
- Use
|
|
52
|
-
- Use
|
|
51
|
+
- Use your **architecture** skill if available, or ask the user about their architectural conventions
|
|
52
|
+
- Use your **application-design** skill if available, or ask the user about their application design practices
|
|
53
53
|
|
|
54
54
|
Break down the work into specific, actionable tasks. Consider edge cases, dependencies, and potential challenges. Document the planning work thoroughly and create implementation tasks as part of the code phase as needed.
|
|
55
55
|
transitions:
|
|
@@ -82,8 +82,8 @@ states:
|
|
|
82
82
|
|
|
83
83
|
- Check whether there is a design document in the project and follow it; if not, elaborate design options and present them to the user
|
|
84
84
|
- Check whether there is a requirements document in the project and ensure all requirements are met
|
|
85
|
-
- Use
|
|
86
|
-
- Use
|
|
85
|
+
- Use your **coding** skill if available, or ask the user about their coding practices and patterns
|
|
86
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
87
87
|
|
|
88
88
|
Write clean, well-structured code with proper error handling. Prevent regression by building, linting, and executing existing tests. Stay flexible and adapt the plan as you learn more during implementation. Update task progress and create new tasks as needed.
|
|
89
89
|
transitions:
|
|
@@ -150,7 +150,7 @@ states:
|
|
|
150
150
|
|
|
151
151
|
**STEP 3: Final Validation**
|
|
152
152
|
|
|
153
|
-
- Use
|
|
153
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
154
154
|
- Verify documentation accuracy with a final review
|
|
155
155
|
- Ensure code is ready for production/delivery
|
|
156
156
|
|
|
@@ -33,7 +33,7 @@ states:
|
|
|
33
33
|
- How will you measure product success?
|
|
34
34
|
- Have you validated this need with potential users?
|
|
35
35
|
|
|
36
|
-
Use
|
|
36
|
+
Use your **starting-project** skill if available, or ask the user about their project setup practices and conventions.
|
|
37
37
|
|
|
38
38
|
Don't discuss technical implementation yet - focus purely on understanding the problem space and requirements. Check whether there is a requirements document in the project and if so, read it carefully. Create tasks as needed.
|
|
39
39
|
transitions:
|
|
@@ -55,7 +55,7 @@ states:
|
|
|
55
55
|
- Challenge their choices by presenting alternatives
|
|
56
56
|
- Evaluate pros and cons of different tech stacks, frameworks, and architectural patterns
|
|
57
57
|
- Consider non-functional requirements like scalability, performance, maintainability, and deployment
|
|
58
|
-
- Use
|
|
58
|
+
- Use your **architecture** skill if available, or ask the user about their architectural conventions
|
|
59
59
|
|
|
60
60
|
Check whether there is an architecture document in the project and if so, read and build on it. Don't start coding yet - focus on technical design decisions.
|
|
61
61
|
transitions:
|
|
@@ -87,7 +87,7 @@ states:
|
|
|
87
87
|
default_instructions: |
|
|
88
88
|
Create a detailed implementation strategy based on your completed architecture and requirements.
|
|
89
89
|
|
|
90
|
-
- Use
|
|
90
|
+
- Use your **application-design** skill if available, or ask the user about their application design practices
|
|
91
91
|
- Check whether there is a design document in the project and adhere to it
|
|
92
92
|
|
|
93
93
|
**STEP 1: Break Down Work**
|
|
@@ -128,8 +128,8 @@ states:
|
|
|
128
128
|
|
|
129
129
|
- Check whether there is a design document in the project and follow it
|
|
130
130
|
- Check whether there is a requirements document in the project and ensure all requirements you are currently working on are met
|
|
131
|
-
- Use
|
|
132
|
-
- Use
|
|
131
|
+
- Use your **coding** skill if available, or ask the user about their coding practices and patterns
|
|
132
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
133
133
|
- Write clean, well-structured code with proper error handling
|
|
134
134
|
- Prevent regression by building, linting, and executing existing tests
|
|
135
135
|
- Stay flexible and adapt the plan as you learn more during implementation, but maintain alignment with your architecture decisions
|
|
@@ -186,7 +186,7 @@ states:
|
|
|
186
186
|
Ensure project has complete documentation for newcomers including setup, usage, architecture overview, and contribution guidelines.
|
|
187
187
|
|
|
188
188
|
**STEP 4: Final Validation**
|
|
189
|
-
- Use
|
|
189
|
+
- Use your **testing** skill if available, or ask the user about their testing practices
|
|
190
190
|
- Verify documentation accuracy with a final review
|
|
191
191
|
- Ensure project is ready for users and contributors
|
|
192
192
|
- Update task progress and mark completed work as you finalize the project
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: application-design
|
|
3
|
+
description: General conventions when creating an application design
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
practices
|
|
7
|
+
|
|
8
|
+
# Application Design Conventions
|
|
9
|
+
|
|
10
|
+
**Organization:**
|
|
11
|
+
|
|
12
|
+
- Apply the Single Responsibility Principle
|
|
13
|
+
- Use packages with defined interfaces to apply open-close principle for components
|
|
14
|
+
|
|
15
|
+
**APIs:**
|
|
16
|
+
|
|
17
|
+
- Use RESTful conventions
|
|
18
|
+
- Handle 404s gracefully
|
|
19
|
+
|
|
20
|
+
**Validation:**
|
|
21
|
+
|
|
22
|
+
- Validate on client and server
|
|
23
|
+
- Provide immediate feedback
|
|
24
|
+
- Handle edge cases and malicious input
|
|
25
|
+
|
|
26
|
+
**Configurability**
|
|
27
|
+
|
|
28
|
+
- Only provide configurability if explicitly requested
|
|
29
|
+
- If needed, use the registry pattern
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architecture
|
|
3
|
+
description: General practices to consider when setting up a new application or enhancing it structurally
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Architecture conventions
|
|
7
|
+
|
|
8
|
+
**Organization:**
|
|
9
|
+
|
|
10
|
+
- SRP, separation of concerns, dependency injection
|
|
11
|
+
- Fail fast with clear error messages
|
|
12
|
+
- Use packages with defined interfaces to apply open-close principle for components
|
|
13
|
+
- Start with simple, testable components
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: coding
|
|
3
|
+
description: General practices to consider when writing code
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Coding conventions
|
|
7
|
+
|
|
8
|
+
**Code Quality:**
|
|
9
|
+
|
|
10
|
+
- Write self-documenting code with clear names. Prefer verbose names over comments
|
|
11
|
+
- Comment the intend (why), do not describe the code (how)
|
|
12
|
+
- KISS
|
|
13
|
+
- DRY
|
|
14
|
+
- Prefer simplicity (understandability over elegance)
|
|
15
|
+
|
|
16
|
+
**Error Handling:**
|
|
17
|
+
|
|
18
|
+
- Handle errors explicitly
|
|
19
|
+
- Use explicit error types
|
|
20
|
+
- Provide context in messages
|
|
21
|
+
- Use structured logging and debugger over console.log
|
|
22
|
+
|
|
23
|
+
**Performance:**
|
|
24
|
+
|
|
25
|
+
- Avoid premature optimization
|
|
26
|
+
- Use appropriate data structures
|
|
27
|
+
- Consider memory usage
|
|
28
|
+
- Profile before optimizing
|
|
29
|
+
|
|
30
|
+
**Security:**
|
|
31
|
+
|
|
32
|
+
- Follow OWASP security guidelines and dependency scanning
|
|
33
|
+
- Validate and sanitize inputs
|
|
34
|
+
- Use parameterized queries
|
|
35
|
+
- Never hardcode secrets
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: starting-project
|
|
3
|
+
description: How to set-up the skeleton of a new application
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Starting Project conventions
|
|
7
|
+
|
|
8
|
+
**Check existing structure:**
|
|
9
|
+
|
|
10
|
+
- Look for README.md, package.json, or project files
|
|
11
|
+
- Identify tech stack
|
|
12
|
+
|
|
13
|
+
**Setup patterns:**
|
|
14
|
+
|
|
15
|
+
- Set up gitignore and linting tools
|
|
16
|
+
- Create basic test structure with common framework
|
|
17
|
+
- Add standard build scripts and CI/CD templates
|
|
18
|
+
- Document setup and contribution guidelines
|
|
19
|
+
|
|
20
|
+
**Mandatory user interaction:**
|
|
21
|
+
|
|
22
|
+
- Ask the user for preferences on starter templates
|
|
23
|
+
- Before you write any package or launch a generator, ALWAYS present it to the user and wait for confirmation!
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: task-handling
|
|
3
|
+
description: Important conventions on how to author and work on tasks
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Task Writing Methodology
|
|
7
|
+
|
|
8
|
+
**SMART Tasks:**
|
|
9
|
+
|
|
10
|
+
- Use task description for SMART criteria
|
|
11
|
+
- Include all context for new team members
|
|
12
|
+
- Include instructions to research known sources of knowledge
|
|
13
|
+
- Specify dependencies and prerequisites
|
|
14
|
+
|
|
15
|
+
**Task Completion:**
|
|
16
|
+
|
|
17
|
+
- Record results and key findings when completing
|
|
18
|
+
- Document "how it was done" - methods, approaches, decisions
|
|
19
|
+
- Update plan file with key results in addition
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: testing
|
|
3
|
+
description: General practices when writing and executing tests
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
## Testing Best Practices
|
|
7
|
+
|
|
8
|
+
**Test Authoring:**
|
|
9
|
+
|
|
10
|
+
- Test behavior, not implementation
|
|
11
|
+
- Use testing pyramid (many unit, some integration, few E2E)
|
|
12
|
+
- Test edge cases and error conditions
|
|
13
|
+
- Keep tests simple and fast
|
|
14
|
+
|
|
15
|
+
**Test Organization:**
|
|
16
|
+
|
|
17
|
+
- Group related tests
|
|
18
|
+
- Use descriptive test names
|
|
19
|
+
- Follow AAA pattern (Arrange, Act, Assert)
|
|
20
|
+
- Keep test data minimal
|
|
@@ -40,19 +40,6 @@ states:
|
|
|
40
40
|
to: 'analyze'
|
|
41
41
|
transition_reason: 'Bug reproduced successfully, ready to analyze root cause'
|
|
42
42
|
|
|
43
|
-
- trigger: 'bug_not_reproducible'
|
|
44
|
-
to: 'reproduce'
|
|
45
|
-
instructions: >
|
|
46
|
-
Unable to reproduce the bug with current information. Gather more details about the environment,
|
|
47
|
-
conditions, or steps that might be missing. Contact the reporter for additional information if needed.
|
|
48
|
-
Continue attempting reproduction with new information.
|
|
49
|
-
transition_reason: 'Bug could not be reproduced, need more information'
|
|
50
|
-
|
|
51
|
-
- trigger: 'abandon_bug'
|
|
52
|
-
to: 'reproduce'
|
|
53
|
-
additional_instructions: 'Bug investigation abandoned. Clean up any reproduction work and prepare for new bug reports.'
|
|
54
|
-
transition_reason: 'Bug investigation abandoned'
|
|
55
|
-
|
|
56
43
|
analyze:
|
|
57
44
|
description: 'Analyze the bug and identify root cause'
|
|
58
45
|
default_instructions: Examine the code paths involved in the bug, identify the root cause, and understand why the issue occurs. Use debugging tools, add logging, and trace through the problematic code. Document your analysis and create tasks as needed.
|