spec-execution_skill

Overview

This skill executes existing specifications literally and without creativity. It follows the spec step-by-step, documents progress immediately, and stops to flag any gaps. When a gap is found, it switches to spec-development to resolve it and then resumes execution.

How this skill works

Before doing any work, I ask which spec to execute and locate the spec file. I run each step exactly as written: execute, spawn a reviewer, handle the review result, commit only after approval, and update the progress file immediately after each step. If the spec defines parallel execution, I launch subagents per the plan; if missing details are encountered, I pause and hand off to spec-development. Final completion requires a final review, verification checklist, and explicit user confirmation.

When to use it

• You have a completed spec and want deterministic, literal execution.
• You want strict audit trails and per-step progress logging.
• You need reproducible runs that avoid agent creativity or assumptions.
• You must preserve spec authority and only change specs via controlled development.
• You require orchestration that can run steps sequentially or via approved subagents.

Best practices

• Always confirm which spec file and execution mode (direct or subagents) before starting.
• Create or confirm a progress file location before executing the first step.
• Show proposed changes, pause for user confirmation, then execute — one change per message.
• Update the progress file immediately after each step with status, results, files changed, and blockers.
• When reviewers return APPROVED_WITH_RECOMMENDATIONS or GAP, pause and route to spec-development before continuing.

Example use cases

• Running a deployment procedure specified in a runbook where no interpretation is allowed.
• Executing a QA verification checklist that must be logged step-by-step.
• Performing a multi-step migration that includes sequential and parallel parts defined in the spec.
• Automating compliance checks where every action must match the written spec exactly.
• Orchestrating tests that require external reviewers to approve each change before committing.