| name | writing-plans |
| description | Create structured implementation plans for articles, features, or agent tasks. Breaks work into ordered steps with clear acceptance criteria. Used by CEO (strategic plans), EIC (content pipeline planning), and CTO (feature implementation planning). |
Writing Plans
A plan is a work breakdown that lets an agent (or human) execute without ambiguity. Good plans are specific, ordered, and testable.
When to Use
- After brainstorming has produced a recommendation — turn it into executable steps
- When a task is large enough that a single issue would be ambiguous
- Before creating multiple linked issues — the plan defines how they relate
- When the CEO needs to hand complex multi-agent work to EIC or CTO with clear sequencing
Plan Structure
## Plan: {title}
**Goal:** {one sentence — what does success look like?}
**Deadline:** {date or "open"}
**Lead:** {agent or human responsible}
### Steps
1. **{Step name}** — {who does this}
- Input: {what triggers this step or what it needs}
- Action: {what to do, specifically}
- Output: {concrete deliverable — file, issue, PR, comment}
- Acceptance criteria: {how you know it's done}
- Blocks: {step number(s) this must precede}
2. **{Step name}** ...
### Dependencies
{Diagram or list of step→step dependencies if non-sequential}
### Risks
- {risk}: {mitigation}
### Definition of Done
{What does the completed plan's end state look like?}
Planning Principles
Specific over general: "Writer creates src/content/articles/owasp_top10/index.mdx with all frontmatter fields populated" beats "Writer writes the article."
Ordered: steps should have a clear sequence. If two steps can happen in parallel, say so explicitly — don't leave it ambiguous.
Testable acceptance criteria: every step's "done" state should be verifiable without judgment. "PR is open" is testable. "Article is good" is not.
Realistic scope: a plan with 15 steps is probably two plans. If a plan can't be executed in one sprint (one week of agent work), split it.
Name the agents: every step has a responsible party. Plans with "someone should..." fail silently.
For Content Plans (EIC)
The standard 6-stage pipeline is already the default plan for articles. Use writing-plans only for:
- Non-standard articles (requires a new component, a complex translation, special imagery)
- Content campaigns (series of related articles with coordinated publishing)
- Infrastructure articles (require DevOps coordination for demo environments)
Output
The plan is either:
- A comment on the originating issue (for short plans, ≤10 steps)
- A separate issue with the plan as the body (for long plans or plans spawning many sub-issues)
After writing the plan, create the first issue from step 1 and assign it. Do not create all issues upfront — create them as each step becomes ready to work.
