Plan-Review Integrator v2.0
Consumes structured review panel output and integrates findings into an implementation plan document -- turning review feedback into concrete plan updates with full traceability.
Key insight: Review panels often identify correct symptoms but prescribe wrong fixes when they lack domain context. Always validate recommendations against domain-specific constraints before applying them.
Quick Reference
| Stage | Phase | Action | Output |
|---|---|---|---|
| Gather | 1. Gather Inputs | Collect review reports + plan + domain context | Input set |
| 2. VoltAgent Detection | Detect specialists, suggest install if beneficial | Available specialist map | |
| Analyze | 3. Extract Findings | Parse findings with severity, source, citations | Structured finding list |
| 4. Cross-Reference | Match each finding against plan content | Category per finding | |
| 5. Actionability Filter | Score actionability, drop low-signal findings | Filtered finding list | |
| 6. Classify | Assign action category (epistemic-weighted) | must-fix / bundle / defer / info | |
| Apply | 7. Apply Edits | Edit plan document with rollback on coherence break | Updated plan |
| 8. Verify | Re-read modified plan, check coherence | Verified plan or rollback | |
| Finalize | 9. Update Peripherals | Update ADRs, runbooks, memory | Supporting docs |
| 10. Produce Summary | Traceability table | Audit trail | |
| 11. Persistent Log | Append decisions to integration log | integration_log.jsonl |
Phase 1: Gather Inputs
Collect three things:
- Review report(s) -- file path, inline paste, or reference to prior conversation
- Plan document -- markdown plan, design doc, RFC, or architecture proposal
- Domain context -- memory files, config files, related docs, session history
Domain context is essential for validating reviewer recommendations. Do NOT skip it.
Empty review guard: If the review contains no actionable findings (clean pass), produce no classifications and output: "No action items identified. Plan unchanged." Skip Phases 3-8 and go directly to Phase 10 with a summary confirming the clean review.
VoltAgent Specialist Verification (v1.3)
VoltAgent specialist agents (127+ across 10 families) have built-in domain expertise via their system prompts. Unlike agent-review-panel (which replaces reviewer personas with VoltAgent agents), this skill uses VoltAgent as an optional second-opinion verifier for high-severity edits. The skill remains single-agent; specialists are consulted, not orchestrated. Full catalog: github.com/VoltAgent/awesome-claude-code-subagents
Step 1: Detection. During Phase 1 (Gather Inputs), scan the system-reminder
agent list for any voltagent-* prefixed agents. Note which families are
installed (e.g., voltagent-data-ai, voltagent-infra, voltagent-lang).
If none found, skip all VoltAgent steps silently -- everything works without them.
Step 2: Content-signal routing. Match plan content signals to specialists:
| Content Signal | VoltAgent Specialist | Verification Use |
|---|---|---|
| SQL / database queries | voltagent-data-ai:database-optimizer | Verify query correctness in must-fix edits |
| Data pipelines / ETL | voltagent-data-ai:data-engineer | Verify pipeline logic changes |
| ML / model training | voltagent-data-ai:ml-engineer | Verify model config / hyperparameter fixes |
| Python code | voltagent-lang:python-pro | Verify code snippet corrections |
| TypeScript code | voltagent-lang:typescript-pro | Verify TS code corrections |
| Go code | voltagent-lang:golang-pro | Verify Go code corrections |
| Rust code | voltagent-lang:rust-engineer | Verify Rust code corrections |
| Java / Spring | voltagent-lang:java-architect | Verify Java code corrections |
| Terraform / IaC | voltagent-infra:terraform-engineer | Verify infra changes in plan edits |
| Kubernetes / k8s | voltagent-infra:kubernetes-specialist | Verify k8s manifest changes |
| Docker / containers | voltagent-infra:docker-expert | Verify container config changes |
| CI/CD / pipelines | voltagent-infra:deployment-engineer | Verify deployment procedure edits |
| Security / auth | voltagent-qa-sec:security-auditor | Verify security fix correctness |
| Performance / scaling | voltagent-qa-sec:performance-engineer | Verify performance-related changes |
| API design / REST | voltagent-core-dev:api-designer | Verify API contract changes |
| GraphQL | voltagent-core-dev:graphql-architect | Verify schema changes |
| React / frontend | voltagent-lang:react-specialist | Verify frontend code corrections |
| Compliance / GDPR | voltagent-qa-sec:compliance-auditor | Verify regulatory compliance of edits |
Step 3: Suggest installation when beneficial. If content signals match VoltAgent specialists but the relevant agent families are not available, suggest installation to the user:
"This integration would benefit from VoltAgent specialist agents for domain-specific edit verification. You can install the relevant families with:
Quick install (CLI):
claude plugin install voltagent-qa-sec-- security, code review, testingclaude plugin install voltagent-data-ai-- data science, ML, databasesclaude plugin install voltagent-infra-- DevOps, cloud, Terraformclaude plugin install voltagent-lang-- language specialists (TS, Python, Go, Rust)Or browse via marketplace:
/plugin marketplace add VoltAgent/awesome-claude-code-subagentsthen/plugin install <name>@voltagent-subagentsContinue without them? They're optional -- all verification works without VoltAgent specialists."
Only suggest installation once per session. List only the families relevant to the detected content signals, not all 10. If the user declines or the agents are not available, proceed silently with the standard single-agent workflow.
Step 4: When to spawn specialists. VoltAgent spawns are gated by priority, phase, and a hard cap:
- Priority gate: ONLY for P0 or P1 effective priority findings (from Phase 6 epistemic-weighted classification). P2 and informational findings never trigger specialist verification.
- Phase gate: ONLY during Phase 4 (cross-reference validation) and Phase 7 (edit verification). Optionally Phase 8 (post-integration coherence check) if spawns remain.
- Spawn cap: Maximum 3 specialist spawns per integration run. If more than 3 P0/P1 findings qualify, prioritize: P0 before P1, Corrections before Gaps, security/data-integrity domains before others.
- Specialist prompt: Each specialist receives:
- The specific finding (ID, severity, detail, prescribed fix)
- The plan section being modified (2 paragraphs of surrounding context)
- Domain context gathered in Phase 1
- Focused question: "Is the prescribed fix correct for this domain? If not, what should change?"
- Response handling: Specialist responses are advisory. If a specialist
flags the prescribed fix as incorrect:
- Document the specialist's concern in the traceability table
- Apply the specialist's suggested alternative if it passes coherence check
- Or flag for human review if disagreement cannot be resolved
- Fallback: If the specialist spawn fails or times out, proceed without it.
Log
"voltagent_verification": "unavailable"inintegration_log.jsonl.
Note: findings downgraded by the actionability filter (Phase 5, where groundedness < 0.3 caps severity at MEDIUM) will not reach P0/P1 threshold for specialist verification. This is correct behavior.
Phase 3: Extract Findings
For each finding, capture:
| Field | Description |
|---|---|
| ID | Sequential: R1-F01, R1-F02, ... R2-F01, ... |
| Severity | CRITICAL / HIGH / MEDIUM / LOW |
| Source | Reviewer name, "Completeness Audit", or "Judge" |
| Summary | One-line descript |