Applied when an AI agent writesplanssuch as design, implementation, migration, and phased rollout.
Trigger conditions
Read this skill if any of the following applies.
| Situation | Example |
|---|---|
| Plan creation | Implementation plan, migration plan, rollout plan, phase splitting |
| Design proposal | Architecture proposal, technology selection, trade-off organization |
| Plan mode | SwitchMode Output after switching to plan with |
| GitHub posting | Before and after pasting a plan into an issue / PR comment |
How to read through
- Whether specialized terms are needed is determined by references/term-glossary.md determined by
- Footnote notation follows references/footnote-formats.md follows
Structural policy
- Choose headings and blocks according to the purpose and scale of the plan. No fixed template is enforced.
Writing style
- Concise. Noun-ending style is acceptable.
- Prefer tables と mermaid over long lists
- Do not write the same information in both paragraphs and tables.
mermaid diagram type
| Purpose | Diagram type | Example |
|---|---|---|
| Component relationships | flowchart |
Service splitting, data flow |
| Time series | sequenceDiagram |
API calls, authorization flow |
| State transitions | stateDiagram-v2 |
Job states, deployment stages |
| Parallel phases | gantt |
Milestones |
Anti-patterns
- Writing phases only as numbered long text
- Duplicating the same content in an overview table and body paragraphs
- Placing only a one-line description under every heading (consolidate into a table)
- Drawing unverified mermaid at an overly detailed granularity
Footnote policy
| Category | Handling |
|---|---|
| Standard IT terms | No footnote needed. Plain text even on first occurrence. |
| Product-specific / niche | Footnote only on first occurrence |
| GitHub posting (issue description / comment, etc.) | Convert notation to GitHub footnotes [^n] convert to |
For details on determination and the vocabulary list, see references/term-glossary.md. For rules by notation, conversion, and output destination, see references/footnote-formats.md。
Final check
- Are tables or mermaid central to the plan?
- Are there unnecessary footnotes on standard terms?
- Are there first-occurrence footnotes on product-specific terms?
- Is the notation appropriate for the output destination? (Cursor=HTML / local MD=
[^label]/ GitHub=[^n]) - Have footnotes been converted before posting to GitHub?