thanh-kit 2.5.4 → 2.5.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/templates/command-archive/ask.md +56 -0
- package/templates/command-archive/ck-help.md +129 -0
- package/templates/command-archive/coding-level.md +48 -0
- 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/command-archive/kanban.md +99 -0
- package/templates/command-archive/plan/archive.md +57 -0
- 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/command-archive/review/codebase.md +49 -0
- package/templates/command-archive/test/ui.md +92 -0
- package/templates/command-archive/test.md +8 -0
- package/templates/command-archive/use-mcp.md +38 -0
- package/templates/command-archive/watzup.md +8 -0
- package/templates/command-archive/worktree.md +109 -0
- package/templates/hooks/.logs/hook-log.jsonl +26 -0
- package/templates/settings.local.json +13 -0
- 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/code/auto.md +0 -203
- package/templates/commands/code/no-test.md +0 -174
- package/templates/commands/code/parallel.md +0 -100
- package/templates/commands/code.md +0 -205
- 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/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.md +0 -105
- 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/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.md +0 -43
- package/templates/commands/plan/ci.md +0 -33
- package/templates/commands/plan/cro.md +0 -69
- package/templates/commands/plan/fast.md +0 -82
- package/templates/commands/plan/hard.md +0 -108
- package/templates/commands/plan/parallel.md +0 -145
- package/templates/commands/plan/two.md +0 -45
- package/templates/commands/plan.md +0 -30
- package/templates/commands/scout/ext.md +0 -39
- package/templates/commands/scout.md +0 -28
- 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/update.md +0 -36
|
@@ -1,82 +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
|
-
<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
|
-
Use `planner` subagent to:
|
|
23
|
-
1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
|
|
24
|
-
If reusing: Use the active plan path from Plan Context.
|
|
25
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
26
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
27
|
-
3. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
|
|
28
|
-
4. Gathers all information and create an implementation plan of this task.
|
|
29
|
-
5. Ask user to review the plan.
|
|
30
|
-
|
|
31
|
-
## Context Reminder (MANDATORY)
|
|
32
|
-
|
|
33
|
-
**IMPORTANT:** After plan creation, you MUST remind the user with the **full absolute path**:
|
|
34
|
-
|
|
35
|
-
> **Best Practice:** Run `/clear` before implementing to start with fresh context.
|
|
36
|
-
> Then run:
|
|
37
|
-
> ```
|
|
38
|
-
> /cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
|
|
39
|
-
> ```
|
|
40
|
-
> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
|
|
41
|
-
|
|
42
|
-
**Why `--auto`?** Fast planning pairs with fast execution - skips review gates.
|
|
43
|
-
**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
|
|
44
|
-
|
|
45
|
-
This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan with the actual absolute path.
|
|
46
|
-
|
|
47
|
-
## Output Requirements
|
|
48
|
-
|
|
49
|
-
**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
|
|
50
|
-
```
|
|
51
|
-
{plan-dir}/
|
|
52
|
-
├── reports/
|
|
53
|
-
│ ├── XX-report.md
|
|
54
|
-
│ └── ...
|
|
55
|
-
├── plan.md
|
|
56
|
-
├── phase-XX-phase-name-here.md
|
|
57
|
-
└── ...
|
|
58
|
-
```
|
|
59
|
-
|
|
60
|
-
**Plan File Specification**
|
|
61
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
62
|
-
```yaml
|
|
63
|
-
---
|
|
64
|
-
title: "{Brief title}"
|
|
65
|
-
description: "{One sentence for card preview}"
|
|
66
|
-
status: pending
|
|
67
|
-
priority: P2
|
|
68
|
-
effort: {sum of phases, e.g., 4h}
|
|
69
|
-
branch: {current git branch}
|
|
70
|
-
tags: [relevant, tags]
|
|
71
|
-
created: {YYYY-MM-DD}
|
|
72
|
-
---
|
|
73
|
-
```
|
|
74
|
-
- 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.
|
|
75
|
-
- 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.
|
|
76
|
-
|
|
77
|
-
## Important Notes
|
|
78
|
-
- **IMPORTANT:** Ensure token consumption efficiency while maintaining high quality.
|
|
79
|
-
- **IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
80
|
-
- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
81
|
-
- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
82
|
-
- **IMPORTANT**: **Do not** start implementing.
|
|
@@ -1,108 +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
|
-
## Context Reminder (MANDATORY)
|
|
49
|
-
|
|
50
|
-
**IMPORTANT:** If user skips validation (chooses "No" or mode is `off`), you MUST remind them with the **full absolute path**:
|
|
51
|
-
|
|
52
|
-
> **Best Practice:** Run `/clear` before implementing to start with fresh context.
|
|
53
|
-
> Then run:
|
|
54
|
-
> ```
|
|
55
|
-
> /cook {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
|
|
56
|
-
> ```
|
|
57
|
-
> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
|
|
58
|
-
|
|
59
|
-
**Why no flag?** Thorough planning without validation needs interactive review gates.
|
|
60
|
-
**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
|
|
61
|
-
|
|
62
|
-
This reminder is **NON-NEGOTIABLE** when validation is skipped - always output with the actual absolute path.
|
|
63
|
-
|
|
64
|
-
## Output Requirements
|
|
65
|
-
|
|
66
|
-
**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
|
|
67
|
-
```
|
|
68
|
-
{plan-dir}/
|
|
69
|
-
├── research/
|
|
70
|
-
│ ├── researcher-XX-report.md
|
|
71
|
-
│ └── ...
|
|
72
|
-
├── reports/
|
|
73
|
-
│ ├── XX-report.md
|
|
74
|
-
│ └── ...
|
|
75
|
-
├── scout/
|
|
76
|
-
│ ├── scout-XX-report.md
|
|
77
|
-
│ └── ...
|
|
78
|
-
├── plan.md
|
|
79
|
-
├── phase-XX-phase-name-here.md
|
|
80
|
-
└── ...
|
|
81
|
-
```
|
|
82
|
-
|
|
83
|
-
**Research Output Requirements**
|
|
84
|
-
- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
|
|
85
|
-
|
|
86
|
-
**Plan File Specification**
|
|
87
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
88
|
-
```yaml
|
|
89
|
-
---
|
|
90
|
-
title: "{Brief title}"
|
|
91
|
-
description: "{One sentence for card preview}"
|
|
92
|
-
status: pending
|
|
93
|
-
priority: P2
|
|
94
|
-
effort: {sum of phases, e.g., 4h}
|
|
95
|
-
branch: {current git branch}
|
|
96
|
-
tags: [relevant, tags]
|
|
97
|
-
created: {YYYY-MM-DD}
|
|
98
|
-
---
|
|
99
|
-
```
|
|
100
|
-
- 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.
|
|
101
|
-
- 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.
|
|
102
|
-
|
|
103
|
-
## Important Notes
|
|
104
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
105
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
106
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
107
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
108
|
-
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -1,145 +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
|
-
<task>
|
|
11
|
-
$ARGUMENTS
|
|
12
|
-
</task>
|
|
13
|
-
|
|
14
|
-
## Workflow
|
|
15
|
-
1. Create a directory using naming pattern from `## Naming` section in injected context.
|
|
16
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
17
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
18
|
-
3. Use multiple `researcher` agents (max 2 agents) in parallel to research for this task:
|
|
19
|
-
Each agent research for a different aspect of the task and are allowed to perform max 5 tool calls.
|
|
20
|
-
4. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
|
|
21
|
-
**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.
|
|
22
|
-
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.
|
|
23
|
-
6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
|
|
24
|
-
|
|
25
|
-
## Post-Plan Validation (Optional)
|
|
26
|
-
|
|
27
|
-
After plan creation, offer validation interview to confirm decisions before implementation.
|
|
28
|
-
|
|
29
|
-
**Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:**
|
|
30
|
-
|
|
31
|
-
| Mode | Behavior |
|
|
32
|
-
|------|----------|
|
|
33
|
-
| `prompt` | Ask user: "Validate this plan with a brief interview?" → Yes (Recommended) / No |
|
|
34
|
-
| `auto` | Automatically execute `/plan:validate {plan-path}` |
|
|
35
|
-
| `off` | Skip validation step entirely |
|
|
36
|
-
|
|
37
|
-
**If mode is `prompt`:** Use `AskUserQuestion` tool with options above.
|
|
38
|
-
**If user chooses validation or mode is `auto`:** Execute `/plan:validate {plan-path}` SlashCommand.
|
|
39
|
-
|
|
40
|
-
## Special Requirements for Parallel Execution
|
|
41
|
-
|
|
42
|
-
**CRITICAL:** The planner subagent must create phases that:
|
|
43
|
-
1. **Can be executed independently** - Each phase should be self-contained with no runtime dependencies on other phases
|
|
44
|
-
2. **Have clear boundaries** - No file overlap between phases (each file should only be modified in ONE phase)
|
|
45
|
-
3. **Separate concerns logically** - Group by architectural layer, feature domain, or technology stack
|
|
46
|
-
4. **Minimize coupling** - Phases should communicate through well-defined interfaces only
|
|
47
|
-
5. **Include dependency matrix** - Clearly document which phases must run sequentially vs in parallel
|
|
48
|
-
|
|
49
|
-
**Parallelization Strategy:**
|
|
50
|
-
- Group frontend/backend/database work into separate phases when possible
|
|
51
|
-
- Separate infrastructure setup from application logic
|
|
52
|
-
- Isolate different feature domains (e.g., auth vs profile vs payments)
|
|
53
|
-
- Split by file type/directory (e.g., components vs services vs models)
|
|
54
|
-
- Create independent test phases per module
|
|
55
|
-
|
|
56
|
-
**Phase Organization Example:**
|
|
57
|
-
```
|
|
58
|
-
Phase 01: Database Schema (can run independently)
|
|
59
|
-
Phase 02: Backend API Layer (can run independently)
|
|
60
|
-
Phase 03: Frontend Components (can run independently)
|
|
61
|
-
Phase 04: Integration Tests (depends on 01, 02, 03)
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
## Output Requirements
|
|
65
|
-
|
|
66
|
-
**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
|
|
67
|
-
```
|
|
68
|
-
{plan-dir}/
|
|
69
|
-
├── research/
|
|
70
|
-
│ ├── researcher-XX-report.md
|
|
71
|
-
│ └── ...
|
|
72
|
-
├── reports/
|
|
73
|
-
│ ├── XX-report.md
|
|
74
|
-
│ └── ...
|
|
75
|
-
├── scout/
|
|
76
|
-
│ ├── scout-XX-report.md
|
|
77
|
-
│ └── ...
|
|
78
|
-
├── plan.md
|
|
79
|
-
├── phase-XX-phase-name-here.md
|
|
80
|
-
└── ...
|
|
81
|
-
```
|
|
82
|
-
|
|
83
|
-
**Research Output Requirements**
|
|
84
|
-
- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
|
|
85
|
-
|
|
86
|
-
**Plan File Specification**
|
|
87
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
88
|
-
```yaml
|
|
89
|
-
---
|
|
90
|
-
title: "{Brief title}"
|
|
91
|
-
description: "{One sentence for card preview}"
|
|
92
|
-
status: pending
|
|
93
|
-
priority: P2
|
|
94
|
-
effort: {sum of phases, e.g., 4h}
|
|
95
|
-
branch: {current git branch}
|
|
96
|
-
tags: [relevant, tags]
|
|
97
|
-
created: {YYYY-MM-DD}
|
|
98
|
-
---
|
|
99
|
-
```
|
|
100
|
-
- 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.
|
|
101
|
-
- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order:
|
|
102
|
-
- Context links (reference parent plan, dependencies, docs)
|
|
103
|
-
- **Parallelization Info** (which phases can run concurrently, which must wait)
|
|
104
|
-
- Overview (date, description, priority, implementation status, review status)
|
|
105
|
-
- Key Insights
|
|
106
|
-
- Requirements
|
|
107
|
-
- Architecture
|
|
108
|
-
- **Related code files** (MUST be exclusive to this phase - no overlap with other phases)
|
|
109
|
-
- **File Ownership** (explicit list of files this phase owns/modifies)
|
|
110
|
-
- Implementation Steps
|
|
111
|
-
- Todo list
|
|
112
|
-
- Success Criteria
|
|
113
|
-
- **Conflict Prevention** (how this phase avoids conflicts with parallel phases)
|
|
114
|
-
- Risk Assessment
|
|
115
|
-
- Security Considerations
|
|
116
|
-
- Next steps
|
|
117
|
-
|
|
118
|
-
**Main plan.md must include:**
|
|
119
|
-
- Dependency graph showing which phases can run in parallel
|
|
120
|
-
- Execution strategy (e.g., "Phases 1-3 parallel, then Phase 4")
|
|
121
|
-
- File ownership matrix (which phase owns which files)
|
|
122
|
-
|
|
123
|
-
## Context Reminder (MANDATORY)
|
|
124
|
-
|
|
125
|
-
**IMPORTANT:** After plan creation, you MUST remind the user with the **full absolute path**:
|
|
126
|
-
|
|
127
|
-
> **Best Practice:** Run `/clear` before implementing to start with fresh context.
|
|
128
|
-
> Then run:
|
|
129
|
-
> ```
|
|
130
|
-
> /cook --parallel {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
|
|
131
|
-
> ```
|
|
132
|
-
> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
|
|
133
|
-
|
|
134
|
-
**Why `--parallel`?** Parallel-optimized plan pairs with parallel execution - multiple agents work on independent phases.
|
|
135
|
-
**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
|
|
136
|
-
|
|
137
|
-
This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan with the actual absolute path.
|
|
138
|
-
|
|
139
|
-
## Important Notes
|
|
140
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
141
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
142
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
143
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
144
|
-
**IMPORTANT:** Do not start implementing.
|
|
145
|
-
**IMPORTANT:** Each phase MUST have exclusive file ownership - no file can be modified by multiple phases.
|
|
@@ -1,45 +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
|
-
Use the `planner` subagent to create 2 detailed implementation plans for this following task:
|
|
11
|
-
<task>
|
|
12
|
-
$ARGUMENTS
|
|
13
|
-
</task>
|
|
14
|
-
|
|
15
|
-
## Workflow
|
|
16
|
-
1. First: Create a directory using naming pattern from `## Naming` section in injected context.
|
|
17
|
-
Make sure you pass the directory path to every subagent during the process.
|
|
18
|
-
2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
|
|
19
|
-
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).
|
|
20
|
-
4. Use `scout` agent to search the codebase for files needed to complete the task.
|
|
21
|
-
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.
|
|
22
|
-
**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.
|
|
23
|
-
1. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
|
|
24
|
-
|
|
25
|
-
## Plan File Specification
|
|
26
|
-
- Every `plan.md` MUST start with YAML frontmatter:
|
|
27
|
-
```yaml
|
|
28
|
-
---
|
|
29
|
-
title: "{Brief title}"
|
|
30
|
-
description: "{One sentence for card preview}"
|
|
31
|
-
status: pending
|
|
32
|
-
priority: P2
|
|
33
|
-
effort: {sum of phases, e.g., 4h}
|
|
34
|
-
branch: {current git branch}
|
|
35
|
-
tags: [relevant, tags]
|
|
36
|
-
created: {YYYY-MM-DD}
|
|
37
|
-
---
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
## Important Notes
|
|
41
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
42
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
43
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
44
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
45
|
-
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -1,30 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡⚡ Intelligent plan creation with prompt enhancement
|
|
3
|
-
argument-hint: [task]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Your mission
|
|
7
|
-
<task>
|
|
8
|
-
$ARGUMENTS
|
|
9
|
-
</task>
|
|
10
|
-
|
|
11
|
-
## Pre-Creation Check (Active vs Suggested Plan Detection)
|
|
12
|
-
|
|
13
|
-
Check the `## Plan Context` section in the injected context:
|
|
14
|
-
- If "Plan:" shows a path → Active plan exists. Ask user: "Active plan found: {path}. Continue with this? [Y/n]"
|
|
15
|
-
- If "Suggested:" shows a path → Branch-matched plan hint only. Ask user if they want to activate it or create new.
|
|
16
|
-
- If "Plan: none" → Proceed to create new plan using naming pattern from `## Naming` section.
|
|
17
|
-
|
|
18
|
-
## Workflow
|
|
19
|
-
- Analyze the given task and use `AskUserQuestion` tool to ask for more details if needed.
|
|
20
|
-
- Decide to use `/plan:fast` or `/plan:hard` SlashCommands based on the complexity.
|
|
21
|
-
- Execute SlashCommand: `/plan:fast <detailed-instructions-prompt>` or `/plan:hard <detailed-instructions-prompt>`
|
|
22
|
-
- Activate `planning` skill.
|
|
23
|
-
- Note: `detailed-instructions-prompt` is **an enhanced prompt** that describes the task in detail based on the provided task description.
|
|
24
|
-
|
|
25
|
-
## Important Notes
|
|
26
|
-
**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
|
|
27
|
-
**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
28
|
-
**IMPORTANT:** Ensure token efficiency while maintaining high quality.
|
|
29
|
-
**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
30
|
-
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -1,39 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡ Use external agentic tools to scout given directories
|
|
3
|
-
argument-hint: [user-prompt] [scale]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Purpose
|
|
7
|
-
|
|
8
|
-
Utilize external agentic tools to scout given directories or explore the codebase for files needed to complete the task using a fast, token efficient agent.
|
|
9
|
-
|
|
10
|
-
## Variables
|
|
11
|
-
|
|
12
|
-
USER_PROMPT: $1
|
|
13
|
-
SCALE: $2 (defaults to 3)
|
|
14
|
-
RELEVANT_FILE_OUTPUT_DIR: Use `Report:` from `## Naming` section
|
|
15
|
-
|
|
16
|
-
## Configuration
|
|
17
|
-
|
|
18
|
-
Read Gemini model from `.claude/.ck.json`: `gemini.model` (default: `gemini-3-flash-preview`)
|
|
19
|
-
|
|
20
|
-
## Workflow:
|
|
21
|
-
- Write a prompt for 'SCALE' number of agents to the `Task` tool that will immediately call the `Bash` tool to run these commands to kick off your agents to conduct the search:
|
|
22
|
-
- `gemini -y -m <gemini.model> "[prompt]"` (if count <= 3)
|
|
23
|
-
- `opencode run "[prompt]" --model opencode/grok-code` (if count > 3 and count < 6)
|
|
24
|
-
- if count >= 6, spawn `Explore` subagents to search the codebase in parallel
|
|
25
|
-
|
|
26
|
-
**Why use external agentic tools?**
|
|
27
|
-
- External agentic tools are faster and more efficient when using LLMs with large context windows (1M+ tokens).
|
|
28
|
-
|
|
29
|
-
**How to prompt the agents:**
|
|
30
|
-
- If `gemini` or `opencode` is not available, ask the user if they want to install it:
|
|
31
|
-
- If **yes**, install it (if there are permission issues, instruct the user to install it manually, including authentication steps)
|
|
32
|
-
- If **no**, use the default `Explore` subagents.
|
|
33
|
-
- IMPORTANT: Kick these agents off in parallel using the `Task` tool, analyze and divide folders for each agent to scout intelligently and quickly.
|
|
34
|
-
- IMPORTANT: These agents are calling OTHER agentic coding tools to search the codebase. DO NOT call any search tools yourself.
|
|
35
|
-
- IMPORTANT: That means with the `Task` tool, you'll immediately call the Bash tool to run the respective agentic coding tool (gemini, opencode, claude, etc.)
|
|
36
|
-
- IMPORTANT: Instruct the agents to quickly search the codebase for files needed to complete the task. This isn't about a full blown search, just a quick search to find the files needed to complete the task.
|
|
37
|
-
- Instruct the subagent to use a timeout of 3 minutes for each agent's bash call. Skip any agents that don't return within the timeout, don't restart them.
|
|
38
|
-
- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
39
|
-
- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
@@ -1,28 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: ⚡⚡ Scout given directories to respond to the user's requests
|
|
3
|
-
argument-hint: [user-prompt] [scale]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
## Purpose
|
|
7
|
-
|
|
8
|
-
Search the codebase for files needed to complete the task using a fast, token efficient agent.
|
|
9
|
-
|
|
10
|
-
## Variables
|
|
11
|
-
|
|
12
|
-
USER_PROMPT: $1
|
|
13
|
-
SCALE: $2 (defaults to 3)
|
|
14
|
-
REPORT_OUTPUT_DIR: Use `Report:` from `## Naming` section
|
|
15
|
-
|
|
16
|
-
## Workflow:
|
|
17
|
-
|
|
18
|
-
- Write a prompt for 'SCALE' number of agents to the `Task` tool that will immediately call the `Bash` tool to run these commands to kick off your agents to conduct the search: spawn many `Explore` subagents to search the codebase in parallel based on the user's prompt.
|
|
19
|
-
|
|
20
|
-
**How to prompt the agents:**
|
|
21
|
-
- IMPORTANT: Kick these agents off in parallel using the `Task` tool, analyze and divide folders for each agent to scout intelligently and quickly.
|
|
22
|
-
- IMPORTANT: Instruct the agents to quickly search the codebase for files needed to complete the task. This isn't about a full blown search, just a quick search to find the files needed to complete the task.
|
|
23
|
-
- Instruct the subagent to use a timeout of 3 minutes for each agent's bash call. Skip any agents that don't return within the timeout, don't restart them.
|
|
24
|
-
|
|
25
|
-
**How to write reports:**
|
|
26
|
-
|
|
27
|
-
- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
|
|
28
|
-
- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
|
|
@@ -1,36 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Add new reference files or scripts to a skill
|
|
3
|
-
argument-hint: [skill-name] [reference-or-script-prompt]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think harder.
|
|
7
|
-
Use `skill-creator` skill and `claude-code-guide` subagent.
|
|
8
|
-
Use `docs-seeker` skills to search for documentation if needed.
|
|
9
|
-
|
|
10
|
-
## Arguments
|
|
11
|
-
$1: skill name (required, default: "")
|
|
12
|
-
$2: reference or script prompt (required, default: "")
|
|
13
|
-
If $1 or $2 is not provided, ask the user to provide it.
|
|
14
|
-
|
|
15
|
-
## Your mission
|
|
16
|
-
Add new reference files or scripts to a skill at `.claude/skills/$1` directory.
|
|
17
|
-
|
|
18
|
-
## Requirements
|
|
19
|
-
<reference-or-script-prompt>
|
|
20
|
-
$2
|
|
21
|
-
</reference-or-script-prompt>
|
|
22
|
-
|
|
23
|
-
## Rules of Skill Creation:
|
|
24
|
-
Base on the requirements:
|
|
25
|
-
- Always keep in mind that `SKILL.md` and reference files should be token consumption efficient, so that **progressive disclosure** can be leveraged at best.
|
|
26
|
-
- `SKILL.md` is always short and concise, straight to the point, treat it as a quick reference guide.
|
|
27
|
-
- If you're given nothing, use `AskUserQuestion` tool for clarifications and `researcher` subagent to research about the topic.
|
|
28
|
-
- If you're given an URL, it's documentation page, use `Explore` subagent to explore every internal link and report back to main agent, don't skip any link.
|
|
29
|
-
- If you receive a lot of URLs, use multiple `Explore` subagents to explore them in parallel, then report back to main agent.
|
|
30
|
-
- If you receive a lot of files, use multiple `Explore` subagents to explore them in parallel, then report back to main agent.
|
|
31
|
-
- If you're given a Github URL, use [`repomix`](https://repomix.com/guide/usage) command to summarize ([install it](https://repomix.com/guide/installation) if needed) and spawn multiple `Explore` subagents to explore it in parallel, then report back to main agent.
|
|
32
|
-
|
|
33
|
-
**IMPORTANT:**
|
|
34
|
-
- Skills are not documentation, they are practical instructions for Claude Code to use the tools, packages, plugins or APIs to achieve the tasks.
|
|
35
|
-
- Each skill teaches Claude how to perform a specific development task, not what a tool does.
|
|
36
|
-
- Claude Code can activate multiple skills automatically to achieve the user's request.
|
|
@@ -1,29 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create a new agent skill
|
|
3
|
-
argument-hint: [prompt-or-llms-or-github-url]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Ultrathink.
|
|
7
|
-
Use `skill-creator` skill and `claude-code-guide` subagent.
|
|
8
|
-
Use `docs-seeker` skills to search for documentation if needed.
|
|
9
|
-
|
|
10
|
-
## Your mission
|
|
11
|
-
Create a new skill in `.claude/skills/` directory.
|
|
12
|
-
|
|
13
|
-
## Requirements
|
|
14
|
-
<user-prompt>$ARGUMENTS</user-prompt>
|
|
15
|
-
|
|
16
|
-
## Rules of Skill Creation:
|
|
17
|
-
Base on the requirements:
|
|
18
|
-
- Always keep in mind that `SKILL.md` and reference files should be token consumption efficient, so that **progressive disclosure** can be leveraged at best.
|
|
19
|
-
- `SKILL.md` is always short and concise, straight to the point, treat it as a quick reference guide.
|
|
20
|
-
- If you're given nothing, use `AskUserQuestion` tool for clarifications and `researcher` subagent to research about the topic.
|
|
21
|
-
- If you're given an URL, it's documentation page, use `Explore` subagent to explore every internal link and report back to main agent, don't skip any link.
|
|
22
|
-
- If you receive a lot of URLs, use multiple `Explore` subagents to explore them in parallel, then report back to main agent.
|
|
23
|
-
- If you receive a lot of files, use multiple `Explore` subagents to explore them in parallel, then report back to main agent.
|
|
24
|
-
- If you're given a Github URL, use [`repomix`](https://repomix.com/guide/usage) command to summarize ([install it](https://repomix.com/guide/installation) if needed) and spawn multiple `Explore` subagents to explore it in parallel, then report back to main agent.
|
|
25
|
-
|
|
26
|
-
**IMPORTANT:**
|
|
27
|
-
- Skills are not documentation, they are practical instructions for Claude Code to use the tools, packages, plugins or APIs to achieve the tasks.
|
|
28
|
-
- Each skill teaches Claude how to perform a specific development task, not what a tool does.
|
|
29
|
-
- Claude Code can activate multiple skills automatically to achieve the user's request.
|
|
@@ -1,22 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Fix the agent skill based on `logs.txt` file.
|
|
3
|
-
argument-hint: [prompt-or-path-to-skill]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think harder.
|
|
7
|
-
Use `skill-creator` skill and `claude-code-guide` subagent.
|
|
8
|
-
Use `docs-seeker` skills to search for documentation if needed.
|
|
9
|
-
|
|
10
|
-
## Your mission
|
|
11
|
-
Fix the agent skill based on the current `logs.txt` file (in the project root directory).
|
|
12
|
-
|
|
13
|
-
## Requirements
|
|
14
|
-
<user-prompt>$ARGUMENTS</user-prompt>
|
|
15
|
-
|
|
16
|
-
## Rules of Skill Fixing:
|
|
17
|
-
Base on the requirements:
|
|
18
|
-
- If you're given nothing, use `AskUserQuestion` tool for clarifications and `researcher` subagent to research about the topic.
|
|
19
|
-
- If you're given an URL, it's documentation page, use `Explorer` subagent to explore every internal link and report back to main agent, don't skip any link.
|
|
20
|
-
- If you receive a lot of URLs, use multiple `Explorer` subagents to explore them in parallel, then report back to main agent.
|
|
21
|
-
- If you receive a lot of files, use multiple `Explorer` subagents to explore them in parallel, then report back to main agent.
|
|
22
|
-
- If you're given a Github URL, use [`repomix`](https://repomix.com/guide/usage) command to summarize ([install it](https://repomix.com/guide/installation) if needed) and spawn multiple `Explorer` subagents to explore it in parallel, then report back to main agent.
|
|
@@ -1,25 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Optimize an existing agent skill [auto]
|
|
3
|
-
argument-hint: [skill-name] [prompt]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think harder.
|
|
7
|
-
Use `skill-creator` skill and `claude-code-guide` subagent.
|
|
8
|
-
Use `docs-seeker` skills to search for documentation if needed.
|
|
9
|
-
|
|
10
|
-
## Arguments
|
|
11
|
-
SKILL: $1 (default: `*`)
|
|
12
|
-
PROMPT: $2 (default: empty)
|
|
13
|
-
|
|
14
|
-
## Your mission
|
|
15
|
-
Optimize an existing skill in `.claude/skills/${SKILL}` directory.
|
|
16
|
-
Always keep in mind that `SKILL.md` and reference files should be token consumption efficient, so that **progressive disclosure** can be leveraged at best.
|
|
17
|
-
`SKILL.md` is always short and concise, straight to the point, treat it as a quick reference guide.
|
|
18
|
-
|
|
19
|
-
**IMPORTANT:**
|
|
20
|
-
- Skills are not documentation, they are practical instructions for Claude Code to use the tools, packages, plugins or APIs to achieve the tasks.
|
|
21
|
-
- Each skill teaches Claude how to perform a specific development task, not what a tool does.
|
|
22
|
-
- Claude Code can activate multiple skills automatically to achieve the user's request.
|
|
23
|
-
|
|
24
|
-
## Additional instructions
|
|
25
|
-
<additional-instructions>$PROMPT</additional-instructions>
|
|
@@ -1,34 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Optimize an existing agent skill
|
|
3
|
-
argument-hint: [skill-name] [prompt]
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
Think harder.
|
|
7
|
-
Use `skill-creator` skill and `claude-code-guide` subagent.
|
|
8
|
-
Use `docs-seeker` skills to search for documentation if needed.
|
|
9
|
-
|
|
10
|
-
## Arguments
|
|
11
|
-
SKILL: $1 (default: `*`)
|
|
12
|
-
PROMPT: $2 (default: empty)
|
|
13
|
-
|
|
14
|
-
## Your mission
|
|
15
|
-
Propose a plan to optimize an existing skill in `.claude/skills/${SKILL}` directory.
|
|
16
|
-
When you finish, ask user to review your plan:
|
|
17
|
-
- If the user approve: Write down a plan follow "Output Requirements", then ask user if they want to start implementing.
|
|
18
|
-
- If the user reject: Revise the plan or ask more questions to clarify more about the user's request (ask one question at the time), then repeat the review process.
|
|
19
|
-
|
|
20
|
-
## Additional instructions
|
|
21
|
-
<additional-instructions>$PROMPT</additional-instructions>
|
|
22
|
-
|
|
23
|
-
## Output Requirements
|
|
24
|
-
An output implementation plan must also follow the progressive disclosure structure:
|
|
25
|
-
- Always keep in mind that `SKILL.md` and reference files should be token consumption efficient, so that **progressive disclosure** can be leveraged at best.
|
|
26
|
-
- `SKILL.md` is always short and concise, straight to the point, treat it as a quick reference guide.
|
|
27
|
-
- Create a directory using naming pattern from `## Naming` section.
|
|
28
|
-
- Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
|
|
29
|
-
- 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).
|
|
30
|
-
|
|
31
|
-
**IMPORTANT:**
|
|
32
|
-
- Skills are not documentation, they are practical instructions for Claude Code to use the tools, packages, plugins or APIs to achieve the tasks.
|
|
33
|
-
- Each skill teaches Claude how to perform a specific development task, not what a tool does.
|
|
34
|
-
- Claude Code can activate multiple skills automatically to achieve the user's request.
|