メニュー
Use when you have a spec or requirements for a multi-step task, before touching code
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | writing-plans |
| description | Use when you have a spec or requirements for a multi-step task, before touching code |
The key point is to ensure that the final implementation does not drift away from the spec, that it stays aligned with the intended use cases.
The plan should be organized around use-case-level integration tests first. Interface/function contracts exist to support the integration test, not to encourage isolated implementation of internal helpers.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good design very well.
Announce at start: "I'm using the writing-plans skill to create the implementation plan."
Context: If working in an isolated worktree, it should have been created via the medium-powers:using-git-worktrees skill at execution time.
Save plans to: docs/medium-powers/plans/YYYY-MM-DD-<feature-name>.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.
Before defining tasks, first map out which folders will be modified and what each folder is responsible for. Read the documents below.
Before writing the plan, perform an existing-flow inventory:
Before creating a new flow, inspect the existing codebase and identify the closest reusable flow. The plan must explain whether the new use case reuses, extends, or intentionally bypasses that flow. Bypassing an existing flow requires explicit justification.
For each use case, define one primary integration test group before defining implementation tasks.
The integration test should:
# [Feature Name] Implementation Plan
## [Use case] use case's title
### Goal
Describe in natural language what exactly needs to be implemented.
### Existing Flow Inventory
existing flow should this feature reuse or extend
### Core structure
You need to clarify detail definition of types/interfaces/functions need to be implemented:
- Core domain models
- DTOs / state shapes
- Interface inputs and outputs
- State transitions
-
such as
```
type ThreadState = {
threadId: string;
title: string | null;
status: RunStatus;
messages: ThreadMessage[];
};
async createThread(params: {id: string...}): Promise<ThreadStoreResult<void>>;
```
Do not rush into implementation. First, make the interfaces clearly express how the flow is connected. Must clearly provide a detailed definition of the capability will be implemented
### Use case map
For each key point, describe the use-case flow with this loop:
```mermaid
flowchart LR
A["Input structure generated after the trigger"] --> B["Function or interface that consumes the structure"]
B --> C["How the input is parsed or used"]
C --> D["Output structure or side effect"]
D --> E{"Does this output or side effect reach the final use-case result?"}
E -- "No: pass it to the next consumer" --> B
E -- "Yes" --> F["Final state, output, or observable side effect that proves the use case worked"]
```
For each loop iteration, make clear the consumed structure, the consumer function or interface, the result structure that consumer output, how the result is consumed next, and which function-level or interface-level capability must be implemented, extend or reused.
- Integration test need to create when exceeding: `/path/to/test.xxx`
natural-language/near-code description(how to make the test work)
During planning, the test may be expressed as near-code to define semantics.
During implementation, the first execution task must turn it into a runnable test or runnable verification before writing production code.
If this would become a negative test, write `Skipped negative test:` and briefly reference only the plan detail that explains why.
> **For agentic workers:** REQUIRED SUB-SKILL: Use medium-powers:subagent-driven-development (recommended) to make the test work
At last ask the user to review the integration test before implementation begins.
After writing the complete plan, review the plan with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.
After saving the plan, offer execution choice:
"Plan complete and saved to docs/medium-powers/plans/<filename>.md. Two execution options:
1. Subagent-Driven (recommended) - I dispatch a fresh subagent per task, review between tasks, fast iteration
2. Inline Execution - Execute tasks in this session using executing-plans, batch execution with checkpoints
Which approach?"
If Subagent-Driven chosen:
If Inline Execution chosen:
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when executing implementation plans with independent tasks in the current session
Use when implementing any feature or bugfix, before writing implementation code
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent and requirements before producing a product-level spec.
Use when you have a written implementation plan to execute in a separate session with review checkpoints