Use when converting an approved long-running plan into self-contained execution prompts across sessions or workers. Covers dependency order, checkpoints, capability fallback and evidence handoff; use world-class-engineering for a single implementation slice.
Use when converting an approved long-running plan into self-contained execution prompts across sessions or workers. Covers dependency order, checkpoints, capability fallback and evidence handoff; use world-class-engineering for a single implementation slice.
Approved plan, current task states and acceptance criteria
Task owner
Draft the plan before generating execution prompts
Repository instructions, actual skill inventory and supported capabilities
Executing environment
Discover them; do not assume a named plugin or tool exists
Dependency edges, file ownership and last verified checkpoint
Coordinator
Sequence dependent work and resolve overlapping writes
Existing authorisation and external-action limits
User and host policy
Carry forward the existing scope; stop only for work outside it
Capability contract
Authoring needs read/search access to the plan and skill catalogue. Editing
requires the user's plan-authoring scope. Execution and delegation are optional:
produce sequential prompts when workers are unavailable. A process plugin may
refine the workflow when installed; its absence does not block the same approved
workflow through available tools. Keep vendor-specific invocations in an adapter.
Degraded mode
When an optional tool or process skill is unavailable, preserve the task and
substitute its documented capability equivalent. When a required source, test
environment or credential is unavailable, mark the affected acceptance evidence
NOT ASSESSED and continue independent work. Never convert a missing required test
into an expected failure solely to obtain a green suite.
Decision rules
Condition
Prompt design
Evidence required
A task consumes another task's output
Run after the producer's acceptance gate
Producer artefact and result
Independent tasks have disjoint write sets and delegation is available
Assign one owner per write set
Reconciled diffs and worker results
Delegation or a named process plugin is unavailable
Execute the same tasks sequentially
Same acceptance criteria and checkpoint
A session is resumed or compacted
Read the checkpoint and inspect current state
Remaining work, prior results and user corrections
A requested action exceeds existing authority
Complete independent preparation, then request that specific authority
Reviewable proposed action and scope boundary
Workflow
Read the plan, user corrections and repository instructions; enumerate the
actual skills and capabilities.
Partition by dependencies and file ownership. Keep the coordinator's next
blocking task local; delegate independent work only where supported.
Write self-contained prompts using the anatomy below. Use available process
skills when they add value; never prescribe unavailable vendor tools.
Record exact acceptance commands, expected behaviour, negative cases,
unresolved prerequisites and the recovery point.
Verify the prompts against the plan: every task has an owner, required inputs,
output, acceptance evidence and a checkpoint.
Quality Standards
Prompts must preserve existing authorisation, user corrections and incomplete
work across sessions. Completion requires observed acceptance evidence; a tool
invocation, a generated file or an unexecuted test is not completion.
About this skill (self-awareness)
This skill is itself a member of the domain engine — the same library of craft skills it instructs you to reference when authoring a script. It is the meta-skill for the planning and documentation surface of software and app development. Other engine members (e.g. mysql-best-practices, php-security, healthcare-ui-design, android-tdd, swiftui-design, multi-tenant-saas-architecture) are the implementation surface.
Because it lives inside the engine, this skill MUST:
Discover siblings dynamically. Do not paste a static list of available skills into a script. Instead, enumerate the skills library at author-time and pick the relevant ones by name. On any environment, the listing command is whatever the local CLAUDE.md / AGENTS.md / GEMINI.md documents (e.g. ls $SKILLS_HOME or ls <web-dev-library>/skills/). The author session runs the command, reads the listing, picks the relevant skill names, and quotes them by name in the script.
Refer to siblings by name only. This skill never paths to a sibling (/Users/.../skills/mysql-best-practices/SKILL.md) — it names it (mysql-best-practices). The executor's environment resolves the path.
Refresh its category knowledge each use. New skills land in the library all the time. Treat the categories table at the bottom of this file as a stable taxonomy of kinds of skill (security, db, ui, mobile, etc.) — not a frozen registry of skill names. Re-list the library before authoring.
Self-load when relevant. Whenever a plan or runbook is being written or executed for software/app development, this skill SHOULD be loaded — the project's CLAUDE.md "mandatory pairings" entry for execution-plan-scripts enforces this. If a sibling skill is being applied to a multi-prompt deliverable, this skill is its companion.
Use When
A plan has more open tasks than one session can credibly execute (rule of thumb: > ~30 tasks, or > 10 file surfaces, or mixes web + mobile + infra).
The work crosses dependency boundaries that benefit from session-level checkpoints (operator review between prompts).
Subagents will be dispatched from inside one or more of the prompts (per-prompt fan-out).
The deliverable is a runnable script (a markdown file the operator pastes prompt-by-prompt), not the implementation itself.
A sibling domain skill is being applied to a multi-prompt workstream — this skill is the companion that wraps it.
Do Not Use When
The task is a single implementation slice: use world-class-engineering with the applicable domain skill.
The work is open-ended discovery: use product-discovery before writing execution prompts.
No written plan exists: define scope, dependencies and acceptance criteria first.
The Two-Engine Skills Model
Each prompt distinguishes domain guidance from optional process guidance:
Engine
Purpose
How to enumerate
Process engine (e.g. superpowers:*)
HOW work is done — TDD cadence, subagent fan-out, verification gates, code review
Loaded by the host platform (Claude Code plugin manager / Codex / Gemini CLI). The session lists them via the platform's skill discovery (Skill tool listing, /skills, etc.).
Domain engine (the craft library this skill lives in)
WHAT good looks like — language standards, framework patterns, security baselines, UX rules
The session lists them by enumerating the library's skills/ directory. Path is resolved from the local environment's CLAUDE.md / AGENTS.md / GEMINI.md — never hardcoded.
Author-time discipline:
Discover the domain catalogue and any installed process guidance before writing the script; do not assume plugins exist.
Pick by name — the author session quotes only the names that apply to each prompt.
Re-quote in subagent prompts — subagents do not inherit the parent session's skill state, so each subagent prompt repeats the names it needs.
Never path — a name in this script is a contract that the executor will resolve to a path on its own machine.
Process-engine examples (current as of this skill's last edit; the host platform is authoritative):
This skill (execution-plan-scripts) sits in the SDLC + Architecture corner of the domain engine. When you author a script, list its siblings and pick from the categories above — do not work from a frozen list inside this file.
Path-Resolution Rule (cross-platform)
Never hardcode the skills library location. Each environment (mac, linux, windows, codespaces, CI) keeps its own CLAUDE.md/AGENTS.md/GEMINI.md (or equivalent) that tells the executing session where its skills live. The execution-plan script only quotes skill names; the executor resolves them.
In your script, write:
Read these skills in full before any code: mysql-best-practices, php-security, multi-tenant-saas-architecture, dual-auth-rbac, sdlc-testing, healthcare-ui-design, api-error-handling.
The executor finds the file by following the path rule its own environment defines (e.g. macOS: ~/Sites/skills-web-dev/skills/<name>/SKILL.md; Linux dev box: ~/skills-lib/<name>/SKILL.md; CI: $SKILLS_HOME/<name>/SKILL.md). Skill names are stable; paths are not.
Prompt Anatomy
Every prompt in the script follows this structure:
## Prompt N — <one-line scope>
You are in . Read these files first, in this order:
/CLAUDE.md
/INDEX.md
/AGENT_BRIEF.md (or equivalent invariants doc)
/README.md
/plan.md (focus: lines A–B if a sub-range)
Then load the available skills in order, before implementation:
Process guidance (only skills verified as available):
-
-
Read these domain skills in full (resolve paths from your environment):
-
-
- <healthcare-ui-design or other PRIMARY skill, re-read per page Task>
Track each task with the host's task facility or the plan's status register.
Work plan:
A.
B. — delegate through the available worker capability,
or execute sequentially. Each worker prompt MUST include:
- The Task IDs and plan.md line ranges it owns
- The exact list of domain skills to read first (by NAME)
- The file scope it is allowed to touch
- Acceptance checks and the existing commit/publication boundary
- Subagents do NOT inherit the parent's skill state — re-state every skill name.
C. Verification gate (no claim without evidence):
<exact commands to run, with expected green outcome>
D. Status updates in plan.md (- [ ] **Status:** pending → - [x] complete (<hash>))
E. Final report ≤200 words: commits, tests added, deviations.
Do NOT push. Do NOT touch other phases. Do NOT modify INDEX until the
phase's final prompt.
Fan-Out Rules
Bucket subagents by file scope. Two subagents must never write to the same file. If they would, fold them into one subagent or split the file first.
Batch independent work where supported. Use the host's available worker capability; execute sequentially when it is unavailable.
State the file scope explicitly.Allowed: src/Imaging/Services/*, tests/Unit/Imaging/*. Forbidden: anything else. Subagents will respect a clear scope.
Re-inject skills. Every subagent prompt repeats the skill names it must read. They do not inherit parent skill state.
Cap fan-out at ~7. Beyond that, results are hard for the parent session to review. Split into two prompts.
Sequencing Rules
Critical-path serial. If Prompt N produces an artefact (frozen API spec, schema, design tokens) consumed by Prompt N+1, run them in order.
Independent siblings. When two phases have no shared state, they can be siblings — but still keep them as separate prompts so the operator can review between.
No prompt pushes. Push, PR, and release decisions live with the operator after the final prompt completes.
Final prompt is always cleanup. Static analysis, security audit, multi-tenant leak hunt, i18n parity, dead-code/yellow-flag sweep, INDEX flip. Never bury this work inside a feature prompt.
Verification Gate (per prompt)
Every prompt ends with the same gate, drawn from superpowers:verification-before-completion:
Run and capture output verbatim:
<test-suite command>
<static-analysis command>
<linter command>
<multi-tenant / leak / parity grep>
Fix failed checks within the authorised scope. If blocked by a missing source,
environment or new authority, preserve the failure, continue independent work
and leave the dependent task incomplete with a recovery checkpoint.
A "done" claim without the output pasted is forbidden.
Operator-Action Surfacing
Some work needs human-only steps (signing keys, cloud accounts, real-device tests, App Store / Play Console). The script must:
Surface the prerequisite at the top of the prompt that needs it.
Use existing authorisation and capabilities; ask only when a required input
cannot be recovered or a materially different action needs new authority.
If unavailable, record NOT ASSESSED with its release consequence. Keep real
failures failing; do not insert xfail or ignored-test annotations to hide
missing evidence. Continue work that does not depend on the prerequisite.
Never silently skip operator actions.
Index / Status Hygiene
Phase Tasks: every prompt flips - [ ] **Status:** pending to - [x] **Status:** complete (<hash>) at the end.
Phase status in INDEX.md: only the last prompt of a phase flips the row to complete.
Authoring-progress log in INDEX.md: append a dated entry referring to the session.
Memory layer: only the cleanup prompt may write to long-term memory (frozen-contract pointer, post-launch follow-ups location).
Skill names in the script header but not re-stated in subagent prompts — subagents lose them.
A single mega-prompt covering > ~30 Tasks — context exhaustion, lost discipline.
Verification commands omitted "to keep the prompt short" — verification is the prompt.
Fan-out without file-scope — subagents collide on the same file.
Final prompt without static analysis + security audit + INDEX flip.
Pushing or merging from inside a prompt — operator decides.
Re-implementing scaffolded code "to be clean" instead of verifying what's there (violates TDD's iron law against tests-after-code).
Authoring Checklist
Before handing the script to the operator, verify:
Every prompt names verified domain skills and any available process skills it needs.
No absolute path to a skill file appears anywhere in the script.
Every fan-out subagent prompt re-injects the skill names it needs.
Every fan-out has explicit, non-overlapping file scope.
Every prompt ends with a verification gate that names exact commands.
Operator-action prerequisites are surfaced at the top of the affected prompt with a STOP-and-ask instruction.
The final prompt does cleanup: static analysis, security audit, multi-tenant leak hunt, i18n parity, dead-code/yellow-flag sweep, INDEX flip, memory write.
No prompt pushes, force-pushes, or opens PRs.
Status updates: each prompt flips its Task statuses; only the last prompt of a phase flips the phase row in INDEX.md.
The script preface lists the sequence overview as a table (prompt #, scope, parallelism, subagent count) so the operator sees the shape at a glance.
Companion skills (named, not pathed)
The companions below are the kinds of skill you will most often pair with this one. Re-enumerate the library at author-time to confirm names and discover new arrivals — never work from this list as a frozen registry.
superpowers:writing-plans or feature-planning — author the underlying plan first.
superpowers:executing-plans or plan-implementation — what each prompt invokes when it runs.
Use the companion skills above only after confirming their names in the current
catalogue. The local world-class-engineering skill owns implementation gates;
implementation-status-auditor checks plan evidence. Illustrative plugin names
above are not installation requirements.
Evidence Produced
Category
Artifact
Format
Example
Correctness
Task-to-prompt coverage with dependencies and acceptance checks
Markdown table
Each approved task maps to one owner and a verification command
Operability
Resume checkpoint and capability fallback
Markdown
Completed task evidence, remaining tasks and sequential worker fallback
Release evidence
Verification results and unresolved prerequisites
Markdown
Failed or unavailable checks remain visible with their release consequence
