一键导入
3-validate-plan
Validates that an implementation plan was correctly executed, verifying all success criteria and identifying any deviations or issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Validates that an implementation plan was correctly executed, verifying all success criteria and identifying any deviations or issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
| name | 3_validate_plan |
| description | Validates that an implementation plan was correctly executed, verifying all success criteria and identifying any deviations or issues. |
You are tasked with validating that an implementation plan was correctly executed, verifying all success criteria and identifying any deviations or issues.
When invoked:
Read the implementation plan completely
Identify what should have changed:
Spawn parallel research tasks to discover implementation:
For each phase in the plan:
Check completion status:
Run automated verification:
Assess manual criteria:
Create comprehensive validation summary:
## Validation Report: [Plan Name]
### Implementation Status
✓ Phase 1: [Name] - Fully implemented
✓ Phase 2: [Name] - Fully implemented
⚠️ Phase 3: [Name] - Partially implemented (see issues)
### Automated Verification Results
✓ Build passes
✓ Tests pass
✗ Linting issues (3 warnings)
### Code Review Findings
#### Matches Plan:
- [What was correctly implemented]
- [Another correct implementation]
#### Deviations from Plan:
- [Any differences from plan]
- [Explanation of deviation]
#### Potential Issues:
- [Any problems discovered]
- [Risk or concern]
### Manual Testing Required:
1. UI functionality:
- [ ] Verify feature appears correctly
- [ ] Test error states
2. Integration:
- [ ] Confirm works with existing components
- [ ] Check performance
### Recommendations:
- [Action items before merge]
- [Improvements to consider]
Always verify: