thanh-kit 2.5.1 → 2.5.2
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 +20 -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,86 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡ No research. Only analyze and create an implementation plan
|
|
3
|
-
argument-hint: [task]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think.
|
|
7
|
-
Activate `planning` skill.
|
|
8
|
-
|
|
9
|
-
## Your mission
|
|
10
|
-
|
|
11
|
-
<task>
|
|
12
|
-
$ARGUMENTS
|
|
13
|
-
</task>
|
|
14
|
-
|
|
15
|
-
## Pre-Creation Check (Active vs Suggested Plan)
|
|
16
|
-
|
|
17
|
-
Check the `## Plan Context` section in the injected context:
|
|
18
|
-
|
|
19
|
-
- If "Plan:" shows a path → Active plan exists. Ask user: "Continue with this? [Y/n]"
|
|
20
|
-
- If "Suggested:" shows a path → Branch-matched hint only. Ask if they want to activate or create new.
|
|
21
|
-
- If "Plan: none" → Create new plan using naming from `## Naming` section.
|
|
22
|
-
|
|
23
|
-
## Workflow
|
|
24
|
-
|
|
25
|
-
Use `planner` subagent to:
|
|
26
|
-
|
|
27
|
-
1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
|
|
28
|
-
If reusing: Use the active plan path from Plan Context.
|
|
29
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
30
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
31
|
-
3. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
|
|
32
|
-
4. Gathers all information and create an implementation plan of this task.
|
|
33
|
-
5. Ask user to review the plan.
|
|
34
|
-
|
|
35
|
-
## Output Requirements
|
|
36
|
-
|
|
37
|
-
**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
|
|
38
|
-
|
|
39
|
-
```
|
|
40
|
-
{plan-dir}/
|
|
41
|
-
├── reports/
|
|
42
|
-
│ ├── XX-report.md
|
|
43
|
-
│ └── ...
|
|
44
|
-
├── plan.md
|
|
45
|
-
├── phase-XX-phase-name-here.md
|
|
46
|
-
└── ...
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
**Plan File Specification**
|
|
50
|
-
|
|
51
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
52
|
-
|
|
53
|
-
```yaml
|
|
54
|
-
---
|
|
55
|
-
title: "{Brief title}"
|
|
56
|
-
description: "{One sentence for card preview}"
|
|
57
|
-
status: pending
|
|
58
|
-
priority: P2
|
|
59
|
-
effort: {sum of phases, e.g., 4h}
|
|
60
|
-
branch: {current git branch}
|
|
61
|
-
tags: [relevant, tags]
|
|
62
|
-
created: {YYYY-MM-DD}
|
|
63
|
-
---
|
|
64
|
-
```
|
|
65
|
-
|
|
66
|
-
- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status and progress plus links to phase files.
|
|
67
|
-
- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order: Context links (reference parent plan, dependencies, docs), Overview (date, description, priority, implementation status, review status), Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps.
|
|
68
|
-
|
|
69
|
-
## Post-Plan Preview (Optional)
|
|
70
|
-
|
|
71
|
-
After plan creation, offer to open in browser for easier reading.
|
|
72
|
-
|
|
73
|
-
Use `AskUserQuestion` tool:
|
|
74
|
-
- "Open plan in browser for easier reading?" → Yes (Recommended) / No
|
|
75
|
-
|
|
76
|
-
**If user chooses Yes:** Run `/plan:preview {plan-path}` SlashCommand.
|
|
77
|
-
|
|
78
|
-
## Important Notes
|
|
79
|
-
|
|
80
|
-
- **IMPORTANT:** Ensure token consumption efficiency while maintaining high quality.
|
|
81
|
-
- **IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
82
|
-
- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
83
|
-
- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
84
|
-
- **IMPORTANT**: **Do not** start implementing.
|
|
85
|
-
|
|
86
|
-
ultrathink
|
|
@@ -1,103 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡ Research, analyze, and create an implementation plan
|
|
3
|
-
argument-hint: [task]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think harder.
|
|
7
|
-
Activate `planning` skill.
|
|
8
|
-
|
|
9
|
-
## Your mission
|
|
10
|
-
<task>
|
|
11
|
-
$ARGUMENTS
|
|
12
|
-
</task>
|
|
13
|
-
|
|
14
|
-
## Pre-Creation Check (Active vs Suggested Plan)
|
|
15
|
-
|
|
16
|
-
Check the `## Plan Context` section in the injected context:
|
|
17
|
-
- If "Plan:" shows a path → Active plan exists. Ask user: "Continue with this? [Y/n]"
|
|
18
|
-
- If "Suggested:" shows a path → Branch-matched hint only. Ask if they want to activate or create new.
|
|
19
|
-
- If "Plan: none" → Create new plan using naming from `## Naming` section.
|
|
20
|
-
|
|
21
|
-
## Workflow
|
|
22
|
-
1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
|
|
23
|
-
If reusing: Use the active plan path from Plan Context.
|
|
24
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
25
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
26
|
-
3. Use multiple `researcher` agents (max 2 agents) in parallel to research for this task:
|
|
27
|
-
Each agent research for a different aspect of the task and are allowed to perform max 5 tool calls.
|
|
28
|
-
4. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
|
|
29
|
-
**ONLY PERFORM THIS FOLLOWING STEP IF `codebase-summary.md` is not available or older than 3 days**: Use `/scout <instructions>` slash command to search the codebase for files needed to complete the task.
|
|
30
|
-
5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the prompt to create an implementation plan of this task.
|
|
31
|
-
6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
|
|
32
|
-
|
|
33
|
-
## Post-Plan Validation (Optional)
|
|
34
|
-
|
|
35
|
-
After plan creation, offer validation interview to confirm decisions before implementation.
|
|
36
|
-
|
|
37
|
-
**Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:**
|
|
38
|
-
|
|
39
|
-
| Mode | Behavior |
|
|
40
|
-
| -------- | ------------------------------------------------------------------------------- |
|
|
41
|
-
| `prompt` | Ask user: "Validate this plan with a brief interview?" → Yes (Recommended) / No |
|
|
42
|
-
| `auto` | Automatically execute `/plan:validate {plan-path}` |
|
|
43
|
-
| `off` | Skip validation step entirely |
|
|
44
|
-
|
|
45
|
-
**If mode is `prompt`:** Use `AskUserQuestion` tool with options above.
|
|
46
|
-
**If user chooses validation or mode is `auto`:** Execute `/plan:validate {plan-path}` SlashCommand.
|
|
47
|
-
|
|
48
|
-
## Post-Plan Preview (Optional)
|
|
49
|
-
|
|
50
|
-
After plan creation, offer to open in browser for easier reading.
|
|
51
|
-
|
|
52
|
-
Use `AskUserQuestion` tool:
|
|
53
|
-
- "Open plan in browser for easier reading?" → Yes (Recommended) / No
|
|
54
|
-
|
|
55
|
-
**If user chooses Yes:** Run `/plan:preview {plan-path}` SlashCommand.
|
|
56
|
-
|
|
57
|
-
## Output Requirements
|
|
58
|
-
|
|
59
|
-
**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
|
|
60
|
-
```
|
|
61
|
-
{plan-dir}/
|
|
62
|
-
├── research/
|
|
63
|
-
│ ├── researcher-XX-report.md
|
|
64
|
-
│ └── ...
|
|
65
|
-
├── reports/
|
|
66
|
-
│ ├── XX-report.md
|
|
67
|
-
│ └── ...
|
|
68
|
-
├── scout/
|
|
69
|
-
│ ├── scout-XX-report.md
|
|
70
|
-
│ └── ...
|
|
71
|
-
├── plan.md
|
|
72
|
-
├── phase-XX-phase-name-here.md
|
|
73
|
-
└── ...
|
|
74
|
-
```
|
|
75
|
-
|
|
76
|
-
**Research Output Requirements**
|
|
77
|
-
- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
|
|
78
|
-
|
|
79
|
-
**Plan File Specification**
|
|
80
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
81
|
-
```yaml
|
|
82
|
-
---
|
|
83
|
-
title: "{Brief title}"
|
|
84
|
-
description: "{One sentence for card preview}"
|
|
85
|
-
status: pending
|
|
86
|
-
priority: P2
|
|
87
|
-
effort: {sum of phases, e.g., 4h}
|
|
88
|
-
branch: {current git branch}
|
|
89
|
-
tags: [relevant, tags]
|
|
90
|
-
created: {YYYY-MM-DD}
|
|
91
|
-
---
|
|
92
|
-
```
|
|
93
|
-
- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status and progress plus links to phase files.
|
|
94
|
-
- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order: Context links (reference parent plan, dependencies, docs), Overview (date, description, priority, implementation status, review status), Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps.
|
|
95
|
-
|
|
96
|
-
## Important Notes
|
|
97
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
98
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
99
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
100
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
101
|
-
**IMPORTANT**: **Do not** start implementing.
|
|
102
|
-
|
|
103
|
-
ultrathink
|
|
@@ -1,152 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡ Create detailed plan with parallel-executable phases
|
|
3
|
-
argument-hint: [task]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think strategically about parallelization.
|
|
7
|
-
Activate `planning` skill.
|
|
8
|
-
|
|
9
|
-
## Your mission
|
|
10
|
-
|
|
11
|
-
<task>
|
|
12
|
-
$ARGUMENTS
|
|
13
|
-
</task>
|
|
14
|
-
|
|
15
|
-
## Workflow
|
|
16
|
-
|
|
17
|
-
1. Create a directory using naming pattern from `## Naming` section in injected context.
|
|
18
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
19
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
20
|
-
3. Use multiple `researcher` agents (max 2 agents) in parallel to research for this task:
|
|
21
|
-
Each agent research for a different aspect of the task and are allowed to perform max 5 tool calls.
|
|
22
|
-
4. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
|
|
23
|
-
**ONLY PERFORM THIS FOLLOWING STEP IF `codebase-summary.md` is not available or older than 3 days**: Use `/scout <instructions>` slash command to search the codebase for files needed to complete the task.
|
|
24
|
-
5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the prompt to create a parallel-optimized implementation plan.
|
|
25
|
-
6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
|
|
26
|
-
|
|
27
|
-
## Post-Plan Validation (Optional)
|
|
28
|
-
|
|
29
|
-
After plan creation, offer validation interview to confirm decisions before implementation.
|
|
30
|
-
|
|
31
|
-
**Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:**
|
|
32
|
-
|
|
33
|
-
| Mode | Behavior |
|
|
34
|
-
| -------- | ------------------------------------------------------------------------------- |
|
|
35
|
-
| `prompt` | Ask user: "Validate this plan with a brief interview?" → Yes (Recommended) / No |
|
|
36
|
-
| `auto` | Automatically execute `/plan:validate {plan-path}` |
|
|
37
|
-
| `off` | Skip validation step entirely |
|
|
38
|
-
|
|
39
|
-
**If mode is `prompt`:** Use `AskUserQuestion` tool with options above.
|
|
40
|
-
**If user chooses validation or mode is `auto`:** Execute `/plan:validate {plan-path}` SlashCommand.
|
|
41
|
-
|
|
42
|
-
## Special Requirements for Parallel Execution
|
|
43
|
-
|
|
44
|
-
**CRITICAL:** The planner subagent must create phases that:
|
|
45
|
-
|
|
46
|
-
1. **Can be executed independently** - Each phase should be self-contained with no runtime dependencies on other phases
|
|
47
|
-
2. **Have clear boundaries** - No file overlap between phases (each file should only be modified in ONE phase)
|
|
48
|
-
3. **Separate concerns logically** - Group by architectural layer, feature domain, or technology stack
|
|
49
|
-
4. **Minimize coupling** - Phases should communicate through well-defined interfaces only
|
|
50
|
-
5. **Include dependency matrix** - Clearly document which phases must run sequentially vs in parallel
|
|
51
|
-
|
|
52
|
-
**Parallelization Strategy:**
|
|
53
|
-
|
|
54
|
-
- Group frontend/backend/database work into separate phases when possible
|
|
55
|
-
- Separate infrastructure setup from application logic
|
|
56
|
-
- Isolate different feature domains (e.g., auth vs profile vs payments)
|
|
57
|
-
- Split by file type/directory (e.g., components vs services vs models)
|
|
58
|
-
- Create independent test phases per module
|
|
59
|
-
|
|
60
|
-
**Phase Organization Example:**
|
|
61
|
-
|
|
62
|
-
```
|
|
63
|
-
Phase 01: Database Schema (can run independently)
|
|
64
|
-
Phase 02: Backend API Layer (can run independently)
|
|
65
|
-
Phase 03: Frontend Components (can run independently)
|
|
66
|
-
Phase 04: Integration Tests (depends on 01, 02, 03)
|
|
67
|
-
```
|
|
68
|
-
|
|
69
|
-
## Output Requirements
|
|
70
|
-
|
|
71
|
-
**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
|
|
72
|
-
|
|
73
|
-
```
|
|
74
|
-
{plan-dir}/
|
|
75
|
-
├── research/
|
|
76
|
-
│ ├── researcher-XX-report.md
|
|
77
|
-
│ └── ...
|
|
78
|
-
├── reports/
|
|
79
|
-
│ ├── XX-report.md
|
|
80
|
-
│ └── ...
|
|
81
|
-
├── scout/
|
|
82
|
-
│ ├── scout-XX-report.md
|
|
83
|
-
│ └── ...
|
|
84
|
-
├── plan.md
|
|
85
|
-
├── phase-XX-phase-name-here.md
|
|
86
|
-
└── ...
|
|
87
|
-
```
|
|
88
|
-
|
|
89
|
-
**Research Output Requirements**
|
|
90
|
-
|
|
91
|
-
- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
|
|
92
|
-
|
|
93
|
-
**Plan File Specification**
|
|
94
|
-
|
|
95
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
96
|
-
|
|
97
|
-
```yaml
|
|
98
|
-
---
|
|
99
|
-
title: "{Brief title}"
|
|
100
|
-
description: "{One sentence for card preview}"
|
|
101
|
-
status: pending
|
|
102
|
-
priority: P2
|
|
103
|
-
effort: {sum of phases, e.g., 4h}
|
|
104
|
-
branch: {current git branch}
|
|
105
|
-
tags: [relevant, tags]
|
|
106
|
-
created: {YYYY-MM-DD}
|
|
107
|
-
---
|
|
108
|
-
```
|
|
109
|
-
|
|
110
|
-
- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status, progress, parallelization group, and links to phase files.
|
|
111
|
-
- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order:
|
|
112
|
-
- Context links (reference parent plan, dependencies, docs)
|
|
113
|
-
- **Parallelization Info** (which phases can run concurrently, which must wait)
|
|
114
|
-
- Overview (date, description, priority, implementation status, review status)
|
|
115
|
-
- Key Insights
|
|
116
|
-
- Requirements
|
|
117
|
-
- Architecture
|
|
118
|
-
- **Related code files** (MUST be exclusive to this phase - no overlap with other phases)
|
|
119
|
-
- **File Ownership** (explicit list of files this phase owns/modifies)
|
|
120
|
-
- Implementation Steps
|
|
121
|
-
- Todo list
|
|
122
|
-
- Success Criteria
|
|
123
|
-
- **Conflict Prevention** (how this phase avoids conflicts with parallel phases)
|
|
124
|
-
- Risk Assessment
|
|
125
|
-
- Security Considerations
|
|
126
|
-
- Next steps
|
|
127
|
-
|
|
128
|
-
**Main plan.md must include:**
|
|
129
|
-
|
|
130
|
-
- Dependency graph showing which phases can run in parallel
|
|
131
|
-
- Execution strategy (e.g., "Phases 1-3 parallel, then Phase 4")
|
|
132
|
-
- File ownership matrix (which phase owns which files)
|
|
133
|
-
|
|
134
|
-
## Post-Plan Preview (Optional)
|
|
135
|
-
|
|
136
|
-
After plan creation, offer to open in browser for easier reading.
|
|
137
|
-
|
|
138
|
-
Use `AskUserQuestion` tool:
|
|
139
|
-
- "Open plan in browser for easier reading?" → Yes (Recommended) / No
|
|
140
|
-
|
|
141
|
-
**If user chooses Yes:** Run `/plan:preview {plan-path}` SlashCommand.
|
|
142
|
-
|
|
143
|
-
## Important Notes
|
|
144
|
-
|
|
145
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
146
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
147
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
148
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
149
|
-
**IMPORTANT:** Do not start implementing.
|
|
150
|
-
**IMPORTANT:** Each phase MUST have exclusive file ownership - no file can be modified by multiple phases.
|
|
151
|
-
|
|
152
|
-
ultrathink
|
|
@@ -1,40 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: 👁️ Open plan in browser for easy reading
|
|
3
|
-
argument-hint: [plan-path]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Your mission
|
|
7
|
-
|
|
8
|
-
Open the plan preview server to view the plan in a nicely formatted web page.
|
|
9
|
-
|
|
10
|
-
## Workflow
|
|
11
|
-
|
|
12
|
-
1. **Determine plan path:**
|
|
13
|
-
- If `$ARGUMENTS` provided → Use that path
|
|
14
|
-
- If active plan exists in `## Plan Context` → Use that path
|
|
15
|
-
- If neither → Ask user to specify a plan path
|
|
16
|
-
|
|
17
|
-
2. **Start preview server:**
|
|
18
|
-
|
|
19
|
-
```bash
|
|
20
|
-
node .claude/scripts/plan-preview.cjs {plan-path}
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
3. **Inform user:**
|
|
24
|
-
- Browser will open automatically
|
|
25
|
-
- Server runs on `http://localhost:3456`
|
|
26
|
-
- Press `Ctrl+C` in terminal to stop
|
|
27
|
-
|
|
28
|
-
## Example Usage
|
|
29
|
-
|
|
30
|
-
```
|
|
31
|
-
/plan:preview plans/250116-feature-auth
|
|
32
|
-
/plan:preview # Uses active plan from context
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
## Notes
|
|
36
|
-
|
|
37
|
-
- The preview server renders markdown with syntax highlighting
|
|
38
|
-
- Navigation sidebar shows all plan files (plan.md, phases, reports)
|
|
39
|
-
- Server auto-detects plan structure (research/, reports/, scout/ subdirs)
|
|
40
|
-
- Refresh the page to see updated content
|
|
@@ -1,52 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡⚡ Research & create an implementation plan with 2 approaches
|
|
3
|
-
argument-hint: [task]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think harder.
|
|
7
|
-
Activate `planning` skill.
|
|
8
|
-
|
|
9
|
-
## Your mission
|
|
10
|
-
|
|
11
|
-
Use the `planner` subagent to create 2 detailed implementation plans for this following task:
|
|
12
|
-
<task>
|
|
13
|
-
$ARGUMENTS
|
|
14
|
-
</task>
|
|
15
|
-
|
|
16
|
-
## Workflow
|
|
17
|
-
|
|
18
|
-
1. First: Create a directory using naming pattern from `## Naming` section in injected context.
|
|
19
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
20
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
21
|
-
3. Use multiple `researcher` agents in parallel to research for this task, each agent research for a different aspect of the task and perform max 5 researches (max 5 tool calls).
|
|
22
|
-
4. Use `scout` agent to search the codebase for files needed to complete the task.
|
|
23
|
-
5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the detailed instructions prompt to create an implementation plan of this task.
|
|
24
|
-
**Output:** Provide at least 2 implementation approaches with clear trade-offs, and explain the pros and cons of each approach, and provide a recommended approach.
|
|
25
|
-
6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
|
|
26
|
-
|
|
27
|
-
## Plan File Specification
|
|
28
|
-
|
|
29
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
30
|
-
|
|
31
|
-
```yaml
|
|
32
|
-
---
|
|
33
|
-
title: "{Brief title}"
|
|
34
|
-
description: "{One sentence for card preview}"
|
|
35
|
-
status: pending
|
|
36
|
-
priority: P2
|
|
37
|
-
effort: {sum of phases, e.g., 4h}
|
|
38
|
-
branch: {current git branch}
|
|
39
|
-
tags: [relevant, tags]
|
|
40
|
-
created: {YYYY-MM-DD}
|
|
41
|
-
---
|
|
42
|
-
```
|
|
43
|
-
|
|
44
|
-
## Important Notes
|
|
45
|
-
|
|
46
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
47
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
48
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
49
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
50
|
-
**IMPORTANT**: **Do not** start implementing.
|
|
51
|
-
|
|
52
|
-
ultrathink
|
|
@@ -1,132 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Validate plan with critical questions interview
|
|
3
|
-
argument-hint: [plan-path]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Your mission
|
|
7
|
-
|
|
8
|
-
Interview the user with critical questions to validate assumptions, confirm decisions, and surface potential issues in an implementation plan before coding begins.
|
|
9
|
-
|
|
10
|
-
## Plan Resolution
|
|
11
|
-
|
|
12
|
-
1. If `$ARGUMENTS` provided → Use that path
|
|
13
|
-
2. Else check `## Plan Context` section → Use active plan path
|
|
14
|
-
3. If no plan found → Ask user to specify path or run `/plan:hard` first
|
|
15
|
-
|
|
16
|
-
## Configuration (from injected context)
|
|
17
|
-
|
|
18
|
-
Check `## Plan Context` section for validation settings:
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
- `mode` - Controls auto/prompt/off behavior
|
|
22
|
-
- `questions` - Range like `3-8` (min-max)
|
|
23
|
-
|
|
24
|
-
These values are automatically injected from user config. Use them as constraints.
|
|
25
|
-
|
|
26
|
-
## Workflow
|
|
27
|
-
|
|
28
|
-
### Step 1: Read Plan Files
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
Read the plan directory:
|
|
32
|
-
|
|
33
|
-
- `plan.md` - Overview and phases list
|
|
34
|
-
- `phase-*.md` - All phase files
|
|
35
|
-
- Look for decision points, assumptions, risks, tradeoffs
|
|
36
|
-
|
|
37
|
-
### Step 2: Extract Question Topics
|
|
38
|
-
|
|
39
|
-
Scan plan content for:
|
|
40
|
-
|
|
41
|
-
| Category | Keywords to detect |
|
|
42
|
-
| ---------------- | ----------------------------------------------------------------- |
|
|
43
|
-
| **Architecture** | "approach", "pattern", "design", "structure", "database", "API" |
|
|
44
|
-
| **Assumptions** | "assume", "expect", "should", "will", "must", "default" |
|
|
45
|
-
| **Tradeoffs** | "tradeoff", "vs", "alternative", "option", "choice", "either/or" |
|
|
46
|
-
| **Risks** | "risk", "might", "could fail", "dependency", "blocker", "concern" |
|
|
47
|
-
| **Scope** | "phase", "MVP", "future", "out of scope", "nice to have" |
|
|
48
|
-
|
|
49
|
-
### Step 3: Generate Questions
|
|
50
|
-
|
|
51
|
-
For each detected topic, formulate a concrete question:
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
**Question format rules:**
|
|
55
|
-
|
|
56
|
-
- Each question must have 2-4 concrete options
|
|
57
|
-
- Mark recommended option with "(Recommended)" suffix
|
|
58
|
-
- Include "Other" option is automatic - don't add it
|
|
59
|
-
- Questions should surface implicit decisions
|
|
60
|
-
|
|
61
|
-
**Example questions:**
|
|
62
|
-
|
|
63
|
-
```
|
|
64
|
-
Category: Architecture
|
|
65
|
-
Question: "How should the validation results be persisted?"
|
|
66
|
-
Options:
|
|
67
|
-
1. Save to plan.md frontmatter (Recommended) - Updates existing plan
|
|
68
|
-
2. Create validation-answers.md - Separate file for answers
|
|
69
|
-
3. Don't persist - Ephemeral validation only
|
|
70
|
-
```
|
|
71
|
-
|
|
72
|
-
```
|
|
73
|
-
Category: Assumptions
|
|
74
|
-
Question: "The plan assumes API rate limiting is not needed. Is this correct?"
|
|
75
|
-
Options:
|
|
76
|
-
1. Yes, rate limiting not needed for MVP
|
|
77
|
-
2. No, add basic rate limiting now (Recommended)
|
|
78
|
-
3. Defer to Phase 2
|
|
79
|
-
```
|
|
80
|
-
|
|
81
|
-
### Step 4: Interview User
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
Use `AskUserQuestion` tool to present questions.
|
|
85
|
-
|
|
86
|
-
**Rules:**
|
|
87
|
-
|
|
88
|
-
- Use question count from `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`
|
|
89
|
-
- Group related questions when possible (max 4 questions per tool call)
|
|
90
|
-
- Focus on: assumptions, risks, tradeoffs, architecture
|
|
91
|
-
|
|
92
|
-
### Step 5: Document Answers
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
After collecting answers, update the plan:
|
|
96
|
-
|
|
97
|
-
1. Add `## Validation Summary` section to `plan.md`:
|
|
98
|
-
|
|
99
|
-
```markdown
|
|
100
|
-
## Validation Summary
|
|
101
|
-
|
|
102
|
-
**Validated:** {date}
|
|
103
|
-
**Questions asked:** {count}
|
|
104
|
-
|
|
105
|
-
### Confirmed Decisions
|
|
106
|
-
- {decision 1}: {user choice}
|
|
107
|
-
- {decision 2}: {user choice}
|
|
108
|
-
1
|
|
109
|
-
### Action Items
|
|
110
|
-
- [ ] {any changes needed based on answers}
|
|
111
|
-
```
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
1. If answers require plan changes, note them but **do not modify phase files** - just document what needs updating.
|
|
115
|
-
|
|
116
|
-
## Output
|
|
117
|
-
|
|
118
|
-
After validation completes, provide summary:
|
|
119
|
-
|
|
120
|
-
- Number of questions asked
|
|
121
|
-
- Key decisions confirmed
|
|
122
|
-
- Any items flagged for plan revision
|
|
123
|
-
- Recommendation: proceed to implementation or revise plan first
|
|
124
|
-
|
|
125
|
-
## Importa
|
|
126
|
-
nt Notes
|
|
127
|
-
|
|
128
|
-
**IMPORTANT:** Only ask questions about genuine decision points - don't manufacture artificial choices.
|
|
129
|
-
**IMPORTANT:** If plan is simple with few decisions, it's okay to ask fewer than min questions.
|
|
130
|
-
**IMPORTANT:** Prioritize questions that could change implementation significantly.
|
|
131
|
-
|
|
132
|
-
ultrathink
|
|
@@ -1,36 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡ Intelligent plan creation with prompt enhancement
|
|
3
|
-
argument-hint: [task]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Your mission
|
|
7
|
-
|
|
8
|
-
<task>
|
|
9
|
-
$ARGUMENTS
|
|
10
|
-
</task>
|
|
11
|
-
|
|
12
|
-
## Pre-Creation Check (Active vs Suggested Plan Detection)
|
|
13
|
-
|
|
14
|
-
Check the `## Plan Context` section in the injected context:
|
|
15
|
-
|
|
16
|
-
- If "Plan:" shows a path → Active plan exists. Ask user: "Active plan found: {path}. Continue with this? [Y/n]"
|
|
17
|
-
- If "Suggested:" shows a path → Branch-matched plan hint only. Ask user if they want to activate it or create new.
|
|
18
|
-
- If "Plan: none" → Proceed to create new plan using naming pattern from `## Naming` section.
|
|
19
|
-
|
|
20
|
-
## Workflow
|
|
21
|
-
|
|
22
|
-
- Analyze the given task and use `AskUserQuestion` tool to ask for more details if needed.
|
|
23
|
-
- Decide to use `/plan:fast` or `/plan:hard` SlashCommands based on the complexity.
|
|
24
|
-
- Execute SlashCommand: `/plan:fast <detailed-instructions-prompt>` or `/plan:hard <detailed-instructions-prompt>`
|
|
25
|
-
- Activate `planning` skill.
|
|
26
|
-
- Note: `detailed-instructions-prompt` is **an enhanced prompt** that describes the task in detail based on the provided task description.
|
|
27
|
-
|
|
28
|
-
## Important Notes
|
|
29
|
-
|
|
30
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
31
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
32
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
33
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
34
|
-
**IMPORTANT**: **Do not** start implementing.
|
|
35
|
-
|
|
36
|
-
ultrathink
|
package/templates/commands/pr.md
DELETED
|
@@ -1,49 +0,0 @@
|
|
|
1
|
-
# Create Pull Request: $ARGUMENTS
|
|
2
|
-
|
|
3
|
-
Create a pull request with the standard EasyPlatform format.
|
|
4
|
-
|
|
5
|
-
## Steps
|
|
6
|
-
|
|
7
|
-
1. **Check current branch status:**
|
|
8
|
-
- Run `git status` to see all changes
|
|
9
|
-
- Run `git diff` to review modifications
|
|
10
|
-
- Ensure all changes are committed
|
|
11
|
-
|
|
12
|
-
2. **Analyze commits:**
|
|
13
|
-
- Run `git log --oneline -10` to see recent commits
|
|
14
|
-
- Identify all commits to include in the PR
|
|
15
|
-
|
|
16
|
-
3. **Create PR with standard format:**
|
|
17
|
-
```
|
|
18
|
-
gh pr create --title "[Type] Brief description" --body "$(cat <<'EOF'
|
|
19
|
-
## Summary
|
|
20
|
-
- Bullet points describing changes
|
|
21
|
-
|
|
22
|
-
## Changes
|
|
23
|
-
- List of specific changes made
|
|
24
|
-
|
|
25
|
-
## Test Plan
|
|
26
|
-
- [ ] Unit tests added/updated
|
|
27
|
-
- [ ] Manual testing completed
|
|
28
|
-
- [ ] No regressions introduced
|
|
29
|
-
|
|
30
|
-
## Related Issues
|
|
31
|
-
- Closes #issue_number (if applicable)
|
|
32
|
-
|
|
33
|
-
Generated with Claude Code
|
|
34
|
-
EOF
|
|
35
|
-
)"
|
|
36
|
-
```
|
|
37
|
-
|
|
38
|
-
4. **PR Title Format:**
|
|
39
|
-
- `[Feature]` - New functionality
|
|
40
|
-
- `[Fix]` - Bug fix
|
|
41
|
-
- `[Refactor]` - Code improvement
|
|
42
|
-
- `[Docs]` - Documentation only
|
|
43
|
-
- `[Test]` - Test changes only
|
|
44
|
-
|
|
45
|
-
## Notes
|
|
46
|
-
|
|
47
|
-
- Ensure branch is pushed before creating PR
|
|
48
|
-
- Target branch is usually `develop` or `master`
|
|
49
|
-
- Add reviewers if specified in $ARGUMENTS
|