Skip to content
Back to skills

Plan

ASecurity

Author the technical plan for a spec. Phase 3 of the eight-phase workflow. Produces plans/active/<id>-<slug>.md with architecture, data model, API contracts, dependencies, phasing, risks. Delegate to the architect agent. Modeled on github/spec-kit /speckit.plan.

  • 2 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 9, 2026
ai-agentsbashgitapi

Works with

  • api
  • mcp

Security analysis

A100/100

Scanned October 9, 2026

npx -y skills add qyndex/claude-init --skill plan --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Plan?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Plan
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/qyndex-plan/badge)](https://www.skillsdirectory.com/skills/qyndex-plan)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: plan
description: Author the technical plan for a spec. Phase 3 of the eight-phase workflow. Produces plans/active/<id>-<slug>.md with architecture, data model, API contracts, dependencies, phasing, risks. Delegate to the architect agent. Modeled on github/spec-kit /speckit.plan.
when_to_use: A spec is approved and code work is about to begin. User says "plan it", "design the implementation", "how would you build X".
argument-hint: "<spec id>"
model: sonnet
allowed-tools: Read, Write, Edit, Glob, Grep, WebFetch, WebSearch, TodoWrite
---

# Plan

Turn an approved spec into an actionable technical plan.

## Process

1. **Read the spec** (`specs/active/<id>-<slug>.md`). Confirm `status: approved`.
2. **Delegate to the architect** agent. They produce `plans/active/<id>-<slug>.md`.
3. **Review the plan** for completeness against the template at `plans/templates/plan.md`.
4. **Validate against the spec** — every acceptance criterion must map to plan elements.
5. **Mark `status: approved`** when complete.

## Plan must contain

- Reference to the spec (`spec: specs/active/<id>-<slug>.md`)
- **Architecture** — components, data flow, sequence diagrams (mermaid if non-trivial)
- **Data model** — entities, schemas, migrations, indexes
- **API contracts** — endpoints, request/response shapes, error codes, auth
- **Dependencies** — new packages (with version + justification), new services, new MCP servers
- **Phasing** — Phase 1, 2, 3 with exit criteria per phase; each phase must be independently shippable
- **Risks** — known unknowns + mitigations
- **Rollback** — how do we revert if Phase N is bad?
- **Observability** — metrics, logs, traces this change adds
- **References** — every non-obvious decision cites a doc/RFC/file/repo

## Hard rules

- **Smallest viable design.** Don't add abstractions for hypothetical needs.
- **Cite evidence.** Every "we chose X because Y" must reference a doc, benchmark, or precedent.
- **Phases ship.** Phase 1 alone should deliver value, not be "scaffolding".
- **Surface risks.** A risk hidden is a risk multiplied.
- **Decisions become ADRs (gap-audit G39).** Every non-obvious architectural choice in the plan gets an ADR: `bash .claude/scripts/adr-new.sh "<title>" --by architect --subsystem <key>`, then fill Context/Decision/Alternatives. The plan's References section must cite it. A plan whose References cite no ADR while making architecture choices is incomplete — validate.sh fails the repo when active plans exist with an empty decisions store.

## Output

```
plans/active/<id>-<slug>.md   (status: draft → approved)
```

After save: "Plan plans/active/<id>-<slug>.md ready. <N> phases, <M> dependencies. Ready for /tasks."

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.