How do I install the Plan Format skill?

Run npx skillmds@latest add garyld1962/plan-format in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Plan Format safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Plan Format?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Plan Format free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Plan Format?

garyld1962 (@garyld1962) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Plan Format by garyld1962 — Agent Skill

Name: Plan Format
Author: garyld1962

Plan Format

Canonical plan document format produced by /execute-prd and consumed by /execute-plan's runtime workflow. Defines frontmatter, task metadata (depends_on, milestone_end), and mechanical acceptance blocks. Not user-invokable.

garyld1962 fbebfa2 2.4 KB Updated Sep 17, 2026

File contents

Plan Format (compiler ↔ runtime contract)

A plan is a markdown file. The runtime workflow parses it via an agent with a JSON schema; this document is the source of truth both for the author (execute-prd step 7) and the parser prompt (run-plan.mjs PLAN_SCHEMA agent).

Frontmatter (YAML, required)

---
slug: <kebab-case plan id>
source_prd: <path or ADO/Linear ref>
intent: <one-sentence goal, verbatim usable as pr_description>
type: bug | feature | refactor | infra
---

Body structure

H1 title.
**Source:** line referencing the original artefact.
Optional ## Closed Decisions — bullets; each is tablestakes for the runtime (workers may not re-litigate them).
One or more ## Task N: <title> sections, N unique and ascending.

Task section metadata (replaces the old ## Waves / lane tables)

Each task section starts with a fenced metadata block:

```yaml
depends_on: []          # task numbers that must complete first
write_scope:            # globs this task may modify
  - src/api/**
milestone_end: false    # true → runtime runs a review gate after it
```

Dependency structure IS the parallelism declaration: tasks whose depends_on are all satisfied and whose write_scope globs are mutually disjoint run as one parallel group in isolated worktrees. No separate ## Waves section, no lane registry, no max-team rule — the runtime computes groups and caps concurrency itself.

Single-owner surfaces (root manifests, lockfiles, shared types, migrations, generated files) must appear in exactly one task's write_scope. Overlap between two dependency-independent tasks is a validation error (execute-prd step 8 checks it; the runtime re-checks and serialises the pair if found).

Acceptance blocks

Each task ends with **Acceptance:** bullets. Every bullet must be mechanical: a command that exits 0, or an observable with its exact expected value. Prose like "works correctly" is a validation error.

Milestones

milestone_end: true on a task triggers the runtime's review gate after that task's group completes. If no task sets it, the runtime treats the final task as the only milestone.

---name: plan-formatdescription: Canonical plan document format produced by /execute-prd and consumed by /execute-plan's runtime workflow. Defines frontmatter, task metadata (depends_on, milestone_end), and mechanical acceptance blocks. Not user-invokable.---# Plan Format (compiler ↔ runtime contract)A plan is a markdown file. The runtime workflow parses it via anagent with a JSON schema; this document is the source of truth bothfor the author (execute-prd step 7) and the parser prompt(run-plan.mjs `PLAN_SCHEMA` agent).## Frontmatter (YAML, required) --- slug: <kebab-case plan id> source_prd: <path or ADO/Linear ref> intent: <one-sentence goal, verbatim usable as pr_description> type: bug | feature | refactor | infra ---## Body structure- H1 title.- `**Source:**` line referencing the original artefact.- Optional `## Closed Decisions` — bullets; each is tablestakes for the runtime (workers may not re-litigate them).- One or more `## Task N: <title>` sections, N unique and ascending.## Task section metadata (replaces the old ## Waves / lane tables)Each task section starts with a fenced metadata block: ```yaml depends_on: [] # task numbers that must complete first write_scope: # globs this task may modify - src/api/** milestone_end: false # true → runtime runs a review gate after it ```Dependency structure IS the parallelism declaration: tasks whose`depends_on` are all satisfied and whose `write_scope` globs aremutually disjoint run as one parallel group in isolated worktrees.No separate `## Waves` section, no lane registry, no max-team rule —the runtime computes groups and caps concurrency itself.Single-owner surfaces (root manifests, lockfiles, shared types,migrations, generated files) must appear in exactly one task's`write_scope`. Overlap between two dependency-independent tasks is avalidation error (execute-prd step 8 checks it; the runtime re-checksand serialises the pair if found).## Acceptance blocksEach task ends with `**Acceptance:**` bullets. Every bullet must bemechanical: a command that exits 0, or an observable with its exactexpected value. Prose like "works correctly" is a validation error.## Milestones`milestone_end: true` on a task triggers the runtime's review gateafter that task's group completes. If no task sets it, the runtimetreats the final task as the only milestone.

Frequently asked questions