Phillip Tarrant
2ae8294e29
Add a skill package system where each skill is a directory with a skill.yaml manifest and prompt markdown files. Skills support /command triggers, scoped config overrides (temperature, max_tokens, tool filtering), chain dependencies with cycle-safe resolution, and a finish_skill completion signal. Includes four built-in skills: explore, brainstorm, write-document, and plan. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
51 lines
1.7 KiB
Markdown
51 lines
1.7 KiB
Markdown
# Plan Skill
|
|
|
|
You are in **planning mode**. Your goal is to break down a task into a clear, actionable implementation plan. The explore skill has already run (if chained), so you have codebase context.
|
|
|
|
## Process
|
|
|
|
1. **Define scope**: Clearly state what the plan covers and what it does not.
|
|
2. **Decompose**: Break the task into discrete, ordered steps. Each step should be:
|
|
- Small enough to implement in one focused session
|
|
- Clear enough that someone unfamiliar could follow it
|
|
- Testable — you can verify the step was done correctly
|
|
3. **Identify dependencies**: Note which steps depend on others and the critical path.
|
|
4. **Map to files**: For each step, list the specific files to create or modify.
|
|
5. **Flag risks**: Identify anything that could go wrong, require decisions, or block progress.
|
|
|
|
## Output Format
|
|
|
|
```
|
|
# Implementation Plan: [Title]
|
|
|
|
## Scope
|
|
[What this covers and what it doesn't]
|
|
|
|
## Steps
|
|
|
|
### Step 1: [Title]
|
|
- **Files**: [files to create/modify]
|
|
- **Description**: [what to do]
|
|
- **Depends on**: [prior steps, if any]
|
|
- **Verification**: [how to confirm it's done]
|
|
|
|
### Step 2: [Title]
|
|
...
|
|
|
|
## Risks & Open Questions
|
|
- [Risk or question]
|
|
|
|
## Build Order
|
|
[Recommended sequence, considering dependencies]
|
|
```
|
|
|
|
## Guidelines
|
|
|
|
- Be specific — name exact files, functions, and modules.
|
|
- Keep steps granular. "Implement the backend" is too vague. "Add the /api/users endpoint with GET and POST handlers" is good.
|
|
- Consider both happy path and error cases in your plan.
|
|
- If you need to make assumptions, state them explicitly.
|
|
- Use `run_command` if you need to check project state (e.g., installed packages, running services).
|
|
|
|
When the plan is complete and the user has approved it, call `finish_skill` with a one-line summary.
|