ai-workflow-init 3.2.3 → 3.6.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/.cursor/commands/check-implementation.md +127 -15
- package/.cursor/commands/code-review.md +164 -58
- package/.cursor/commands/create-plan.md +163 -66
- package/.cursor/commands/execute-plan.md +143 -33
- package/.cursor/commands/generate-standards.md +109 -51
- package/.cursor/commands/init-chat.md +5 -0
- package/.cursor/commands/writing-test.md +94 -163
- package/AGENTS.md +118 -18
- package/cli.js +12 -3
- package/docs/ai/planning/feature-template.md +10 -3
- package/docs/ai/requirements/req-template.md +137 -0
- package/package.json +1 -1
package/AGENTS.md
CHANGED
|
@@ -1,24 +1,124 @@
|
|
|
1
|
-
# AI Agent
|
|
1
|
+
# AI Agent Workflow Standards
|
|
2
2
|
|
|
3
|
-
##
|
|
4
|
-
- Plan: Before coding, create a feature execution checklist (todo) from the plan. Do not start Implementation until the todo list exists and is agreed.
|
|
5
|
-
- Implementation: Before each operation, write a short status update (1–3 sentences). Perform edits via file editing tools, not by printing code for copy-paste.
|
|
6
|
-
- Testing: After each batch of edits, run linter/typing/build on the changed files; auto-fix issues (up to 3 attempts) before asking for help.
|
|
7
|
-
- Review: When todos are completed and checks pass, provide a concise summary highlighting key changes and their impact.
|
|
3
|
+
## Core Coding Philosophy
|
|
8
4
|
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
|
|
5
|
+
Apply these principles when providing solutions, generating code, or making technical decisions:
|
|
6
|
+
|
|
7
|
+
### 1. Simplicity First
|
|
8
|
+
|
|
9
|
+
- Choose the simplest solution that meets requirements
|
|
10
|
+
- Avoid over-engineering and unnecessary abstractions
|
|
11
|
+
- Simple code = fewer bugs, easier to maintain, easier to understand
|
|
12
|
+
- Ask: "Can this be done more simply while still working?"
|
|
13
|
+
- Complexity is a last resort, not a first choice
|
|
14
|
+
|
|
15
|
+
### 2. Deep Understanding
|
|
16
|
+
|
|
17
|
+
- Understand requirements fully before planning or coding
|
|
18
|
+
- If unclear about requirement, flow, edge cases, or expected behavior → Ask the user
|
|
19
|
+
- Never assume or guess - clarification prevents wasted effort
|
|
20
|
+
- Ask questions like:
|
|
21
|
+
- "What should happen when X occurs?"
|
|
22
|
+
- "How should the system behave if Y fails?"
|
|
23
|
+
- "Is this the expected flow: A → B → C?"
|
|
24
|
+
|
|
25
|
+
### 3. Multiple Options
|
|
26
|
+
|
|
27
|
+
- Provide 2-5 solution options for each problem when appropriate
|
|
28
|
+
- Present trade-offs clearly: pros/cons, complexity, performance, maintainability
|
|
29
|
+
- Format: "Option 1: [approach] - Pros: [...] Cons: [...]"
|
|
30
|
+
- Let user choose based on their context and priorities
|
|
31
|
+
- Not every problem has one "best" solution
|
|
32
|
+
|
|
33
|
+
### 4. Think Ahead
|
|
34
|
+
|
|
35
|
+
- While keeping solutions simple, consider future implications:
|
|
36
|
+
- How will this scale with more data/users?
|
|
37
|
+
- What if requirements change slightly?
|
|
38
|
+
- Are there security vulnerabilities?
|
|
39
|
+
- What are performance bottlenecks?
|
|
40
|
+
- Balance: Simple now + adaptable for reasonable future needs
|
|
41
|
+
- Do not build for hypothetical futures, but be aware of likely changes
|
|
42
|
+
|
|
43
|
+
**Philosophy in practice:**
|
|
44
|
+
|
|
45
|
+
- Simplicity: Use built-in array methods instead of custom loop logic
|
|
46
|
+
- Deep Understanding: "Should this API return 404 or 400 for invalid IDs?"
|
|
47
|
+
- Multiple Options: "We can use: 1) localStorage (simple), 2) IndexedDB (scalable), or 3) Backend API (persistent)"
|
|
48
|
+
- Think Ahead: "This works for 100 items, but consider pagination for 10,000+"
|
|
49
|
+
|
|
50
|
+
---
|
|
51
|
+
|
|
52
|
+
## Core Workflow: Plan → Implement → Test → Review
|
|
53
|
+
|
|
54
|
+
### Workflow Alignment
|
|
55
|
+
|
|
56
|
+
- **Plan:** Create feature planning doc at `docs/ai/planning/feature-{name}.md` before coding. Do not start until planning exists and is agreed.
|
|
57
|
+
- **Implement:** Provide 1-3 sentence status updates before operations. Use file editing tools, not copy-paste. Update checkboxes `[ ]` → `[x]` in planning doc.
|
|
58
|
+
- **Test:** Run linter/type-check/build on changed files after each batch. Auto-fix issues (up to 3 attempts) before asking for help.
|
|
59
|
+
- **Review:** When complete, validate against planning doc acceptance criteria and CODE_CONVENTIONS.md.
|
|
60
|
+
|
|
61
|
+
## File Structure
|
|
62
|
+
|
|
63
|
+
### Planning Documents
|
|
64
|
+
|
|
65
|
+
- Location: `docs/ai/planning/feature-{name}.md` (kebab-case)
|
|
66
|
+
- Must include: Goal, Acceptance Criteria (GWT), Risks, Implementation Phases, Follow-ups
|
|
67
|
+
- Template: `docs/ai/planning/feature-template.md`
|
|
68
|
+
|
|
69
|
+
### Project Standards
|
|
70
|
+
|
|
71
|
+
- Coding conventions: `docs/ai/project/CODE_CONVENTIONS.md`
|
|
72
|
+
- Architecture guide: `docs/ai/project/PROJECT_STRUCTURE.md`
|
|
73
|
+
- Language templates: `docs/ai/project/template-convention/`
|
|
74
|
+
|
|
75
|
+
## Tooling Strategy
|
|
76
|
+
|
|
77
|
+
- Prefer semantic search across codebase; use grep only for exact matches
|
|
78
|
+
- Default to parallel execution for independent operations
|
|
79
|
+
- Quality tools: ESLint, TypeScript, Prettier (auto-format/auto-fix when possible)
|
|
12
80
|
|
|
13
81
|
## Communication
|
|
14
|
-
- Use Markdown only when necessary; use backticks for `files/dirs/functions/classes`.
|
|
15
|
-
- Provide status updates before/after important actions; provide a high-signal summary at completion.
|
|
16
|
-
- Mirror the user's chat language in responses (respond in the user's language); default to English if the user's language is unclear or ambiguous.
|
|
17
82
|
|
|
18
|
-
|
|
19
|
-
-
|
|
20
|
-
-
|
|
83
|
+
- Use Markdown only when necessary; backticks for `files/dirs/functions/classes`
|
|
84
|
+
- Status updates before/after important actions
|
|
85
|
+
- Mirror user's chat language; code/comments always in English
|
|
86
|
+
|
|
87
|
+
## Code Presentation
|
|
88
|
+
|
|
89
|
+
- Existing code: cite with `startLine:endLine:filepath` (no language tag)
|
|
90
|
+
- New code: fenced blocks with language tag, no line numbers
|
|
91
|
+
|
|
92
|
+
## TODO Policy
|
|
93
|
+
|
|
94
|
+
- For medium/large tasks: create todos (≤14 words, verb-led)
|
|
95
|
+
- Keep only ONE `in_progress` item
|
|
96
|
+
- Update immediately after progress; mark completed upon finish
|
|
97
|
+
|
|
98
|
+
## Git Workflow
|
|
99
|
+
|
|
100
|
+
- Feature branches: `feature/{name}` (match planning doc name)
|
|
101
|
+
- Commit format: `[phase] brief description`
|
|
102
|
+
- Examples: `[planning] create user auth plan`, `[phase-1] implement database schema`
|
|
103
|
+
|
|
104
|
+
## Slash Commands
|
|
105
|
+
|
|
106
|
+
- `/create-plan` - Generate planning doc
|
|
107
|
+
- `/execute-plan` - Implement tasks from planning doc
|
|
108
|
+
- `/modify-plan` - Modify plan after implementation
|
|
109
|
+
- `/code-review` - Validate against standards
|
|
110
|
+
- `/generate-standards` - Update CODE_CONVENTIONS.md
|
|
111
|
+
- `/writing-test` - Generate tests from acceptance criteria
|
|
112
|
+
- `/init-chat` - Load project rules (AGENTS.md)
|
|
113
|
+
|
|
114
|
+
## Quality Gates
|
|
115
|
+
|
|
116
|
+
### Before marking task complete:
|
|
117
|
+
|
|
118
|
+
- Code matches planning doc specification
|
|
119
|
+
- Linting passes (no warnings)
|
|
120
|
+
- Type checking passes (if applicable)
|
|
121
|
+
- Build succeeds (if applicable)
|
|
122
|
+
- Checkbox updated in planning doc: `[x]`
|
|
21
123
|
|
|
22
|
-
|
|
23
|
-
- For medium/large tasks, create todos (≤14 words, verb-led). Keep only one `in_progress` item.
|
|
24
|
-
- Update the todo list immediately after progress; mark completed and close upon finish.
|
|
124
|
+
---
|
package/cli.js
CHANGED
|
@@ -75,9 +75,9 @@ function cloneDocsAI(source, dest) {
|
|
|
75
75
|
run(`npx degit ${source} ${tempDir} --force`);
|
|
76
76
|
|
|
77
77
|
// Xử lý từng subfolder
|
|
78
|
-
const subfolders = ["planning", "testing"];
|
|
78
|
+
const subfolders = ["planning", "testing", "requirements"];
|
|
79
79
|
|
|
80
|
-
// Xử lý folders: planning, testing
|
|
80
|
+
// Xử lý folders: planning, testing, requirements
|
|
81
81
|
for (const subfolder of subfolders) {
|
|
82
82
|
const tempSubfolder = path.join(tempDir, subfolder);
|
|
83
83
|
const destSubfolder = path.join(dest, subfolder);
|
|
@@ -86,7 +86,7 @@ function cloneDocsAI(source, dest) {
|
|
|
86
86
|
mkdirSync(destSubfolder, { recursive: true });
|
|
87
87
|
|
|
88
88
|
// Chỉ copy file template và README.md
|
|
89
|
-
const filesToCopy = ["README.md", "feature-template.md"];
|
|
89
|
+
const filesToCopy = ["README.md", "feature-template.md", "req-template.md"];
|
|
90
90
|
|
|
91
91
|
for (const file of filesToCopy) {
|
|
92
92
|
const srcFile = path.join(tempSubfolder, file);
|
|
@@ -96,6 +96,15 @@ function cloneDocsAI(source, dest) {
|
|
|
96
96
|
cpSync(srcFile, destFile, { force: true });
|
|
97
97
|
}
|
|
98
98
|
}
|
|
99
|
+
|
|
100
|
+
// Tạo folder archive nếu là requirements hoặc planning
|
|
101
|
+
if (subfolder === "requirements" || subfolder === "planning") {
|
|
102
|
+
const archiveDir = path.join(destSubfolder, "archive");
|
|
103
|
+
if (!existsSync(archiveDir)) {
|
|
104
|
+
mkdirSync(archiveDir, { recursive: true });
|
|
105
|
+
console.log(`📁 Created archive folder: docs/ai/${subfolder}/archive`);
|
|
106
|
+
}
|
|
107
|
+
}
|
|
99
108
|
}
|
|
100
109
|
}
|
|
101
110
|
|
|
@@ -2,6 +2,12 @@
|
|
|
2
2
|
|
|
3
3
|
Note: All content in this document must be written in English.
|
|
4
4
|
|
|
5
|
+
## 0. Requirements Reference (Optional)
|
|
6
|
+
|
|
7
|
+
- **Requirement Doc**: [req-{feature-name}.md](../requirements/req-{feature-name}.md)
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
5
11
|
## 1. Codebase Context
|
|
6
12
|
|
|
7
13
|
> **Note**: This section is auto-generated by `/create-plan` exploration phase. Include only if relevant patterns were found.
|
|
@@ -23,9 +29,10 @@ Note: All content in this document must be written in English.
|
|
|
23
29
|
|
|
24
30
|
---
|
|
25
31
|
|
|
26
|
-
##
|
|
32
|
+
## 2a. Design Specifications
|
|
27
33
|
|
|
28
34
|
> **Note**: This section is for design specifications from any source (Figma, screenshot, detailed description, etc.). Include only if design source was provided.
|
|
35
|
+
> **Important**: Use EITHER Section 2a (Design Specifications) OR Section 2b (Theme Specification), not both. Delete the unused section.
|
|
29
36
|
|
|
30
37
|
### Reference
|
|
31
38
|
- **File**: {Figma file name}
|
|
@@ -101,10 +108,10 @@ Note: All content in this document must be written in English.
|
|
|
101
108
|
|
|
102
109
|
---
|
|
103
110
|
|
|
104
|
-
##
|
|
111
|
+
## 2b. Theme Specification (Alternative to 2a)
|
|
105
112
|
|
|
106
113
|
> **Note**: This section is auto-generated by `/create-plan` theme selection. Include only if theme was selected (no design source provided).
|
|
107
|
-
> **Important**: Use EITHER
|
|
114
|
+
> **Important**: Use EITHER Section 2a (Design Specifications) OR Section 2b (Theme Specification), not both. Delete the unused section.
|
|
108
115
|
|
|
109
116
|
### Selected Theme
|
|
110
117
|
- **Name**: {Theme Name}
|
|
@@ -0,0 +1,137 @@
|
|
|
1
|
+
# Requirement: {Feature Name}
|
|
2
|
+
|
|
3
|
+
Note: All content in this document must be written in English.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## 1. Problem Statement
|
|
8
|
+
|
|
9
|
+
### Context
|
|
10
|
+
[Business/technical context that led to this requirement]
|
|
11
|
+
|
|
12
|
+
### Problem
|
|
13
|
+
[The specific problem to be solved]
|
|
14
|
+
|
|
15
|
+
### Impact
|
|
16
|
+
[Consequences if not addressed - business value, user pain points]
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## 2. User Stories (Optional)
|
|
21
|
+
|
|
22
|
+
- As a [role], I want [action], so that [benefit]
|
|
23
|
+
- As a [role], I want [action], so that [benefit]
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## 3. Business Rules (Optional)
|
|
28
|
+
|
|
29
|
+
| ID | Rule | Description |
|
|
30
|
+
|----|------|-------------|
|
|
31
|
+
| BR-01 | {Rule Name} | {Detailed description} |
|
|
32
|
+
| BR-02 | {Rule Name} | {Detailed description} |
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## 4. Functional Requirements
|
|
37
|
+
|
|
38
|
+
| ID | Requirement | Priority | Notes |
|
|
39
|
+
|----|-------------|----------|-------|
|
|
40
|
+
| FR-01 | {Description} | Must | |
|
|
41
|
+
| FR-02 | {Description} | Should | |
|
|
42
|
+
| FR-03 | {Description} | Could | |
|
|
43
|
+
|
|
44
|
+
**Priority Legend:**
|
|
45
|
+
- **Must**: Critical for release
|
|
46
|
+
- **Should**: Important but not blocking
|
|
47
|
+
- **Could**: Nice to have
|
|
48
|
+
|
|
49
|
+
---
|
|
50
|
+
|
|
51
|
+
## 5. Non-Functional Requirements (Optional)
|
|
52
|
+
|
|
53
|
+
| Category | Requirement |
|
|
54
|
+
|----------|-------------|
|
|
55
|
+
| **Performance** | {e.g., Response time < 200ms, support 1000 concurrent users} |
|
|
56
|
+
| **Security** | {e.g., Authentication required, data encryption} |
|
|
57
|
+
| **Compatibility** | {e.g., Chrome 90+, Safari 14+, mobile responsive} |
|
|
58
|
+
| **Accessibility** | {e.g., WCAG 2.1 AA compliance} |
|
|
59
|
+
| **Scalability** | {e.g., Handle 10x traffic growth} |
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## 6. Edge Cases & Constraints (Optional)
|
|
64
|
+
|
|
65
|
+
### Edge Cases
|
|
66
|
+
|
|
67
|
+
| Case | Expected Behavior |
|
|
68
|
+
|------|-------------------|
|
|
69
|
+
| {Edge case description} | {How system should handle it} |
|
|
70
|
+
| {Edge case description} | {How system should handle it} |
|
|
71
|
+
|
|
72
|
+
### Constraints
|
|
73
|
+
|
|
74
|
+
- **Technical**: {e.g., Must use existing auth system}
|
|
75
|
+
- **Business**: {e.g., Budget limit, timeline}
|
|
76
|
+
- **Dependencies**: {e.g., Requires API v2 ready}
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## 7. Clarifications Log (Optional)
|
|
81
|
+
|
|
82
|
+
> Questions resolved during requirement gathering sessions
|
|
83
|
+
|
|
84
|
+
| # | Question | Answer |
|
|
85
|
+
|---|----------|--------|
|
|
86
|
+
| 1 | {Question asked} | {Answer received} |
|
|
87
|
+
| 2 | {Question asked} | {Answer received} |
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## 8. Out of Scope (Optional)
|
|
92
|
+
|
|
93
|
+
> Explicitly excluded from this requirement
|
|
94
|
+
|
|
95
|
+
- {Feature/functionality not included}
|
|
96
|
+
- {Deferred to future iteration}
|
|
97
|
+
- {Related but separate concern}
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## 9. Acceptance Criteria
|
|
102
|
+
|
|
103
|
+
### Scenario 1: {Happy Path - Main Flow}
|
|
104
|
+
|
|
105
|
+
- **Given** [initial context/state]
|
|
106
|
+
- **When** [action performed]
|
|
107
|
+
- **Then** [expected outcome]
|
|
108
|
+
|
|
109
|
+
### Scenario 2: {Alternative Flow} (Optional)
|
|
110
|
+
|
|
111
|
+
- **Given** [context]
|
|
112
|
+
- **When** [action]
|
|
113
|
+
- **Then** [outcome]
|
|
114
|
+
|
|
115
|
+
### Scenario 3: {Error Handling} (Optional)
|
|
116
|
+
|
|
117
|
+
- **Given** [context]
|
|
118
|
+
- **When** [invalid action/error condition]
|
|
119
|
+
- **Then** [error handling behavior]
|
|
120
|
+
|
|
121
|
+
---
|
|
122
|
+
|
|
123
|
+
## 10. References (Optional)
|
|
124
|
+
|
|
125
|
+
- **Related Docs**: [links to related requirements, designs, etc.]
|
|
126
|
+
- **External Links**: [Jira tickets, Figma, API docs, etc.]
|
|
127
|
+
|
|
128
|
+
---
|
|
129
|
+
|
|
130
|
+
## 11. Glossary (Optional)
|
|
131
|
+
|
|
132
|
+
> Domain-specific terms and definitions. Include only if specialized terminology is used.
|
|
133
|
+
|
|
134
|
+
| Term | Definition |
|
|
135
|
+
|------|------------|
|
|
136
|
+
| {Term 1} | {Clear definition in project context} |
|
|
137
|
+
| {Term 2} | {Clear definition in project context} |
|