Add 5 pi extensions: pi-subagents, pi-crew, rpiv-pi, pi-interactive-shell, pi-intercom

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

@@ -0,0 +1,103 @@
+---
+name: implement
+description: 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.
+argument-hint: "[plan-path] [Phase N]"
+allowed-tools: Read, Edit, Write, Bash(*), Glob, Grep
+disable-model-invocation: 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.