Agent skill

Plan

by swingerman in swingerman/engineer

A skill your agent uses when a feature has ACs and specs and needs an architecture plan before implementation.

MITAuto-check passed

Install Plan

skills CLI
$ npx skills add swingerman/engineer --skill plan -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install swingerman/engineer plan --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/swingerman/engineer.git skills-src && mkdir -p .claude/skills && cp -r skills-src/engineer/skills/plan .claude/skills/plan && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
plan
GitHub stars
154
Token cost
~2.5k tokens
SKILL.md length
1,300 words
Files
2 (incl. references)
Skills in repo
27
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when a feature has ACs and specs and needs an architecture plan before implementation.

  • Works in 8 steps: Resolve + load — resolve the methodology… → Propose the architecture — draft only… → Draft the rest — draft the remaining… → …
  • A feature has ACs and specs and needs an architecture plan before implementation
  • SKILL.md covers When to use, Workflow, Handoff and References
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Plan is an agent skill from swingerman/engineer. Use when a feature has ACs and specs and needs an architecture plan before implementation. Triggers — "/engineer.plan", "plan this feature", "plan the implementation", "design the architecture".

Its SKILL.md is about 2.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files, including reference files (for example `references/runbook-template.md`).

The repository describes itself as: Disciplined Agentic Engineering — a methodology kit for Claude Code: acceptance-test-first specs, explicit checkpoints, and autonomy you can actually leave running. The engineer… The licence is MIT.

When your agent uses it

  • A feature has ACs and specs and needs an architecture plan before implementation
  • — /engineer.plan
  • Plan this feature
  • Plan the implementation

Example prompts

  • “/engineer.plan”
  • “plan this feature”
  • “plan the implementation”
  • “/plan”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Resolve + load — resolve the methodology root + manifest via ${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md)…
  2. Propose the architecture — draft only the Architecture section (components, data flow, where new code lives, coupling, key decisions +…
  3. Draft the rest — draft the remaining sections. When gate_profile is absent, the human confirms Step 2's architecture first, then reviews…
  4. Charter Check — validate the plan against CHARTER.md. Produce the two-part structured check: a compliance table (one row per charter rule…
  5. Write plan.md — frontmatter (slug, checkpoint: 4, plan_status, created) + sections: Architecture, Charter Check, Phasing, Performance…
  6. Review panel — dispatch the standing adviser + advocate pair against plan.md per ${CLAUDE_PLUGIN_ROOT}/references/review-panel.md. This is…
  7. Generate runbook.md if the plan touches infra/operator steps — provisioning (cloud project create, billing link, API enablement), secrets…
  8. Handoff — emit a summary.

What it can do on your machine

Read from SKILL.md and the folder at commit 32947eb. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • notion.so

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Plan loads about 2.5k tokens when it runs, and up to ~3.6k if it reads all its reference files. Until then it costs about 50 tokens; SKILL.md has 1,300 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~50
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~3.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from swingerman/engineer at commit 32947eb, republished under its MIT licence (© swingerman). 1,300 words, ~2,548 tokens.

Download SKILL.mdSave it as .claude/skills/plan/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
plan
description
Use when a feature has ACs and specs and needs an architecture plan before implementation. Triggers — "/engineer.plan", "plan this feature", "plan the implementation", "design the architecture".

plan

Produce a feature's architecture plan — Checkpoint 4, the most consequential architectural checkpoint. Where engineering authority over code design and performance is exercised: the agent proposes, the human decides.

Mixed mode — the agent proposes the architecture, the human confirms it, then the rest of the plan is drafted.

When to use

After discover-acs (Checkpoint 2) and atdd:atdd (Checkpoint 3). Produces plan.md.

If spec.md is missing, warn — planning should follow spec formalization — but the user may override and plan from acs.md alone (flag the skipped step in the handoff).

Not for: Given/When/Then specs (atdd:atdd); small changes to an existing plan (feature-edit).

Workflow

Step 0 — Entry gate. Before starting, verify the prior checkpoint is complete: run ${CLAUDE_PLUGIN_ROOT}/scripts/dae_handoff.py <feature-dir> --through 3. On a non-zero exit, stop and surface the gap to the human — do not proceed.

Verify branch hygiene: run ${CLAUDE_PLUGIN_ROOT}/scripts/dae_branch.py <feature-dir>. On a non-zero exit, stop and surface the message to the human — switch branches and re-invoke. The check honors the git.manual: true manifest opt-out.

After the gate passes, show the pipeline breadcrumb: run ${CLAUDE_PLUGIN_ROOT}/scripts/dae_progress.py <feature-dir> and present its output to the human — it shows where this checkpoint sits in the DAE pipeline. The breadcrumb is advisory: a non-zero exit or a missing progress.md never blocks the skill. Then create one TodoWrite todo per workflow step below. See ${CLAUDE_PLUGIN_ROOT}/references/progress-indicator.md.

  1. Resolve + load — resolve the methodology root + manifest via ${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md); load feature.md, acs.md, spec.md, CHARTER.md.
  2. Propose the architecture — draft only the Architecture section (components, data flow, where new code lives, coupling, key decisions + rationale + alternatives). Pin cross-track interface contracts: for any interface shared across parallel implementation tracks (a client and a backend built concurrently, two services, etc.), specify the exact wire contract — field names, casing, JSON shape, status codes — not a prose sketch or ASCII diagram. A loose contract forces the other track to reverse-engineer and guess (wsapi /auth/firebase was left as {idToken} with no casing; the parallel client shipped a snake_case guess that had to be reconciled later). This is the interface-pinning that makes parallel tracks safe — see ${CLAUDE_PLUGIN_ROOT}/references/parallelism.md. Ground it in the actual code: prefer LSP — workspaceSymbol to locate the components you'll touch, call-hierarchy (incomingCalls/outgoingCalls) to map coupling and blast radius, findReferences before proposing a change to a shared symbol — over grep, when an LSP MCP capability is available; fall back to grep + Read otherwise (see ${CLAUDE_PLUGIN_ROOT}/references/code-lookup.md). Present it; iterate until the human confirms. Do not draft the rest until then. Gate-profile branch (see ${CLAUDE_PLUGIN_ROOT}/references/gate-profile.md): the mid-way "iterate until the human confirms" stop applies when the feature's gate_profile is absent, or when autonomy_level is low (low suppresses front-dialing — the human reviews everything). Under front: bundled or auto at medium/high, do not stop here — draft the architecture and the rest in one pass; the architecture is approved with the bundle at Step 6 (bundled) or trusted to the gauntlet + back gate (auto). Architecture stays a human decision under bundled; only when it's approved changes.
  3. Draft the rest — draft the remaining sections. When gate_profile is absent, the human confirms Step 2's architecture first, then reviews the finished file. Under bundled/auto, draft straight through. Let gate_profile.verify set the Test strategy's back-gate depth: heavy → an explicit human validation step named in validation_method; light → lean on the objective gates (acceptance + CRAP + gauntlet, plus the CP8 checks the refinement-advisor recommends) and say so.
  4. Charter Check — validate the plan against CHARTER.md. Produce the two-part structured check: a compliance table (one row per charter rule, plus auto-rows for autonomy stance, verification independence, mutation policy, and — at high autonomy — performance budgets), and an Amendments section. Hard rule: never finish a plan with a ⚠️ deviation that lacks a matching amendment ADR. Either write the amendment inline, or stop and emit a handoff with human_action_needed: decision.
  5. Write plan.md — frontmatter (slug, checkpoint: 4, plan_status, created) + sections: Architecture, Charter Check, Phasing, Performance budgets, Collaboration schedule, Execution modes, Test strategy. Test strategy must explicitly incorporate feature.md's validation_method if it carries a non-default value — e.g. if validation_method is "canary 5% prod for 24h, watch dashboard X," the Test strategy section names the canary phase, the dashboard, and the rollback trigger. If validation_method is absent, default to the standard DAE stack (acceptance + unit, plus CP8 hardening as the refinement-advisor recommends it) and say so explicitly. Declare the gauntlet bar in Test strategy when the feature has something to build against that the tests can't assert — a design export, a reference UI screenshot or URL, a reference implementation, a golden output. Emit the gauntlet: block (bar paths + capture: command + max_rounds) per ${CLAUDE_PLUGIN_ROOT}/references/gauntlet.md; CP5 loops builder↔critic against it after green instead of handing the grading back to the human. No such reference exists → omit the block entirely; the absence is the opt-out and no gauntlet runs. A bar must be inspectable — never write prose ("matches the design system") or the ACs into it. A promoted prototype is the bar by default: if feature.md carries a prototype: path (from the prototype skill), declare that path as the gauntlet: bar automatically, with a capture: that renders/runs the candidate in the same form — the prototype is iteration 0's reference, no separate bar needed.
  6. Review panel — dispatch the standing adviser + advocate pair against plan.md per ${CLAUDE_PLUGIN_ROOT}/references/review-panel.md. This is the last gate before code exists, and a plan resting on a false premise is the most expensive thing to discover at CP5 — one ei-theme plan's central factual claim about a shared template turned out to be wrong, and only the advocate caught it. Give both briefs the source files the Architecture section makes claims about, not just the artifacts. Autonomy-keyed; skip silently when the plan is a one-module addition with no architectural argument. Fold the findings into plan.md, then record every finding — accepted or rejected — as panel_findings[] in the handoff. An unaddressed error-severity finding blocks the CP5 dispatch.
  7. Generate runbook.md if the plan touches infra/operator steps — provisioning (cloud project create, billing link, API enablement), secrets management, console-only configuration, manual DNS, deploy-day toggles. Use references/runbook-template.md. Each step has [ ] human or [ ] agent ownership, optional command: if runnable, and evidence: for completion. Deploy-related ACs (e.g. "site loads at staging URL") MUST NOT claim green until the runbook's prerequisite steps are checked off. If the plan has no infra/operator surface, skip — no empty file.
  8. Handoff — emit a summary.
Show full SKILL.md (261 more words)Show less

plan.md has phasing (stages/slices), not a task list — tasks emerge from specs (one spec = one TDD cycle), driven by atdd:atdd-team.

Handoff

Emit per ${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md. checkpoint: 4; recommended_next: "/atdd:atdd-team to implement against the specs". If a deviation needs a decision, human_action_needed: yes (decision).

The handoff MUST include the exit_criteria block asserting each of Checkpoint 4's exit criteria (Foundation Design Section 8) with verified_by, met, and evidence. For verified_by: tool criteria, the evidence MUST be the tool's actual output. The checkpoint is marked done only when every criterion is met.

The front gate. Under gate_profile.front: bundled (see ${CLAUDE_PLUGIN_ROOT}/references/gate-profile.md), CP4 is where the human's one front decision lands: present acs.md + spec.md + plan.md together for a single approval before CP5 — this is the bundled front gate that replaces the separate CP2 AC stop and mid-CP4 architecture stop. On approval, dispatch CP5. Under front: auto, skip the front gate and dispatch CP5 directly (the back gate + gauntlet carry it). When gate_profile is absent — or autonomy_level is low — there is no bundle; the per-checkpoint approvals (Step 2 architecture confirm, CP2 AC stop) already happened.

Before stopping, apply the dispatch rule — see ${CLAUDE_PLUGIN_ROOT}/references/handoff-dispatch.md. CP5 implement is a different role than planner; auto-dispatch the implementer subagent at autonomy medium/high; confirm-then-dispatch at low. Skip dispatch only if the plan emitted human_action_needed: yes (decision pending, including an unaddressed error-severity panel finding) — in that case stop until the human resolves.

References

  • ${CLAUDE_PLUGIN_ROOT}/references/handoff-dispatch.md — when to dispatch vs stop
  • ${CLAUDE_PLUGIN_ROOT}/references/review-panel.md — the Step 6 adviser + advocate gate
  • Foundation Design — the structured Charter Check (Section 3)
  • The DAE methodology page — execution model, autonomy levels, collaboration schedule

© swingerman, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file (references) in engineer/skills/plan of swingerman/engineer.

  • SKILL.md
  • references/runbook-template.md

Open the folder on GitHubat commit 32947eb

Compare with similar skills

Plan next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Plan compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Plan this skillswingerman/engineer154—~2.5kAutomated safety check: PassMIT
Spec Writergarrytan/gstack136k—~14kAutomated safety check: NotesMIT
Specgarden-co/classic-jazz2.5k—~1.3kAutomated safety check: PassMIT
Spec Driven Workflowalirezarezvani/claude-skills28k—~3.9kAutomated safety check: PassMIT
Sparc Specruvnet/ruflo74k—~1.1kAutomated safety check: NotesMIT
Write A Specdifferent-ai/openwork24k—~3.3kAutomated safety check: PassCustom licence

Similar skills

  • Spec Writer

    garrytan/gstack

    Converts a vague idea into a precise, executable spec in five phases, files it as an issue and can start an agent on it in a fresh worktree.

    136k GitHub stars~14k tokensUpdated today
    DevelopmentAuto-check: notes
  • Spec

    garden-co/classic-jazz

    Implement features using Spec Driven Development (SDD) workflow.

    2.5k GitHub stars~1.3k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Spec Driven Workflow

    alirezarezvani/claude-skills

    A skill your agent uses when the user asks to write specs before code, define acceptance criteria, plan features before implementation, generate tests from specifications, or follow spec-first…

    28k GitHub stars~3.9k tokensUpdated 1 mo ago
    DevelopmentAuto-check passed
  • Sparc Spec

    ruvnet/ruflo

    Run the SPARC Specification phase — gather requirements, define acceptance criteria, identify constraints, and store the spec in memory

    74k GitHub stars~1.1k tokensUpdated today
    Product & Project ManagementAuto-check: notes
  • Write A Spec

    different-ai/openwork

    Write or extend an E2E journey spec in evals/specs that proves a PR's change to a human reviewer.

    24k GitHub stars~3.3k tokensUpdated today
    Testing & QAAuto-check passed
  • To Spec

    vinvcn/mattpocock-skills-zh-CN

    把当前对话转成 spec 并发布到项目 issue tracker——不做访谈,只综合已经讨论的内容. An agent skill from vinvcn/mattpocock-skills-zh-CN.

    4.6k GitHub stars~443 tokensUpdated 9 days ago
    Product & Project ManagementAuto-check passed

More from swingerman/engineer

All 27 skills in this repo
  • Crap Analyzer

    swingerman/engineer

    A skill your agent uses to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods.

    154 GitHub stars~1.2k tokensUpdated 14 days ago
    Auto-check passed
  • Atdd Mutate

    swingerman/engineer

    A skill your agent uses to add a third validation layer to the ATDD workflow — after acceptance tests verify WHAT and unit tests verify HOW, mutation testing verifies the tests actually catch bugs.

    154 GitHub stars~2.7k tokensUpdated 14 days ago
    Auto-check passed
  • Fix

    swingerman/engineer

    A skill your agent uses to drive a bug fix from first report through close, with a "why didn't we catch it?" loop at the end.

    154 GitHub stars~3k tokensUpdated 14 days ago
    Auto-check passed
  • Atdd

    swingerman/engineer

    A skill your agent uses to drive feature work through the Acceptance Test Driven Development workflow — Given/When/Then specs before code, a project-specific test pipeline, and two parallel test…

    154 GitHub stars~2.8k tokensUpdated 14 days ago
    Auto-check passed
  • Harden

    swingerman/engineer

    Use after a feature passes Light Verify (CP7), to prove the tests actually catch bugs and, where the code warrants it, to formally check its invariants — Checkpoint 8.

    154 GitHub stars~1.8k tokensUpdated 14 days ago
    Auto-check passed
  • Next

    swingerman/engineer

    Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project.

    154 GitHub stars~3k tokensUpdated 14 days ago
    Auto-check passed

Questions about Plan

What does Plan do?

A skill your agent uses when a feature has ACs and specs and needs an architecture plan before implementation. Plan is an agent skill from swingerman/engineer. Use when a feature has ACs and specs and needs an architecture plan before implementation.

When should I use Plan?

Plan fits situations like: A feature has ACs and specs and needs an architecture plan before implementation; — /engineer.plan; plan this feature; plan the implementation.

How do I install Plan in Claude Code?

Run `npx skills add swingerman/engineer --skill plan -a claude-code`. Or copy the skill folder (engineer/skills/plan in swingerman/engineer) into .claude/skills/plan in your project. Claude Code loads it when a task matches its description.

How do I install Plan in Codex?

Run `npx skills add swingerman/engineer --skill plan -a codex`. Or copy the skill folder (engineer/skills/plan in swingerman/engineer) into .agents/skills/plan in your project. Codex loads it when a task matches its description.

Can I use Plan in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add swingerman/engineer --skill plan -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/plan, .gemini/skills/plan, .github/skills/plan and .opencode/skills/plan in your project.

What does Plan need to run?

SKILL.md names no scripts, command-line tools or credentials: Plan is instructions for the agent only.

Does Plan access the network?

SKILL.md names 1 domain. As links in the text: notion.so. This is read from the text; nothing was executed.

Is Plan safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Plan use?

Plan is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Plan use?

About 2.5k tokens (SKILL.md is roughly 10k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.1k tokens, read only when the agent opens those files.

What are the alternatives to Plan?

Skills that share tags, products or a category with Plan: Spec Writer (garrytan/gstack, 136k stars), Spec (garden-co/classic-jazz, 2.5k stars), Spec Driven Workflow (alirezarezvani/claude-skills, 28k stars) and Sparc Spec (ruvnet/ruflo, 74k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Plan?

swingerman (a GitHub user) maintains it in swingerman/engineer, which has 154 GitHub stars. The repository holds 27 skills in this directory. The repository was last updated on September 23, 2026.

Source: swingerman/engineer on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.