This skill should be used when the user asks to "implement the plan", "execute the plan", "start implementation", "build the feature", "make the changes", or invokes the rpikit:implement command. Provides methodology for disciplined execution with checkpoint validation and progress tracking.
/plugin marketplace add bostonaholic/rpikit/plugin install rpikit@rpikitThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Execute the implementation plan for: $ARGUMENTS
Implementation executes an approved plan with discipline and verification. The goal is not just working code, but verified, documented progress that matches the plan. Implementation follows the plan strictly, verifying each step before proceeding.
Look for plan at: docs/plans/YYYY-MM-DD-$ARGUMENTS-plan.md
(Search for files matching *-$ARGUMENTS-plan.md pattern)
If plan exists:
If no plan exists:
High Stakes (architectural, security-sensitive, hard to rollback):
Cannot proceed without an approved plan.
High-stakes implementations require:
1. Research phase (rpikit:research-methodology skill)
2. Approved plan (rpikit:plan-methodology skill)
Invoke the Skill tool with skill "rpikit:plan-methodology" to create a plan first.
Stop and do not proceed.
Medium Stakes (multiple files, moderate impact):
Warning: No approved plan found for '$ARGUMENTS'.
Medium-stakes changes benefit from planning.
Use AskUserQuestion with options:
Low Stakes (isolated, easy rollback):
Note: Consider rpikit:research-methodology and rpikit:plan-methodology skills for better results.
Proceeding with implementation...
Proceed with inline planning.
Before making changes, offer to create an isolated worktree.
First, check if already in an additional worktree:
# Check if .git is a file (indicates additional worktree, not main repo)
test -f .git
Run this command via the Bash tool:
.git is a file → this is an additional worktree → skip the prompt and proceed to progress tracking.git is a directory → this is the main repository → continue with the worktree offer belowIf not in a worktree, offer based on stakes level:
High Stakes:
Use AskUserQuestion with options:
Medium Stakes:
Use AskUserQuestion with options:
Low Stakes:
Brief mention only:
Tip: For isolation, you can use the git-worktrees skill.
Proceeding in current directory...
Skip the prompt and continue.
If user chooses worktree:
Invoke Skill tool with skill: "rpikit:git-worktrees"
After worktree is created:
Convert plan steps to TodoWrite todos:
Read each step from the plan and create corresponding todos:
For each step in the plan:
Mark in_progress - Update TodoWrite
Locate target files - If file path is unclear or missing, use file-finder:
Task tool with subagent_type: "file-finder"
Prompt: "Find [what the step describes]. Need to [action from plan]"
Read target files - Always read before modifying
Make the change - Follow plan specification exactly
Run verification - Execute the verify criteria
Confirm success - Only proceed if verification passes
Mark completed - Update TodoWrite immediately
Update plan - Mark step complete in plan document
After completing each phase:
Summarize progress:
Phase [N] complete:
- Step N.1: [description]
- Step N.2: [description]
- Step N.3: [description]
Verifications: All passed
Use AskUserQuestion:
When verification fails:
Stop - Do not proceed to next step
Report - Explain what failed and why
Diagnose - Investigate the cause. If the error involves external libraries or unfamiliar issues, use web-researcher:
Task tool with subagent_type: "web-researcher"
Prompt: "[error message or issue] in [library/context]"
Propose fix - Suggest correction based on diagnosis
If fix requires plan changes:
Verification failed for Step [X.Y]: [description]
The planned approach doesn't work because: [reason]
Proposed adjustment: [new approach]
Use AskUserQuestion:
When all steps are done:
Mark all todos complete
Update plan document status section
Run final verification (full test suite if applicable)
Run code review:
Task tool with subagent_type: "code-reviewer"
Prompt: "Review implementation changes for: $ARGUMENTS"
If verdict is REQUEST CHANGES (soft gate):
Use AskUserQuestion:
If user chooses "Proceed anyway", continue to security review.
Run security review:
Task tool with subagent_type: "security-reviewer"
Prompt: "Review implementation changes for: $ARGUMENTS"
If verdict is FAIL, stop and address findings before completing.
Summarize results
Implementation complete for '$ARGUMENTS'.
Summary:
- Steps completed: [N]
- Phases completed: [M]
- Files changed: [list]
- Tests: [pass/fail status]
Plan updated: docs/plans/YYYY-MM-DD-$ARGUMENTS-plan.md
All success criteria met.
The plan is the contract. Deviations require explicit approval:
Never claim completion without evidence:
Use TodoWrite to show real-time progress:
Maintain real-time visibility:
[completed] Step 1.1: Add validation function
[completed] Step 1.2: Update API endpoint
[in_progress] Step 2.1: Add unit tests
[pending] Step 2.2: Update integration tests
Update the plan file as implementation progresses:
#### Step 1.1: Add validation function
- **Status**: Complete
- **Verified**: Unit tests pass
- **Notes**: Used existing regex pattern from validatePhone()
When plan includes test steps, follow TDD:
Mark test steps complete only when tests pass.
If implementation reveals the plan needs changes:
Stop current step
Document the issue
If additional files are needed, use file-finder to locate them:
Task tool with subagent_type: "file-finder"
Prompt: "Find files related to [issue discovered]. Need to [proposed change]"
Propose plan modification with updated file references
Get approval before continuing
Never deviate silently from the approved plan.
For code changes, verify by:
For functionality, verify by:
Ensure no breakage:
Wrong: Marking done without running verification Right: Always run verification, document results
Wrong: Moving to next step when current step failed Right: Stop, diagnose, fix, re-verify
Wrong: Changing approach without updating plan Right: Request approval for plan changes
Wrong: Marking multiple steps done at once Right: Mark complete immediately after each verification
Wrong: Rushing high-stakes changes Right: Respect enforcement based on stakes level
During implementation:
At completion:
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.