メニュー
Use when you have a spec or requirements for a multi-step task, before touching code
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use before any creative work - creating features, building components, adding functionality, or modifying behavior.
Use when implementing new features or applications, or starting complex multi-step tasks that may benefit from structured workflows like brainstorming, TDD, or debugging. NOT for simple questions or straightforward operations.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
Use when executing implementation plans with independent tasks in the current session
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees in <project_root>/.worktrees
| name | writing-plans |
| description | Use when you have a spec or requirements for a multi-step task, before touching code |
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Announce at start: "I'm using the writing-plans skill to create the implementation plan."
Context: This should be run in a dedicated worktree (created by brainstorming skill).
Save plans to: docs/plans/YYYY-MM-DD-<topic>.md
If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
Read these three artifacts before writing anything:
docs/design/YYYY-MM-DD-<topic>-proposal.md) — intent, scope, approach, impactdocs/design/YYYY-MM-DD-<topic>-spec.md) — behavioral requirements with SHALL/MUST/SHOULD and GIVEN/WHEN/THEN scenariosdocs/specs/<domain>.md) — current system behavior for affected domains (may not exist yet)These are your source material. Every task in the plan must trace back to a requirement in the feature spec.
Write the delta spec FIRST, before the file structure and tasks. The delta spec is derived by comparing the feature spec (proposed behavior) against the living spec (current behavior). It declares what behavioral requirements are changing.
Save to: docs/design/YYYY-MM-DD-<topic>-delta.md
Why delta spec before tasks: The delta spec is the behavioral contract. Tasks implement it. Writing tasks first and backfilling the delta spec produces a spec that mirrors the implementation rather than driving it. The delta spec must stand on its own as a complete statement of behavioral change — tasks are the execution plan, not the specification.
# Delta: <Feature Name>
## Domain: <domain-name>
### ADDED Requirements
#### Requirement: <requirement-name>
The system SHALL do something new.
##### Scenario: <scenario-name>
- GIVEN <precondition>
- WHEN <trigger>
- THEN <expected outcome>
### MODIFIED Requirements
#### Requirement: <existing-requirement-name>
##### Scenario: <new-or-changed-scenario>
- GIVEN <precondition>
- WHEN <trigger>
- THEN <expected outcome>
### REMOVED Requirements
#### Requirement: <deprecated-requirement-name>
(Brief explanation of why.)
If the feature touches multiple domains, include a section for each:
# Delta: <Feature Name>
## Domain: auth
### ADDED Requirements
...
## Domain: notifications
### MODIFIED Requirements
...
If the change has no behavioral impact (refactoring, bug fix that doesn't change requirements, performance improvement), declare it explicitly:
# Delta: <Feature Name>
## No Behavioral Changes
<Brief description of the internal change.>
No requirements added, modified, or removed.
The sync step in finishing-a-development-branch skips living spec updates when this is declared.
Map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
Write bite-sized tasks that implement the delta spec. Every task must trace to a requirement in the delta spec.
Each step is one action (2-5 minutes):
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For agentic workers:** REQUIRED SUB-SKILL: Use subagent-driven-development (recommended) or executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach — from proposal]
**Tech Stack:** [Key technologies/libraries]
**Feature spec:** `docs/design/YYYY-MM-DD-<topic>-spec.md`
**Delta spec:** `docs/design/YYYY-MM-DD-<topic>-delta.md`
---
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
**Delta requirement:** [Which ADDED/MODIFIED/REMOVED requirement this task implements]
- [ ] **Step 1: Write the failing test**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
- [ ] **Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"
- [ ] **Step 3: Write minimal implementation**
```python
def function(input):
return expected
```
- [ ] **Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS
- [ ] **Step 5: Commit**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
Every step must contain the actual content an engineer needs. These are plan failures — never write them:
After writing the complete plan and delta spec, look at everything with fresh eyes. This is a checklist you run yourself — not a subagent dispatch.
1. Feature spec coverage (spec → delta): For each requirement in the feature spec, can you point to a corresponding ADDED/MODIFIED/REMOVED entry in the delta spec? List any gaps. A feature spec requirement with no delta entry is a plan failure.
2. Delta coverage (delta → plan): For each ADDED/MODIFIED requirement in the delta spec, can you point to a task with a corresponding failing test? List any gaps. A requirement without a test is a plan failure.
3. Reverse coverage (plan → delta + spec): Does every task in the plan map to something in the delta spec or the feature spec? Tasks that don't map to either are scope creep.
4. Placeholder scan: Search your plan for red flags — any of the patterns from the "No Placeholders" section above. Fix them.
5. Type consistency: Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called clearLayers() in Task 3 but clearFullLayers() in Task 7 is a bug.
If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task. If you find a delta requirement with no test, add the test step.
Dispatch plan reviewer. After the self-review passes, dispatch a read-only subagent using plan-document-reviewer-prompt.md to verify plan completeness and spec alignment. This is required — the self-review catches what you can see, the plan reviewer catches what you miss.
If the reviewer finds issues: Fix the plan, then re-dispatch the reviewer. Loop until the reviewer approves.
Do NOT proceed to the execution handoff until the plan reviewer approves.
After saving the plan and delta spec, ask the user which execution approach to use:
If Subagent-Driven chosen:
If Inline Execution chosen: