Implement a plan
npx skills add https://github.com/alexandersumer/config --skill execute-plan이 명령을 Claude Code에 복사하여 붙여넣어 스킬을 설치하세요
Heavyweight codebase architecture review using fresh-context subagents and validation. Use when the user asks for deep, thorough, multi-agent, high-confidence, or heavyweight review of architecture, modularity, seams, coupling, ownership, domain boundaries, AI-navigability, or testability. Use architecture-review-solo for ordinary/direct single-agent architecture review.
Direct codebase architecture review without subagents. Use for ordinary, direct, inline, single-agent, or no-subagent architecture review. Use architecture-review-deep when the user asks for deep, thorough, multi-agent, high-confidence, or heavyweight architecture review.
Heavyweight design review using fresh-context subagents and validation. Use when the user asks for deep, thorough, multi-agent, high-confidence, or heavyweight review of a software design, architecture proposal, API boundary, module split, data model, or design-sensitive diff. Use design-review-solo for ordinary/direct single-agent design review.
Direct design review without subagents. Use for ordinary, direct, inline, single-agent, or no-subagent review of software design, architecture proposals, API boundaries, module splits, data models, or design-sensitive diffs. Use design-review-deep when the user asks for deep, thorough, multi-agent, high-confidence, or heavyweight design review.
Heavyweight code-change review using fresh-context subagents and validation. Use when the user asks for deep, thorough, multi-agent, high-confidence, or heavyweight review of PRs, diffs, branches, staged changes, unstaged changes, untracked files, or any set of code/config/test changes. Use review-solo for ordinary/direct single-agent review.
Direct code-change review without subagents. Use for ordinary, direct, inline, single-agent, or no-subagent review of code/config/test changes. Use review-deep when the user asks for deep, thorough, multi-agent, high-confidence, or heavyweight review.
| name | execute-plan |
| description | Implement a plan |
Implement artifact, spec, $ARGUMENTS, or the most relevant discovered planning artifact.
Do not stop at scaffolding, types, TODOs, docs, or unrelated green tests. Deliver reachable behavior through real repo entry points.
Before editing:
Artifact: <path or inline> and Canonical patterns: <path> for <aspect>Maintain an explicit todo or plan in chat or with the available planning tool. Every task must be an observable behavior or capability with a checkable signal.
Build production code, wiring, tests, and required docs/config together. Tests must catch a named realistic regression. If no existing check can prove the behavior, add the missing targeted check instead of claiming green.
Test infra/build config changes are allowed only when the artifact asks for verification infrastructure. Otherwise no suppressions, baselines, dependency bumps, build config edits, skipped tests, or fake TODO placeholders.
Run targeted checks, then broader checks when available. Re-read the artifact and account for every requirement as implemented or deferred. Evidence before claims: no fixed, complete, ready, or passing language without fresh proof in this turn.
Final under 25 lines:
Artifact: <path or inline>
Implemented:
- <behavior>: <files> — `<command>` -> <result>
Checks: `<command>` -> <result> or `not run — <reason>`
Deferred:
- <item or None>: <reason>
Next: review-solo or review-deep as appropriate, then git-publish.