pi-config/extensions/rpiv-pi/skills/implement/SKILL.md

name, description, argument-hint, allowed-tools, disable-model-invocation

name	description	argument-hint	allowed-tools	disable-model-invocation
implement	Execute an approved implementation plan from thoughts/shared/plans/ phase by phase, applying changes and verifying each phase against its success criteria before moving on. Use when the user invokes /implement, asks to "implement this plan", or wants an existing phased plan executed. Pair with revise to update plans mid-flight and validate to confirm completion.	[plan-path] [Phase N]	Read, Edit, Write, Bash(*), Glob, Grep	true

Implement Plan

You are tasked with implementing an approved technical plan from thoughts/shared/plans/. These plans contain phases with specific changes and success criteria.

Getting Started

• Plan path: $1 (empty/literal → ask user)
• Phase scope: ${@:2} (empty → all phases sequentially; else scope to this phase only)

With a plan path in hand:

• Read the plan completely and check for any existing checkmarks (- [x])
• Read the original ticket and all files mentioned in the plan
• Read files fully - never use limit/offset parameters, you need complete context
• Think deeply about how the pieces fit together
• Create a todo list to track your progress
• Start implementing if you understand what needs to be done

Implementation Philosophy

Plans are carefully designed, but reality can be messy. Your job is to:

• Follow the plan's intent while adapting to what you find
• Implement each phase fully before moving to the next
• Verify your work makes sense in the broader codebase context
• Update checkboxes in the plan as you complete sections

When things don't match the plan exactly, think about why and communicate clearly. The plan is your guide, but your judgment matters too.

If you encounter a mismatch:

• STOP and think deeply about why the plan can't be followed

• Present the issue clearly:

  Issue in Phase {N}:
  Expected: {what the plan says}
  Found: {actual situation}
  Why this matters: {explanation}
  
  

  Use the ask_user_question tool to resolve the mismatch. Question: "{Brief summary of the mismatch}". Header: "Mismatch". Options: "Follow the plan" (Adapt the plan's approach to the current code state); "Skip this change" (Move on without this change — it may not be needed); "Update the plan" (The plan needs to be revised before continuing).

Verification Approach

After implementing a phase:

• Run the success criteria checks (usually make check test covers everything)
• Fix any issues before proceeding
• Update your progress in both the plan and your todos
• Check off completed items in the plan file itself using Edit

Don't let verification interrupt your flow - batch it at natural stopping points.

If You Get Stuck

When something isn't working as expected:

• First, make sure you've read and understood all the relevant code
• Consider if the codebase has evolved since the plan was written
• Present the mismatch clearly and ask for guidance

Use skills sparingly - mainly for targeted debugging or exploring unfamiliar territory.

Resuming Work

If the plan has existing checkmarks:

• Trust that completed work is done
• Pick up from the first unchecked item
• Verify previous work only if something seems off

Remember: You're implementing a solution, not just checking boxes. Keep the end goal in mind and maintain forward momentum.

Closing Out

When the last in-scope phase is complete (or the user pauses execution), print a closing block in this exact shape:

Implementation {complete | paused at Phase {N}}: `thoughts/shared/plans/{filename}.md`

{P} phases completed, {M} files changed, {T} tests passing.
Outstanding: {list of unchecked items, blockers, or "none"}.

---

💬 Follow-up: implement edits source files, not artifacts. For plan-level changes run `/skill:revise <plan-path>` first; for session pauses run `/skill:create-handoff`.

**Next step:** `/skill:validate thoughts/shared/plans/{filename}.md` — verify the implementation against the plan's success criteria before committing.

> 🆕 Tip: start a fresh session with `/new` first — chained skills work best with a clean context window.

If the run was paused mid-plan rather than completed, swap the next-step line for /skill:create-handoff so context can be resumed cleanly in a new session — the same /new tip still applies.

Handle Follow-ups

• Implement does not own the plan. Source-file edits happen in implement; plan edits do not. Never patch the plan artifact from inside implement.
• For plan-level changes. Run /skill:revise <plan-path> first — it appends a timestamped Follow-up section to the plan and preserves history. Then resume implement at the affected phase.
• For session pauses. Run /skill:create-handoff to capture in-flight state, then /new and /skill:resume-handoff in the next session.
• Mismatch handling stays inline. When code reality diverges from the plan, use the inline ask_user_question flow ("Follow the plan / Skip this change / Update the plan") — that is implement's only follow-up surface; everything else escalates to revise or create-handoff.