ai-workflow-init 3.0.0 → 3.1.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/CLAUDE.md +114 -0
- package/cli.js +7 -0
- package/package.json +1 -1
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
# AI Agent Workflow Standards
|
|
2
|
+
|
|
3
|
+
## Core Coding Philosophy
|
|
4
|
+
|
|
5
|
+
Apply these principles when providing solutions, generating code, or making technical decisions:
|
|
6
|
+
|
|
7
|
+
### 1. Simplicity First
|
|
8
|
+
- Choose the simplest solution that meets requirements
|
|
9
|
+
- Avoid over-engineering and unnecessary abstractions
|
|
10
|
+
- Simple code = fewer bugs, easier to maintain, easier to understand
|
|
11
|
+
- Ask: "Can this be done more simply while still working?"
|
|
12
|
+
- Complexity is a last resort, not a first choice
|
|
13
|
+
|
|
14
|
+
### 2. Deep Understanding
|
|
15
|
+
- Understand requirements fully before planning or coding
|
|
16
|
+
- If unclear about requirement, flow, edge cases, or expected behavior → Ask the user
|
|
17
|
+
- Never assume or guess - clarification prevents wasted effort
|
|
18
|
+
- Ask questions like:
|
|
19
|
+
- "What should happen when X occurs?"
|
|
20
|
+
- "How should the system behave if Y fails?"
|
|
21
|
+
- "Is this the expected flow: A → B → C?"
|
|
22
|
+
|
|
23
|
+
### 3. Multiple Options
|
|
24
|
+
- Provide 2-5 solution options for each problem when appropriate
|
|
25
|
+
- Present trade-offs clearly: pros/cons, complexity, performance, maintainability
|
|
26
|
+
- Format: "Option 1: [approach] - Pros: [...] Cons: [...]"
|
|
27
|
+
- Let user choose based on their context and priorities
|
|
28
|
+
- Not every problem has one "best" solution
|
|
29
|
+
|
|
30
|
+
### 4. Think Ahead
|
|
31
|
+
- While keeping solutions simple, consider future implications:
|
|
32
|
+
- How will this scale with more data/users?
|
|
33
|
+
- What if requirements change slightly?
|
|
34
|
+
- Are there security vulnerabilities?
|
|
35
|
+
- What are performance bottlenecks?
|
|
36
|
+
- Balance: Simple now + adaptable for reasonable future needs
|
|
37
|
+
- Do not build for hypothetical futures, but be aware of likely changes
|
|
38
|
+
|
|
39
|
+
**Philosophy in practice:**
|
|
40
|
+
- Simplicity: Use built-in array methods instead of custom loop logic
|
|
41
|
+
- Deep Understanding: "Should this API return 404 or 400 for invalid IDs?"
|
|
42
|
+
- Multiple Options: "We can use: 1) localStorage (simple), 2) IndexedDB (scalable), or 3) Backend API (persistent)"
|
|
43
|
+
- Think Ahead: "This works for 100 items, but consider pagination for 10,000+"
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
## Core Workflow: Plan → Implement → Test → Review
|
|
48
|
+
|
|
49
|
+
### Workflow Alignment
|
|
50
|
+
- **Plan:** Create feature planning doc at `docs/ai/planning/feature-{name}.md` before coding. Do not start until planning exists and is agreed.
|
|
51
|
+
- **Implement:** Provide 1-3 sentence status updates before operations. Use file editing tools, not copy-paste. Update checkboxes `[ ]` → `[x]` in planning doc.
|
|
52
|
+
- **Test:** Run linter/type-check/build on changed files after each batch. Auto-fix issues (up to 3 attempts) before asking for help.
|
|
53
|
+
- **Review:** When complete, validate against planning doc acceptance criteria and CODE_CONVENTIONS.md.
|
|
54
|
+
|
|
55
|
+
## File Structure
|
|
56
|
+
|
|
57
|
+
### Planning Documents
|
|
58
|
+
- Location: `docs/ai/planning/feature-{name}.md` (kebab-case)
|
|
59
|
+
- Must include: Goal, Acceptance Criteria (GWT), Risks, Implementation Phases, Follow-ups
|
|
60
|
+
- Template: `docs/ai/planning/feature-template.md`
|
|
61
|
+
|
|
62
|
+
### Project Standards
|
|
63
|
+
- Coding conventions: `docs/ai/project/CODE_CONVENTIONS.md`
|
|
64
|
+
- Architecture guide: `docs/ai/project/PROJECT_STRUCTURE.md`
|
|
65
|
+
- Language templates: `docs/ai/project/template-convention/`
|
|
66
|
+
|
|
67
|
+
## Tooling Strategy
|
|
68
|
+
- Prefer semantic search across codebase; use grep only for exact matches
|
|
69
|
+
- Default to parallel execution for independent operations
|
|
70
|
+
- Quality tools: ESLint, TypeScript, Prettier (auto-format/auto-fix when possible)
|
|
71
|
+
|
|
72
|
+
## Communication
|
|
73
|
+
- Use Markdown only when necessary; backticks for `files/dirs/functions/classes`
|
|
74
|
+
- Status updates before/after important actions
|
|
75
|
+
- Mirror user's chat language; code/comments always in English
|
|
76
|
+
|
|
77
|
+
## Code Presentation
|
|
78
|
+
- Existing code: cite with `startLine:endLine:filepath` (no language tag)
|
|
79
|
+
- New code: fenced blocks with language tag, no line numbers
|
|
80
|
+
|
|
81
|
+
## TODO Policy
|
|
82
|
+
- For medium/large tasks: create todos (≤14 words, verb-led)
|
|
83
|
+
- Keep only ONE `in_progress` item
|
|
84
|
+
- Update immediately after progress; mark completed upon finish
|
|
85
|
+
|
|
86
|
+
## Git Workflow
|
|
87
|
+
- Feature branches: `feature/{name}` (match planning doc name)
|
|
88
|
+
- Commit format: `[phase] brief description`
|
|
89
|
+
- Examples: `[planning] create user auth plan`, `[phase-1] implement database schema`
|
|
90
|
+
|
|
91
|
+
## Slash Commands
|
|
92
|
+
- `/create-plan` - Generate planning doc
|
|
93
|
+
- `/execute-plan` - Implement tasks from planning doc
|
|
94
|
+
- `/modify-plan` - Modify plan after implementation
|
|
95
|
+
- `/code-review` - Validate against standards
|
|
96
|
+
- `/generate-standards` - Update CODE_CONVENTIONS.md
|
|
97
|
+
- `/writing-test` - Generate tests from acceptance criteria
|
|
98
|
+
- `/init-chat` - Load project rules (AGENTS.md)
|
|
99
|
+
|
|
100
|
+
## Quality Gates
|
|
101
|
+
### Before marking task complete:
|
|
102
|
+
- Code matches planning doc specification
|
|
103
|
+
- Linting passes (no warnings)
|
|
104
|
+
- Type checking passes (if applicable)
|
|
105
|
+
- Build succeeds (if applicable)
|
|
106
|
+
- Checkbox updated in planning doc: `[x]`
|
|
107
|
+
|
|
108
|
+
---
|
|
109
|
+
|
|
110
|
+
**Claude Code Specifics:**
|
|
111
|
+
- This file is automatically loaded every session
|
|
112
|
+
- Commands inherit these standards
|
|
113
|
+
- Use `/context` to see loaded memory
|
|
114
|
+
- Use `/usage` to monitor token consumption
|
package/cli.js
CHANGED
|
@@ -244,6 +244,13 @@ async function main() {
|
|
|
244
244
|
} catch (_) {
|
|
245
245
|
run(`wget -qO .claude/hooks.json ${RAW_BASE}/.claude/hooks.json`);
|
|
246
246
|
}
|
|
247
|
+
|
|
248
|
+
// Download skills folder (always overwrite to get latest)
|
|
249
|
+
step("🚚 Downloading Claude Code skills (.claude/skills)...");
|
|
250
|
+
if (!existsSync(".claude/skills")) {
|
|
251
|
+
mkdirSync(".claude/skills", { recursive: true });
|
|
252
|
+
}
|
|
253
|
+
run(`npx degit ${REPO}/.claude/skills .claude/skills --force`);
|
|
247
254
|
}
|
|
248
255
|
|
|
249
256
|
// Clone Cursor prompts (luôn ghi đè)
|