メニュー
Use when you have an agreed spec or requirements for a multi-step task, before touching code. Turns the spec into a bite-sized, test-driven implementation plan with exact files, code, and commands - then hands off to execution.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | Writing Plans |
| description | Use when you have an agreed spec or requirements for a multi-step task, before touching code. Turns the spec into a bite-sized, test-driven implementation plan with exact files, code, and commands - then hands off to execution. |
Write a complete implementation plan for an engineer who has zero context for this codebase and questionable taste. Document everything: which files to touch for each task, the actual code, how to test it, what to check. Hand them the whole thing as small, ordered tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they're a capable developer who knows almost nothing about this toolset or problem domain, and doesn't know good test design well. The plan is also what a plan-implementer sub-agent will execute one task at a time, so each task must stand on its own.
Announce at start: "I'm using the writing-plans skill to create the implementation plan."
Save plans to: docs/plans/YYYY-MM-DD-<feature-name>.md (use today's date; honor any project preference).
If the spec covers several independent subsystems, it should have been split during brainstorming. If it wasn't, suggest splitting it into one plan per subsystem — each plan should produce working, testable software on its own.
Before defining tasks, map out which files will be created or modified and what each is responsible for. This is where decomposition gets locked in.
A task is the smallest unit that carries its own test cycle and is worth a fresh reviewer's gate. Fold setup, configuration, scaffolding, and docs into the task whose deliverable needs them; split only where a reviewer could meaningfully reject one task while approving its neighbor. Each task ends with an independently testable deliverable.
Each step is one action (2–5 minutes):
Every plan starts with this header:
# [Feature Name] Implementation Plan
> **For implementers:** execute this plan task-by-task with the subagent-driven-development
> skill (preferred) or executing-plans. Steps use checkbox (`- [ ]`) syntax for tracking.
**Goal:** [one sentence — what this builds]
**Architecture:** [2–3 sentences on the approach]
**Tech stack:** [key technologies/libraries]
## Global Constraints
[The spec's project-wide requirements — version floors, dependency limits, naming and copy
rules, platform requirements — one line each, exact values copied verbatim from the spec.
Every task implicitly includes this section.]
---
### Task N: [Component Name]
**Files:**
- Create: `exact/path/to/File.cs`
- Modify: `exact/path/to/Existing.cs:123-145`
- Test: `tests/exact/path/to/FileTests.cs`
**Interfaces:**
- Consumes: [what this task uses from earlier tasks — exact signatures]
- Produces: [what later tasks rely on — exact names, parameter and return types. The
implementer sees only their own task; this block is how they learn neighboring names.]
- [ ] **Step 1: Write the failing test**
```csharp
[Fact]
public void Does_The_Specific_Thing()
{
var result = Subject.Method(input);
Assert.Equal(expected, result);
}
```
- [ ] **Step 2: Run the test, confirm it fails**
Run: [the project's test command for this test]
Expected: FAIL — method not implemented
- [ ] **Step 3: Write the minimal implementation**
```csharp
public static Result Method(Input input) { ... }
```
- [ ] **Step 4: Run the test, confirm it passes**
Run: [the project's test command]
Expected: PASS
- [ ] **Step 5: Commit**
Commit with a clear message (e.g. `feat: add <thing>`).
The code blocks above are illustrative (C#/xUnit). Use whatever language and test framework the project uses, and write each task's real build/test command — an
msbuild__build_*tool for a .NET solution, otherwise the project's configured command viacommand__run. Don't hardcode a framework the project doesn't use.
Every step contains the actual content the engineer needs. These are plan failures — never write them:
After writing the full plan, check it against the spec with fresh eyes:
clearLayers() in Task 3 but clearFullLayers() in Task 7 is a bug.)Fix issues inline. For a large or high-stakes plan, you may dispatch the doc-reviewer agent (dispatch_agent) with the plan path and the spec path, asking it to check completeness, spec alignment, and task decomposition; address what it raises.
After saving the plan, offer the two execution paths:
"Plan complete and saved to
docs/plans/<filename>.md. Two ways to execute:1. Sub-agent driven (recommended) — I work in an isolated worktree and dispatch a fresh implementer sub-agent per task, with a review gate after each. Keeps context lean and cheap.
2. Inline — I execute the tasks myself in this conversation, with checkpoints.
Which would you like?"
open_skill → subagent-driven-development).open_skill → executing-plans).Either way, the work happens in a git worktree — both execution skills set one up via using-git-worktrees first.
Use this when the user wants to draft a third-party vendor or product privacy and security review document for consumer use.
Use to execute an implementation plan yourself, inline in this conversation, with review checkpoints. The simpler alternative to subagent-driven-development - use it for small plans or when the agents feature is off. Works in an isolated git worktree.
Use when implementation is complete and tests pass, to integrate the work. Verifies the build/tests, then presents clear options - merge locally, open a pull request, keep as-is, or discard - and carries out the choice, including cleaning up the git worktree.
Use to execute an implementation plan task-by-task by dispatching a fresh sub-agent per task with a review gate after each. Preferred when the agents feature is on - it keeps the main conversation's context lean and cheap. Works in an isolated git worktree.
Use this before any creative or building work - new features, components, behavior changes, or non-trivial fixes. Explores intent, requirements, and design through dialogue, then writes an agreed spec before any implementation begins.
Use before implementing a plan, to set up an isolated git worktree to work in. Creates a linked worktree under .worktrees/ and changes into it, so the feature's work never touches the main checkout - and a second conversation can work a different feature in parallel.