一键导入
4-implement-plan
Implements an approved technical plan from `thoughts/plans/`. These plans contain phases with specific changes and success criteria.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Implements an approved technical plan from `thoughts/plans/`. These plans contain phases with specific changes and success criteria.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | 4_implement_plan |
| description | Implements an approved technical plan from `thoughts/plans/`. These plans contain phases with specific changes and success criteria. |
You are tasked with implementing an approved technical plan from thoughts/plans/. These plans contain phases with specific changes and success criteria.
When given a plan path:
If no plan path provided, ask for one.
Plans are carefully designed, but reality can be messy. Your job is to:
When things don't match the plan exactly:
Issue in Phase [N]:
Expected: [what the plan says]
Found: [actual situation]
Why this matters: [explanation]
How should I proceed?
You MUST commit changes after completing any step of a phase. Do not wait for the user to ask — this command authorizes you to commit. After each step: stage, commit (following the commit guidelines below), then move to the next step.
When committing changes to git, adhere to the following:
After implementing a phase:
Phase by Phase Implementation:
When You Get Stuck:
Progress Tracking:
If the plan has existing checkmarks:
Remember: You're implementing a solution, not just checking boxes. Keep the end goal in mind and maintain forward momentum.
Use when deciding how deeply to review a PR, which reviewers to involve, or whether to accept a large agentic PR
Plan test coverage and the TDD workflow for a GitHub issue through a grill-me interview, then produce an execution-ready plan doc (grounding, test locations, red/green steps, PR breakdown, review gates, task-list bookkeeping) at the repo root. Use when asked to plan a TDD implementation, plan which tests to add for an issue, or scope out test coverage before writing code.
Use ONLY when Nico explicitly invokes it (typically via /pdp-confidence-update) to write, prepare, or reconstruct the weekly PDP confidence update for a project channel. Do NOT trigger automatically from general Slack/status questions. Reconstructs the channel since the last `!pdp progress` post and drafts a ready-to-post update in Nico's house style.
Produces Nico's daily stand-up reply — "Yesterday", "Today", and "Blockers or risks" sections in his house style, organized by his current P1/P2/P3 epics with everything else under "Also" — then posts each as a separate Geekbot reply in his Slack DM once he agrees on the wording. Use when Nico asks to write his daily stand-up, stand-up message, Geekbot reply, or to summarize yesterday's work for stand-up.
Use when reviewing a PR in camunda/camunda that touches AGENTS.md, skills under .claude/skills/, the way the project uses ADRs, or the way the project uses architecture docs (not new ADRs or architecture docs themselves) — i.e., Agent-Ready initiative PRs
Use when user shares an error message, stack trace, or log snippet to investigate — or when investigating an incident that has a concrete error artifact (log line, exception, failed assertion). Skip when the incident has no error artifact, e.g. performance regressions, throughput/latency drops, capacity issues, or behavioral discrepancies without logs.