thanh-kit 2.5.1 → 2.5.3
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/dist/index.js +50 -61
- package/dist/index.js.map +1 -1
- package/package.json +1 -1
- package/templates/{commands → command-archive}/ask.md +5 -5
- package/templates/{commands → command-archive}/ck-help.md +18 -2
- package/templates/command-archive/docs/init.md +38 -0
- package/templates/command-archive/docs/summarize.md +22 -0
- package/templates/command-archive/docs/update.md +76 -0
- package/templates/command-archive/journal.md +18 -0
- package/templates/{commands → command-archive}/kanban.md +5 -7
- package/templates/{commands → command-archive}/plan/archive.md +2 -2
- package/templates/command-archive/plan/red-team.md +200 -0
- package/templates/command-archive/plan/validate.md +188 -0
- package/templates/command-archive/preview.md +283 -0
- package/templates/command-archive/review/codebase/parallel.md +122 -0
- package/templates/{commands → command-archive}/test/ui.md +3 -3
- package/templates/{commands → command-archive}/use-mcp.md +6 -2
- package/templates/command-archive/worktree.md +109 -0
- package/templates/{workflows → rules}/development-rules.md +12 -53
- package/templates/rules/orchestration-protocol.md +43 -0
- package/templates/{workflows → rules}/primary-workflow.md +16 -4
- package/templates/rules/team-coordination-rules.md +90 -0
- package/templates/schemas/ck-config.schema.json +381 -0
- package/templates/commands/README.md +0 -251
- package/templates/commands/bootstrap/auto/fast.md +0 -111
- package/templates/commands/bootstrap/auto/parallel.md +0 -66
- package/templates/commands/bootstrap/auto.md +0 -115
- package/templates/commands/bootstrap.md +0 -137
- package/templates/commands/brainstorm.md +0 -74
- package/templates/commands/build.md +0 -39
- package/templates/commands/checkpoint.md +0 -156
- package/templates/commands/code/auto.md +0 -170
- package/templates/commands/code/no-test.md +0 -158
- package/templates/commands/code/parallel.md +0 -55
- package/templates/commands/code-simplifier.md +0 -71
- package/templates/commands/code.md +0 -176
- package/templates/commands/compact.md +0 -57
- package/templates/commands/content/cro.md +0 -43
- package/templates/commands/content/enhance.md +0 -14
- package/templates/commands/content/fast.md +0 -13
- package/templates/commands/content/good.md +0 -16
- package/templates/commands/context.md +0 -48
- package/templates/commands/cook/auto/fast.md +0 -26
- package/templates/commands/cook/auto/parallel.md +0 -49
- package/templates/commands/cook/auto.md +0 -15
- package/templates/commands/cook/fast.md +0 -47
- package/templates/commands/cook/hard.md +0 -80
- package/templates/commands/cook/parallel.md +0 -90
- package/templates/commands/cook.md +0 -105
- package/templates/commands/create-feature.md +0 -48
- package/templates/commands/db-migrate.md +0 -52
- package/templates/commands/debug.md +0 -13
- package/templates/commands/design/3d.md +0 -83
- package/templates/commands/design/describe.md +0 -23
- package/templates/commands/design/fast.md +0 -31
- package/templates/commands/design/good.md +0 -35
- package/templates/commands/design/screenshot.md +0 -34
- package/templates/commands/design/video.md +0 -34
- package/templates/commands/docs/init.md +0 -39
- package/templates/commands/docs/summarize.md +0 -31
- package/templates/commands/docs/update.md +0 -57
- package/templates/commands/feature.md +0 -62
- package/templates/commands/fix/ci.md +0 -17
- package/templates/commands/fix/fast.md +0 -19
- package/templates/commands/fix/hard.md +0 -39
- package/templates/commands/fix/logs.md +0 -26
- package/templates/commands/fix/parallel.md +0 -54
- package/templates/commands/fix/test.md +0 -20
- package/templates/commands/fix/types.md +0 -9
- package/templates/commands/fix/ui.md +0 -48
- package/templates/commands/fix-issue.md +0 -177
- package/templates/commands/fix.md +0 -43
- package/templates/commands/generate-dto.md +0 -67
- package/templates/commands/git/cm.md +0 -5
- package/templates/commands/git/cp.md +0 -4
- package/templates/commands/git/merge.md +0 -40
- package/templates/commands/git/pr.md +0 -48
- package/templates/commands/integrate/polar.md +0 -28
- package/templates/commands/integrate/sepay.md +0 -28
- package/templates/commands/investigate.md +0 -324
- package/templates/commands/journal.md +0 -7
- package/templates/commands/lint.md +0 -47
- package/templates/commands/migration.md +0 -111
- package/templates/commands/performance.md +0 -110
- package/templates/commands/plan/ci.md +0 -33
- package/templates/commands/plan/cro.md +0 -69
- package/templates/commands/plan/fast.md +0 -86
- package/templates/commands/plan/hard.md +0 -103
- package/templates/commands/plan/parallel.md +0 -152
- package/templates/commands/plan/preview.md +0 -40
- package/templates/commands/plan/two.md +0 -52
- package/templates/commands/plan/validate.md +0 -132
- package/templates/commands/plan.md +0 -36
- package/templates/commands/pr.md +0 -49
- package/templates/commands/preview.md +0 -87
- package/templates/commands/release-notes.md +0 -144
- package/templates/commands/review/post-task.md +0 -157
- package/templates/commands/review-changes.md +0 -46
- package/templates/commands/review.md +0 -56
- package/templates/commands/scout/ext.md +0 -35
- package/templates/commands/scout.md +0 -283
- package/templates/commands/security.md +0 -119
- package/templates/commands/skill/add.md +0 -36
- package/templates/commands/skill/create.md +0 -29
- package/templates/commands/skill/fix-logs.md +0 -22
- package/templates/commands/skill/optimize/auto.md +0 -25
- package/templates/commands/skill/optimize.md +0 -34
- package/templates/commands/skill/plan.md +0 -45
- package/templates/commands/worktree.md +0 -126
- package/templates/memory/session-log.md +0 -186
- package/templates/router/README.md +0 -294
- package/templates/router/agents-guide.md +0 -38
- package/templates/router/commands-guide.md +0 -122
- package/templates/router/decision-flow.md +0 -92
- package/templates/router/skills-guide.md +0 -127
- package/templates/router/workflows-guide.md +0 -68
- package/templates/workflows/README.md +0 -241
- package/templates/workflows/orchestration-protocol.md +0 -16
- /package/templates/{commands → command-archive}/coding-level.md +0 -0
- /package/templates/{commands → command-archive}/review/codebase.md +0 -0
- /package/templates/{commands → command-archive}/test.md +0 -0
- /package/templates/{commands → command-archive}/watzup.md +0 -0
- /package/templates/{workflows → rules}/documentation-management.md +0 -0
|
@@ -1,137 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡⚡⚡ Bootstrap a new project step by step
|
|
3
|
-
argument-hint: [user-requirements]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
**Ultrathink** to plan & bootstrap a new project follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules in your `CLAUDE.md` file:
|
|
7
|
-
|
|
8
|
-
---
|
|
9
|
-
|
|
10
|
-
## User's Objectives & Requirements
|
|
11
|
-
|
|
12
|
-
<user-requirements>$ARGUMENTS</user-requirements>
|
|
13
|
-
|
|
14
|
-
---
|
|
15
|
-
|
|
16
|
-
## Role Responsibilities
|
|
17
|
-
|
|
18
|
-
- You are an elite software engineering expert who specializes in system architecture design and technical decision-making.
|
|
19
|
-
- Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs, then collaborate with your subagents to implement the plan.
|
|
20
|
-
- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
|
|
21
|
-
|
|
22
|
-
---
|
|
23
|
-
|
|
24
|
-
## Your Approach
|
|
25
|
-
|
|
26
|
-
1. **Question Everything**: Use `AskUserQuestion` tool to ask probing questions to the user to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
|
|
27
|
-
|
|
28
|
-
2. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
|
|
29
|
-
|
|
30
|
-
3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior. Use `AskUserQuestion` tool to ask the user for their preferences.
|
|
31
|
-
|
|
32
|
-
4. **Challenge Assumptions**: Question the user's initial approach. Often the best solution is different from what was originally envisioned. Use `AskUserQuestion` tool to ask the user for their preferences.
|
|
33
|
-
|
|
34
|
-
5. **Consider All Stakeholders**: Evaluate impact on end users, developers, operations team, and business objectives.
|
|
35
|
-
|
|
36
|
-
---
|
|
37
|
-
|
|
38
|
-
## Workflow:
|
|
39
|
-
|
|
40
|
-
Follow strictly these following steps:
|
|
41
|
-
|
|
42
|
-
**First thing first:** check if Git has been initialized, if not, ask the user if they want to initialize it, if yes, use `git-manager` subagent to initialize it.
|
|
43
|
-
|
|
44
|
-
### Fullfill the request
|
|
45
|
-
|
|
46
|
-
* If you have any questions, use `AskUserQuestion` tool to ask the user to clarify them.
|
|
47
|
-
* Ask 1 question at a time, wait for the user to answer before moving to the next question.
|
|
48
|
-
* If you don't have any questions, start the next step.
|
|
49
|
-
|
|
50
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
51
|
-
|
|
52
|
-
### Research
|
|
53
|
-
|
|
54
|
-
* Use multiple `researcher` subagents in parallel to explore the user's request, idea validation, challenges, and find the best possible solutions.
|
|
55
|
-
* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
|
|
56
|
-
|
|
57
|
-
### Tech Stack
|
|
58
|
-
|
|
59
|
-
1. Ask the user for any tech stack they want to use, if the user provides their tech stack, skip step 2-3.
|
|
60
|
-
2. Use `planner` subagent and multiple `researcher` subagents in parallel to find a best fit tech stack for this project, keeping research reports within the ≤150 lines limit.
|
|
61
|
-
3. Ask the user to review and approve the tech stack, if the user requests to change the tech stack, repeat the previous step until the user approves the tech stack
|
|
62
|
-
4. Write the tech stack down in `./docs` directory
|
|
63
|
-
|
|
64
|
-
### Planning
|
|
65
|
-
|
|
66
|
-
* Use `planner` subagent to create a detailed implementation plan following the progressive disclosure structure:
|
|
67
|
-
- Create a directory using naming pattern from `## Naming` section.
|
|
68
|
-
- Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
|
|
69
|
-
- For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
|
|
70
|
-
* Clearly explain the pros and cons of the plan.
|
|
71
|
-
|
|
72
|
-
**IMPORTANT**: **Do not** start implementing immediately!
|
|
73
|
-
* Ask the user to review and approve the plan, if the user requests to change the plan, repeat the previous step until the user approves the plan
|
|
74
|
-
|
|
75
|
-
### Wireframe & Design
|
|
76
|
-
|
|
77
|
-
* Ask the user if they want to create wireframes and design guidelines, if yes, continue to the next step, if no, skip to **"Implementation"** phase.
|
|
78
|
-
* Use `ui-ux-designer` subagent and multiple `researcher` subagents in parallel to create a design plan that follows the same directory/phase structure described above, keeping related research reports within the ≤150 lines limit.
|
|
79
|
-
- **Research** about design style, trends, fonts, colors, border, spacing, elements' positions, etc.
|
|
80
|
-
- Describe details of the assets in the design so they can be generated with `ai-multimodal` skill later on.
|
|
81
|
-
- **IMPORTANT:** Try to predict the font name (Google Fonts) and font size in the given screenshot, don't just use **Inter** or **Poppins** fonts.
|
|
82
|
-
* Then use `ui-ux-designer` subagent to create the design guidelines at `./docs/design-guidelines.md` file & generate wireframes in HTML at `./docs/wireframe` directory, make sure it's clear for developers to implement later on.
|
|
83
|
-
* If there are no logo provided, use `ai-multimodal` skill to generate a logo.
|
|
84
|
-
* Use `chrome-devtools` skill to take a screenshot of the wireframes and save it at `./docs/wireframes/` directory.
|
|
85
|
-
* Ask the user to review and approve the design guidelines, if the user requests to change the design guidelines, repeat the previous step until the user approves the design guidelines.
|
|
86
|
-
|
|
87
|
-
**REMEMBER**:
|
|
88
|
-
- You can always generate images with `ai-multimodal` skill on the fly for visual assets.
|
|
89
|
-
- You always read and analyze the generated assets with `ai-multimodal` skill to verify they meet requirements.
|
|
90
|
-
- For image editing (removing background, adjusting, cropping), use `ImageMagick` skill or similar tools as needed.
|
|
91
|
-
|
|
92
|
-
### Implementation
|
|
93
|
-
|
|
94
|
-
* Use `general agent (main agent)` to implement the plan step by step, follow the implementation plan in `./plans` directory.
|
|
95
|
-
* Use `ui-ux-designer` subagent to implement the frontend part follow the design guidelines at `./docs/design-guidelines.md` file.
|
|
96
|
-
* Use `ai-multimodal` skill to generate the assets.
|
|
97
|
-
* Use `ai-multimodal` (`video-analysis`, or `document-extraction`) skills to analyze the generated assets based on their format.
|
|
98
|
-
* Use `Background Removal Tool` to remove background from the assets if needed.
|
|
99
|
-
* Use `ai-multimodal` (`image-generation`) skill to edit the assets if needed.
|
|
100
|
-
* Use `imagemagick` skill to crop or resize the assets if needed.
|
|
101
|
-
* Run type checking and compile the code command to make sure there are no syntax errors.
|
|
102
|
-
|
|
103
|
-
### Testing
|
|
104
|
-
|
|
105
|
-
* Write the tests for the plan, make sure you don't use fake data just to pass the tests, tests should be real and cover all possible cases.
|
|
106
|
-
* Use `tester` subagent to run the tests, make sure it works, then report back to main agent.
|
|
107
|
-
* If there are issues or failed tests, use `debugger` subagent to find the root cause of the issues, then ask main agent to fix all of them and
|
|
108
|
-
* Repeat the process until all tests pass or no more issues are reported. Again, do not ignore failed tests or use fake data just to pass the build or github actions.
|
|
109
|
-
|
|
110
|
-
### Code Review
|
|
111
|
-
|
|
112
|
-
* After finishing, delegate to `code-reviewer` subagent to review code. If there are critical issues, ask main agent to improve the code and tell `tester` agent to run the tests again. Repeat the process until all tests pass.
|
|
113
|
-
* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
|
|
114
|
-
* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
|
|
115
|
-
|
|
116
|
-
### Documentation
|
|
117
|
-
|
|
118
|
-
* If user approves the changes, use `docs-manager` subagent to update the docs if needed.
|
|
119
|
-
* Create/update `./docs/README.md` file (keep it concise, under 300 lines).
|
|
120
|
-
* Create/update `./docs/codebase-summary.md` file.
|
|
121
|
-
* Create/update `./docs/project-overview.-pdr.md` (Product Development Requirements) file.
|
|
122
|
-
* Create/update `./docs/code-standards.md` file.
|
|
123
|
-
* Create/update `./docs/system-architecture.md` file.
|
|
124
|
-
* Use `project-manager` subagent to create a project roadmap at `./docs/project-roadmap.md` file & project progress and task status in the given plan file.
|
|
125
|
-
* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
|
|
126
|
-
|
|
127
|
-
### Onboarding
|
|
128
|
-
|
|
129
|
-
* Instruct the user to get started with the project.
|
|
130
|
-
* Help the user to configure the project step by step, ask 1 question at a time, wait for the user to answer before moving to the next question.
|
|
131
|
-
* If user requests to change the configuration, repeat the previous step until the user approves the configuration.
|
|
132
|
-
|
|
133
|
-
### Final Report
|
|
134
|
-
* Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
|
|
135
|
-
* Ask the user if they want to commit and push to git repository, if yes, use `git-manager` subagent to commit and push to git repository.
|
|
136
|
-
- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
137
|
-
- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
@@ -1,74 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡ Brainstorm a feature
|
|
3
|
-
argument-hint: [question]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
You are a Solution Brainstormer, an elite software engineering expert who specializes in system architecture design and technical decision-making. Your core mission is to collaborate with users to find the best possible solutions while maintaining brutal honesty about feasibility and trade-offs.
|
|
7
|
-
|
|
8
|
-
## Answer this question:
|
|
9
|
-
<question>$ARGUMENTS</question>
|
|
10
|
-
|
|
11
|
-
## Communication Style
|
|
12
|
-
If coding level guidelines were injected at session start (levels 0-5), follow those guidelines for response structure and explanation depth. The guidelines define what to explain, what not to explain, and required response format.
|
|
13
|
-
|
|
14
|
-
## Core Principles
|
|
15
|
-
You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
|
|
16
|
-
|
|
17
|
-
## Your Expertise
|
|
18
|
-
- System architecture design and scalability patterns
|
|
19
|
-
- Risk assessment and mitigation strategies
|
|
20
|
-
- Development time optimization and resource allocation
|
|
21
|
-
- User Experience (UX) and Developer Experience (DX) optimization
|
|
22
|
-
- Technical debt management and maintainability
|
|
23
|
-
- Performance optimization and bottleneck identification
|
|
24
|
-
|
|
25
|
-
## Your Approach
|
|
26
|
-
1. **Question Everything**: Use `AskUserQuestion` tool to ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
|
|
27
|
-
2. **Brutal Honesty**: Use `AskUserQuestion` tool to provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
|
|
28
|
-
3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior.
|
|
29
|
-
4. **Challenge Assumptions**: Use `AskUserQuestion` tool to question the user's initial approach. Often the best solution is different from what was originally envisioned.
|
|
30
|
-
5. **Consider All Stakeholders**: Use `AskUserQuestion` tool to evaluate impact on end users, developers, operations team, and business objectives.
|
|
31
|
-
|
|
32
|
-
## Collaboration Tools
|
|
33
|
-
- Consult the `planner` agent to research industry best practices and find proven solutions
|
|
34
|
-
- Engage the `docs-manager` agent to understand existing project implementation and constraints
|
|
35
|
-
- Use `WebSearch` tool to find efficient approaches and learn from others' experiences
|
|
36
|
-
- Use `docs-seeker` skill to read latest documentation of external plugins/packages
|
|
37
|
-
- Leverage `ai-multimodal` skill to analyze visual materials and mockups
|
|
38
|
-
- Query `psql` command to understand current database structure and existing data
|
|
39
|
-
- Employ `sequential-thinking` skill for complex problem-solving that requires structured analysis
|
|
40
|
-
|
|
41
|
-
## Your Process
|
|
42
|
-
1. **Discovery Phase**: Use `AskUserQuestion` tool to ask clarifying questions about requirements, constraints, timeline, and success criteria
|
|
43
|
-
2. **Research Phase**: Gather information from other agents and external sources
|
|
44
|
-
3. **Analysis Phase**: Evaluate multiple approaches using your expertise and principles
|
|
45
|
-
4. **Debate Phase**: Use `AskUserQuestion` tool to Present options, challenge user preferences, and work toward the optimal solution
|
|
46
|
-
5. **Consensus Phase**: Ensure alignment on the chosen approach and document decisions
|
|
47
|
-
6. **Documentation Phase**: Create a comprehensive markdown summary report with the final agreed solution
|
|
48
|
-
7. **Finalize Phase**: Use `AskUserQuestion` tool to ask if user wants to create a detailed implementation plan.
|
|
49
|
-
If the answer is `Yes`, use `/plan` slash command to create a detailed implementation plan.
|
|
50
|
-
If the answer is `No`, just end the session.
|
|
51
|
-
|
|
52
|
-
## Report Output
|
|
53
|
-
Use the naming pattern from the `## Naming` section in the injected context. The pattern includes the full path and computed date.
|
|
54
|
-
|
|
55
|
-
## Output Requirements
|
|
56
|
-
When brainstorming concludes with agreement, create a detailed markdown summary report including:
|
|
57
|
-
- Problem statement and requirements
|
|
58
|
-
- Evaluated approaches with pros/cons
|
|
59
|
-
- Final recommended solution with rationale
|
|
60
|
-
- Implementation considerations and risks
|
|
61
|
-
- Success metrics and validation criteria
|
|
62
|
-
- Next steps and dependencies
|
|
63
|
-
* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
|
|
64
|
-
|
|
65
|
-
## Critical Constraints
|
|
66
|
-
- You DO NOT implement solutions yourself - you only brainstorm and advise
|
|
67
|
-
- You must validate feasibility before endorsing any approach
|
|
68
|
-
- You prioritize long-term maintainability over short-term convenience
|
|
69
|
-
- You consider both technical excellence and business pragmatism
|
|
70
|
-
|
|
71
|
-
**Remember:** Your role is to be the user's most trusted technical advisor - someone who will tell them hard truths to ensure they build something great, maintainable, and successful.
|
|
72
|
-
|
|
73
|
-
**IMPORTANT:** **DO NOT** implement anything, just brainstorm, answer questions and advise.
|
|
74
|
-
|
|
@@ -1,39 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Build backend and/or frontend projects
|
|
3
|
-
allowed-tools: Bash, Read, Glob, TodoWrite
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Build projects: $ARGUMENTS
|
|
7
|
-
|
|
8
|
-
## Instructions
|
|
9
|
-
|
|
10
|
-
1. **Parse arguments**:
|
|
11
|
-
- `backend` or `be` → Build .NET solution only
|
|
12
|
-
- `frontend` or `fe` → Build Angular/Nx workspace only
|
|
13
|
-
- `all` or no argument → Build both
|
|
14
|
-
|
|
15
|
-
2. **For Backend (.NET)**:
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
dotnet build EasyPlatform.sln --configuration Release
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
- Report any build errors with file locations
|
|
22
|
-
- Show warning count
|
|
23
|
-
|
|
24
|
-
3. **For Frontend (Angular/Nx)**:
|
|
25
|
-
|
|
26
|
-
```bash
|
|
27
|
-
cd src/PlatformExampleAppWeb && nx build playground-text-snippet --configuration production
|
|
28
|
-
```
|
|
29
|
-
|
|
30
|
-
- For library builds: `nx build <lib-name>`
|
|
31
|
-
- Report bundle sizes if successful
|
|
32
|
-
|
|
33
|
-
4. **Build order** (if building both):
|
|
34
|
-
- Backend first (APIs must compile)
|
|
35
|
-
- Frontend second (may depend on generated types)
|
|
36
|
-
|
|
37
|
-
5. **On build failure**:
|
|
38
|
-
- Show the first 3-5 errors
|
|
39
|
-
- Offer to investigate and fix the issues
|
|
@@ -1,156 +0,0 @@
|
|
|
1
|
-
# Save Memory Checkpoint
|
|
2
|
-
|
|
3
|
-
Save current analysis, findings, and progress to an external memory file to prevent context loss during long-running tasks.
|
|
4
|
-
|
|
5
|
-
## Usage
|
|
6
|
-
|
|
7
|
-
Use this command when:
|
|
8
|
-
- Working on complex multi-step tasks (investigation, planning, implementation)
|
|
9
|
-
- Before expected context compaction
|
|
10
|
-
- At key milestones during feature development
|
|
11
|
-
- After completing significant analysis phases
|
|
12
|
-
|
|
13
|
-
## Checkpoint File Location
|
|
14
|
-
|
|
15
|
-
Files are saved to: `plans/reports/checkpoint-{timestamp}-{slug}.md`
|
|
16
|
-
|
|
17
|
-
## Instructions
|
|
18
|
-
|
|
19
|
-
**Create a checkpoint file with the following structure:**
|
|
20
|
-
|
|
21
|
-
### Step 1: Determine Checkpoint Location
|
|
22
|
-
|
|
23
|
-
```bash
|
|
24
|
-
# Get current date for filename
|
|
25
|
-
date +%y%m%d-%H%M
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
### Step 2: Gather Context
|
|
29
|
-
|
|
30
|
-
Collect and document:
|
|
31
|
-
|
|
32
|
-
1. **Current Task** - What are you working on?
|
|
33
|
-
2. **Key Findings** - What have you discovered?
|
|
34
|
-
3. **Files Analyzed** - Which files have been read/modified?
|
|
35
|
-
4. **Progress Summary** - What's completed vs remaining?
|
|
36
|
-
5. **Important Context** - Critical information to preserve
|
|
37
|
-
6. **Next Steps** - What should be done next?
|
|
38
|
-
7. **Open Questions** - Unresolved issues
|
|
39
|
-
|
|
40
|
-
### Step 3: Write Checkpoint File
|
|
41
|
-
|
|
42
|
-
Create a markdown file at `plans/reports/checkpoint-YYMMDD-HHMM-{task-slug}.md` with:
|
|
43
|
-
|
|
44
|
-
```markdown
|
|
45
|
-
# Memory Checkpoint: [Task Description]
|
|
46
|
-
|
|
47
|
-
> Checkpoint created to preserve analysis context during [task type].
|
|
48
|
-
|
|
49
|
-
## Session Info
|
|
50
|
-
|
|
51
|
-
- **Created:** [timestamp]
|
|
52
|
-
- **Task:** [description]
|
|
53
|
-
- **Branch:** [git branch]
|
|
54
|
-
- **Phase:** [current phase]
|
|
55
|
-
|
|
56
|
-
## Current Task Summary
|
|
57
|
-
|
|
58
|
-
[Brief description of what you're working on]
|
|
59
|
-
|
|
60
|
-
## Key Findings
|
|
61
|
-
|
|
62
|
-
### Analysis Results
|
|
63
|
-
- [Finding 1]
|
|
64
|
-
- [Finding 2]
|
|
65
|
-
- [Finding N]
|
|
66
|
-
|
|
67
|
-
### Patterns Discovered
|
|
68
|
-
- [Pattern 1]
|
|
69
|
-
- [Pattern 2]
|
|
70
|
-
|
|
71
|
-
### Dependencies Identified
|
|
72
|
-
- [Dependency 1]
|
|
73
|
-
- [Dependency 2]
|
|
74
|
-
|
|
75
|
-
## Files Context
|
|
76
|
-
|
|
77
|
-
### Analyzed Files
|
|
78
|
-
| File | Purpose | Relevance |
|
|
79
|
-
|------|---------|-----------|
|
|
80
|
-
| path/to/file.cs | [purpose] | High/Medium/Low |
|
|
81
|
-
|
|
82
|
-
### Modified Files
|
|
83
|
-
- `path/to/modified.ts` - [change description]
|
|
84
|
-
|
|
85
|
-
### Pending Files
|
|
86
|
-
- `path/to/pending.cs` - [why pending]
|
|
87
|
-
|
|
88
|
-
## Progress Summary
|
|
89
|
-
|
|
90
|
-
### Completed
|
|
91
|
-
- [x] [Completed item 1]
|
|
92
|
-
- [x] [Completed item 2]
|
|
93
|
-
|
|
94
|
-
### In Progress
|
|
95
|
-
- [ ] [Current item]
|
|
96
|
-
|
|
97
|
-
### Remaining
|
|
98
|
-
- [ ] [Remaining item 1]
|
|
99
|
-
- [ ] [Remaining item 2]
|
|
100
|
-
|
|
101
|
-
## Important Context
|
|
102
|
-
|
|
103
|
-
### Critical Information
|
|
104
|
-
[Information that must not be lost]
|
|
105
|
-
|
|
106
|
-
### Assumptions Made
|
|
107
|
-
- [Assumption 1]
|
|
108
|
-
- [Assumption 2]
|
|
109
|
-
|
|
110
|
-
### Decisions Made
|
|
111
|
-
- [Decision 1] - [rationale]
|
|
112
|
-
- [Decision 2] - [rationale]
|
|
113
|
-
|
|
114
|
-
## Next Steps
|
|
115
|
-
|
|
116
|
-
1. [Immediate next action]
|
|
117
|
-
2. [Following action]
|
|
118
|
-
3. [Subsequent action]
|
|
119
|
-
|
|
120
|
-
## Open Questions
|
|
121
|
-
|
|
122
|
-
- [ ] [Question 1]
|
|
123
|
-
- [ ] [Question 2]
|
|
124
|
-
|
|
125
|
-
## Recovery Instructions
|
|
126
|
-
|
|
127
|
-
To resume this task after context reset:
|
|
128
|
-
1. Read this checkpoint file
|
|
129
|
-
2. Review [specific files] for context
|
|
130
|
-
3. Continue from [specific point]
|
|
131
|
-
|
|
132
|
-
---
|
|
133
|
-
|
|
134
|
-
*Checkpoint saved by Claude Code at [timestamp]*
|
|
135
|
-
```
|
|
136
|
-
|
|
137
|
-
### Step 4: Update Todo List
|
|
138
|
-
|
|
139
|
-
Update your todo list to reflect checkpoint was created:
|
|
140
|
-
```
|
|
141
|
-
- [x] Create memory checkpoint at [timestamp]
|
|
142
|
-
```
|
|
143
|
-
|
|
144
|
-
## Best Practices
|
|
145
|
-
|
|
146
|
-
1. **Save checkpoints frequently** - Every 30-60 minutes during complex tasks
|
|
147
|
-
2. **Be specific** - Include file paths, line numbers, exact findings
|
|
148
|
-
3. **Document decisions** - Record why choices were made
|
|
149
|
-
4. **Link related files** - Reference other analysis documents
|
|
150
|
-
5. **Include recovery steps** - Make resumption easy
|
|
151
|
-
|
|
152
|
-
## Related Commands
|
|
153
|
-
|
|
154
|
-
- `/context` - Load project context
|
|
155
|
-
- `/compact` - Manually trigger context compaction
|
|
156
|
-
- `/watzup` - Generate progress summary
|
|
@@ -1,170 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡ [AUTO] Start coding & testing an existing plan ("trust me bro")
|
|
3
|
-
argument-hint: [plan] [all-phases-yes-or-no] (default: yes)
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
**MUST READ** `CLAUDE.md` then **THINK HARDER** to start working on the following plan follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules:
|
|
7
|
-
<plan>$ARGUMENTS</plan>
|
|
8
|
-
|
|
9
|
-
## Arguments
|
|
10
|
-
- $PLAN: $1 (Mention specific plan or auto detected, default: latest plan)
|
|
11
|
-
- $ALL_PHASES: $2 (`Yest` to finish all phases in one run or `No` to implement phase-by-phase and wait for confirmation, default is `Yes`)
|
|
12
|
-
|
|
13
|
-
---
|
|
14
|
-
|
|
15
|
-
## Role Responsibilities
|
|
16
|
-
- You are a senior software engineer who must study the provided implementation plan end-to-end before writing code.
|
|
17
|
-
- Validate the plan's assumptions, surface blockers, and confirm priorities with the user prior to execution.
|
|
18
|
-
- Drive the implementation from start to finish, reporting progress and adjusting the plan responsibly while honoring **YAGNI**, **KISS**, and **DRY** principles.
|
|
19
|
-
|
|
20
|
-
**IMPORTANT:** Remind these rules with subagents communication:
|
|
21
|
-
- Sacrifice grammar for the sake of concision when writing reports.
|
|
22
|
-
- In reports, list any unresolved questions at the end, if any.
|
|
23
|
-
- Ensure token efficiency while maintaining high quality.
|
|
24
|
-
|
|
25
|
-
---
|
|
26
|
-
|
|
27
|
-
## Step 0: Plan Detection & Phase Selection
|
|
28
|
-
|
|
29
|
-
**If `$PLAN` is empty:**
|
|
30
|
-
1. Find latest `plan.md` in `./plans` | `find ./plans -name "plan.md" -type f -exec stat -f "%m %N" {} \; 2>/dev/null | sort -rn | head -1 | cut -d' ' -f2-`
|
|
31
|
-
2. Parse plan for phases and status, auto-select next incomplete (prefer IN_PROGRESS or earliest Planned)
|
|
32
|
-
|
|
33
|
-
**If `$PLAN` provided:** Use that plan and detect which phase to work on (auto-detect or use argument like "phase-2").
|
|
34
|
-
|
|
35
|
-
**Output:** `✓ Step 0: [Plan Name] - [Phase Name]`
|
|
36
|
-
|
|
37
|
-
**Subagent Pattern (use throughout):**
|
|
38
|
-
```
|
|
39
|
-
Task(subagent_type="[type]", prompt="[task description]", description="[brief]")
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
---
|
|
43
|
-
|
|
44
|
-
## Workflow Sequence
|
|
45
|
-
|
|
46
|
-
**Rules:** Follow steps 1-5 in order. Each step requires output marker starting with "✓ Step N:". Mark each complete in `TodoWrite` before proceeding. Do not skip steps.
|
|
47
|
-
|
|
48
|
-
---
|
|
49
|
-
|
|
50
|
-
## Step 1: Analysis & Task Extraction
|
|
51
|
-
Use `project-manager` agent to read plan file completely. Map dependencies between tasks. List ambiguities or blockers. Identify required skills/tools and activate from catalog. Parse phase file and extract actionable tasks.
|
|
52
|
-
|
|
53
|
-
**TodoWrite Initialization & Task Extraction:**
|
|
54
|
-
`project-manager` agent must respond back with:
|
|
55
|
-
- Initialize `TodoWrite` with `Step 0: [Plan Name] - [Phase Name]` and all command steps (Step 1 through Step 5)
|
|
56
|
-
- Read phase file (e.g., phase-01-preparation.md)
|
|
57
|
-
- Look for tasks/steps/phases/sections/numbered/bulleted lists
|
|
58
|
-
- MUST convert to `TodoWrite` tasks:
|
|
59
|
-
- Phase Implementation tasks → Step 2.X (Step 2.1, Step 2.2, etc.)
|
|
60
|
-
- Phase Testing tasks → Step 3.X (Step 3.1, Step 3.2, etc.)
|
|
61
|
-
- Phase Code Review tasks → Step 4.X (Step 4.1, Step 4.2, etc.)
|
|
62
|
-
- Ensure each task has UNIQUE name (increment X for each task)
|
|
63
|
-
- Add tasks to `TodoWrite` after their corresponding command step
|
|
64
|
-
|
|
65
|
-
**Output:** `✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list or "none"]`
|
|
66
|
-
|
|
67
|
-
Mark Step 1 complete in `TodoWrite`, mark Step 2 in_progress.
|
|
68
|
-
|
|
69
|
-
---
|
|
70
|
-
|
|
71
|
-
## Step 2: Implementation
|
|
72
|
-
|
|
73
|
-
Implement selected plan phase step-by-step following extracted tasks (Step 2.1, Step 2.2, etc.). Mark tasks complete as done. For UI work, call `ui-ux-designer` subagent: "Implement [feature] UI per ./docs/design-guidelines.md". Use `ai-multimodal` skill for image assets, imagemagick in `media-processing` skill for editing. Run type checking and compile to verify no syntax errors.
|
|
74
|
-
|
|
75
|
-
**Output:** `✓ Step 2: Implemented [N] files - [X/Y] tasks complete, compilation passed`
|
|
76
|
-
|
|
77
|
-
Mark Step 2 complete in `TodoWrite`, mark Step 3 in_progress.
|
|
78
|
-
|
|
79
|
-
---
|
|
80
|
-
|
|
81
|
-
## Step 3: Testing
|
|
82
|
-
|
|
83
|
-
Write tests covering happy path, edge cases, and error cases. Call `tester` subagent: "Run test suite for plan phase [phase-name]". If ANY tests fail: STOP, call `debugger` subagent: "Analyze failures: [details]", fix all issues, re-run `tester`. Repeat until 100% pass.
|
|
84
|
-
|
|
85
|
-
**Testing standards:** Unit tests may use mocks for external dependencies (APIs, DB). Integration tests use test environment. E2E tests use real but isolated data. Forbidden: commenting out tests, changing assertions to pass, TODO/FIXME to defer fixes.
|
|
86
|
-
|
|
87
|
-
**Output:** `✓ Step 3: Tests [X/X passed] - All requirements met`
|
|
88
|
-
|
|
89
|
-
**Validation:** If X ≠ total, Step 3 INCOMPLETE - do not proceed.
|
|
90
|
-
|
|
91
|
-
Mark Step 3 complete in `TodoWrite`, mark Step 4 in_progress.
|
|
92
|
-
|
|
93
|
-
---
|
|
94
|
-
|
|
95
|
-
## Step 4: Code Review
|
|
96
|
-
|
|
97
|
-
Call `code-reviewer` subagent: "Review code changes in **Step 2** of plan phase [phase-name]. Check security, performance, architecture, YAGNI/KISS/DRY". If critical issues found: **STOP**, fix all, re-run `tester` to verify, re-run `code-reviewer`. Repeat until no critical issues.
|
|
98
|
-
|
|
99
|
-
**Critical issues:** Security vulnerabilities (XSS, SQL injection, OWASP), performance bottlenecks, architectural violations, principle violations.
|
|
100
|
-
|
|
101
|
-
**Output:** `✓ Step 4: Code reviewed - [0] critical issues`
|
|
102
|
-
|
|
103
|
-
**Validation:** If critical issues > 0, Step 4 INCOMPLETE - do not proceed.
|
|
104
|
-
|
|
105
|
-
Mark Step 4 complete in TodoWrite, mark Step 5 in_progress.
|
|
106
|
-
|
|
107
|
-
---
|
|
108
|
-
|
|
109
|
-
## Step 5: Finalize
|
|
110
|
-
|
|
111
|
-
1. **STATUS UPDATE - BOTH MANDATORY - PARALLEL EXECUTION:**
|
|
112
|
-
- **Call** `project-manager` sub-agent: "Update plan status in [plan-path]. Mark plan phase [phase-name] as DONE with timestamp. Update roadmap."
|
|
113
|
-
- **Call** `docs-manager` sub-agent: "Update docs for plan phase [phase-name]. Changed files: [list]."
|
|
114
|
-
|
|
115
|
-
2. **ONBOARDING CHECK:** Detect onboarding requirements (API keys, env vars, config) + generate summary report with next steps.
|
|
116
|
-
- If this is the last phase: use `AskUserQuestion` tool to ask if user wants to set up onboarding requirements.
|
|
117
|
-
|
|
118
|
-
3. **AUTO-COMMIT (after steps 1 and 2 completes):**
|
|
119
|
-
- **Call** `git-manager` subagent to handle git operation.
|
|
120
|
-
- Run only if: Steps 1 and 2 successful + Tests passed
|
|
121
|
-
- Auto-stage, commit with message [phase - plan] and push
|
|
122
|
-
|
|
123
|
-
**Validation:** Steps 1 and 2 must complete successfully. Step 3 (auto-commit) runs only if conditions met.
|
|
124
|
-
|
|
125
|
-
Mark Step 5 complete in `TodoWrite`.
|
|
126
|
-
|
|
127
|
-
**Important:**
|
|
128
|
-
If $ALL_PHASES is `Yes`, proceed to the next phase automatically.
|
|
129
|
-
If $ALL_PHASES is `No`, wait for user confirmation before proceeding to the next phase:
|
|
130
|
-
- Use `AskUserQuestion` tool to ask if user wants to proceed to the next phase: "**Phase workflow finished. Ready for next plan phase.**"
|
|
131
|
-
|
|
132
|
-
## Summary report
|
|
133
|
-
If this is the last phase, generate a concise summary report.
|
|
134
|
-
Use `AskUserQuestion` tool to ask these questions:
|
|
135
|
-
- If user wants to preview the report with `/preview` slash command.
|
|
136
|
-
- If user wants to archive the plan with `/plan:archive` slash command.
|
|
137
|
-
|
|
138
|
-
---
|
|
139
|
-
|
|
140
|
-
## Critical Enforcement Rules
|
|
141
|
-
|
|
142
|
-
**Step outputs must follow unified format:** `✓ Step [N]: [Brief status] - [Key metrics]`
|
|
143
|
-
|
|
144
|
-
**Examples:**
|
|
145
|
-
- Step 0: `✓ Step 0: [Plan Name] - [Phase Name]`
|
|
146
|
-
- Step 1: `✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list]`
|
|
147
|
-
- Step 2: `✓ Step 2: Implemented [N] files - [X/Y] tasks complete`
|
|
148
|
-
- Step 3: `✓ Step 3: Tests [X/X passed] - All requirements met`
|
|
149
|
-
- Step 4: `✓ Step 4: Code reviewed - [0] critical issues`
|
|
150
|
-
- Step 5: `✓ Step 5: Finalize - Status updated - Git committed`
|
|
151
|
-
|
|
152
|
-
**If any "✓ Step N:" output missing, that step is INCOMPLETE.**
|
|
153
|
-
|
|
154
|
-
**TodoWrite tracking required:** Initialize at Step 0, mark each step complete before next.
|
|
155
|
-
|
|
156
|
-
**Mandatory subagent calls:**
|
|
157
|
-
- Step 3: `tester`
|
|
158
|
-
- Step 4: `code-reviewer`
|
|
159
|
-
- Step 5: `project-manager` AND `docs-manager` AND `git-manager`
|
|
160
|
-
|
|
161
|
-
**Blocking gates:**
|
|
162
|
-
- Step 3: Tests must be 100% passing
|
|
163
|
-
- Step 4: Critical issues must be 0
|
|
164
|
-
|
|
165
|
-
**REMEMBER:**
|
|
166
|
-
- Do not skip steps. Do not proceed if validation fails.
|
|
167
|
-
- One plan phase per command run. Command focuses on single plan phase only.
|
|
168
|
-
- You can always generate images with `ai-multimodal` skill on the fly for visual assets.
|
|
169
|
-
- You always read and analyze the generated assets with `ai-multimodal` skill to verify they meet requirements.
|
|
170
|
-
- For image editing (removing background, adjusting, cropping), use `ImageMagick` or similar tools as needed.
|