How this skill is triggered — by the user, by Claude, or both
Slash command
/workflow-automation:implementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
---
You are implementing a feature from an existing plan document, working through it phase by phase.
This skill uses .workflow-state.json for cross-session resume.
See ../../shared-references/workflow-state.md for the full protocol.
On startup: Check for .workflow-state.json in the project root.
If found with skill: "implement" and the phase is still incomplete,
offer to resume from the recorded step. If stale, delete it and start
fresh.
Autonomous mode: If the state file contains
mode: "auto-implement", skip all confirmation prompts:
During execution: Update the state file at Steps 2, 3, 5, and 7.
On completion: Clear the state file after Step 7 to ensure deterministic resume behavior and a clean state for subsequent skills.
plans/ subfolderplan-*.md files in the project rootplan-*-done.md — these are completed plans.
If only completed plans exist, inform the user that all plans are
already done.TODO or IN_PROGRESS.DONE in the status table. If it's
still TODO or IN_PROGRESS, the plan hasn't been approved — suggest
completing the feature-plan skill first.Gitignore check: Before writing .workflow-state.json, check if
.gitignore exists and contains .workflow-state.json. If the entry is
missing, append it (create .gitignore if needed). This prevents
accidental commits of local workflow state.
Follow the plan's steps for this phase:
Match existing patterns: Before writing new code in a file, read the entire file to identify architectural patterns already in use — wrapper functions, factory conventions, registration patterns, naming schemes, and API surface conventions. Replicate these patterns in new code. For example, if existing functions follow a "public no-arg wrapper + private parameterized implementation" pattern for a registry, new functions must follow the same structure.
Stay on scope: Only implement what the plan specifies for this phase.
Before modifying a file, cross-check it against the plan's file lists for
this phase. If the file is not listed, stop and ask the user: add it to
the current phase, defer it to a future phase, or add it to the project's
dev docs TODO file (see ../../shared-references/todo-convention.md) and
continue. In autonomous mode: add it to the TODO file and continue.
After execution, determine the phase status (see Phase Execution
Statuses below). If the status is not IMPLEMENTED, handle according
to the protocol before proceeding.
Run a simplification pass on the changed code to clean up
over-engineering, unnecessary abstractions, and code style issues before
review. Spawn an agent using the Agent tool
(subagent_type="code-simplifier:code-simplifier", model: "sonnet")
targeting the files modified in this phase.
If this agent type is unavailable, fall back to a general-purpose agent with instructions to simplify the changed code for clarity and maintainability.
Run a two-stage code review cycle until the code is clean.
Stage 1 — Spec compliance (mandatory, runs first):
Spawn an agent (subagent_type="feature-dev:code-reviewer") with the
plan document and changed files. Focus prompt: "Verify that the
implementation matches the plan for this phase. Check: (1) all planned
steps were addressed, (2) no over-building beyond the plan's scope,
(3) pattern consistency — new code replicates the architectural patterns
established in the same file or module. For each finding, state severity
(blocker/warning/suggestion) and a concrete fix."
Handle feedback: judge whether each finding is justified before acting.
../../shared-references/todo-convention.md) with the phase name as
source.Re-run Stage 1 after any fixes. Cap at 2 iterations — if spec compliance still has justified blockers after 2 rounds, stop and inform the user.
Stage 2 — Code quality (only after Stage 1 passes):
Spawn three agents in parallel:
subagent_type="pr-review-toolkit:code-reviewer" — project guidelines
and CLAUDE.md conventionssubagent_type="pr-review-toolkit:silent-failure-hunter" — error
handling, swallowed exceptions, inappropriate fallback behaviorsubagent_type="pr-review-toolkit:pr-test-analyzer" — test coverage
quality and critical gapsCollect findings from all three. Judge whether each finding is justified before acting:
../../shared-references/todo-convention.md) with the phase name as
source.Re-run Stage 2 after any fixes. Cap at 3 iterations — if the 3rd iteration still has justified blockers, stop and inform the user.
Fallback: If any agent type is unavailable, fall back to a general-purpose agent with the same focus prompt.
See the Agent Catalog at the end of this file for the full list of available agents and their roles.
IMPLEMENTED_WITH_CONCERNS, record the concerns in
the plan's Notes section so they are visible to the ship skill and
the user.After completing a phase, suggest using the ship skill to commit, PR, and merge the phase. The ship skill will propose the next phase after shipping is complete.
After executing a phase (Step 3), assign one of these statuses:
IMPLEMENTED — phase complete, all tests pass, ready to ship.IMPLEMENTED_WITH_CONCERNS — complete and tests pass, but with
flagged doubts (e.g., approach may not scale, test coverage is
uncertain, edge case handling is unclear). Concerns are surfaced to
the user before shipping. In autonomous mode
(mode: "auto-implement"), log the concerns in the plan's Notes
and proceed.NEEDS_INPUT — blocked on a user decision (e.g., ambiguous
requirement, design choice not covered by the plan). In autonomous
mode: log the question in the plan's Notes, mark the phase BLOCKED,
and move to the next phase if it is independent; otherwise stop the
loop.BLOCKED — cannot proceed due to a technical issue (missing
dependency, unresolvable test failure, infrastructure problem).
Triggers the stop-and-escalate protocol (see When to Stop and
Escalate).Stop fixing and escalate to the user when:
In autonomous mode (mode: "auto-implement"): mark the phase
as BLOCKED, log what was tried and what failed in the plan's Notes
section, and stop the loop. Do not silently continue to the next phase
unless it is explicitly independent (no dependency on the blocked
phase).
main, master) from the repogit pull origin <main-branch>git status --porcelain). If there are
uncommitted changes, stash them (git stash) before branching and
inform the user. In autonomous mode, stash silently and continue.git checkout -b feat/<feature>-<phase> origin/<main-branch>Why not worktrees: Worktrees created outside the project directory
(e.g., ../feat-something/) fall outside the sandbox's allowed paths.
Commands run from there bypass the sandbox, requiring explicit
per-command permissions and defeating autonomous mode. Regular branches
stay within the sandbox.
BLOCKED or NEEDS_INPUT and follow the protocol there.TMPDIR=/tmp/claude-1000 (e.g., TMPDIR=/tmp/claude-1000 pytest) to
ensure temp files land in a sandbox-writable location. If failures
persist with --capture (FileNotFoundError on fd writes), add
-p no:capture to disable the capture plugin entirely.Agents available to the workflow automation skills. The feature-plan skill uses
feature-dev:code-architect for plan review — see ../feature-plan/SKILL.md Step 3.
Review agents:
feature-dev:code-reviewer — bugs, logic errors, security
vulnerabilities, code quality (confidence-filtered)pr-review-toolkit:code-reviewer — project guidelines, CLAUDE.md
conventions, style guidespr-review-toolkit:silent-failure-hunter — error handling, swallowed
exceptions, inappropriate fallback behaviorpr-review-toolkit:pr-test-analyzer — test coverage quality and gapspr-review-toolkit:comment-analyzer — comment accuracy and
completenesspr-review-toolkit:type-design-analyzer — type design, encapsulation,
invariant expressionImplementation agents:
code-simplifier:code-simplifier — simplify code for clarity and
maintainabilityfeature-dev:code-architect — design architectures from existing
codebase patternsfeature-dev:code-explorer — trace execution paths, map architecture,
understand dependenciesExploration agents:
Explore — fast codebase search (general purpose only; do NOT use
for code review or simplification — use the dedicated agents above)Plan — implementation strategy designUse model: "sonnet" for the simplification agent (Step 4) — it is
mechanical and benefits from speed over depth. Use the default model
for all review agents and tasks requiring deep reasoning (spec
compliance, architectural analysis, complex multi-file changes).
The user can override model choices via CLAUDE.md preferences.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub matthiaskloft/claude-skills --plugin workflow-automation