ワンクリックで
neural-review
Plan vs implementation verification with goal-backward analysis and test-quality audit
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Plan vs implementation verification with goal-backward analysis and test-quality audit
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
Implementation planning with optional adversarial cross-review (Claude Code ⇄ Codex). Tasks are sequential vertical slices, each carrying its own testable behaviors. Pass --visual to also render the plan as a self-contained HTML page (PLAN.html). Pass --skills <skills> to preload skills that shape the plan and that execute loads before coding
Execute all fixes from a REVIEW.md — address warnings, blocking issues, and gaps found during review
Test-driven execution loop — one task at a time, red→green→refactor, atomic commits
Move completed features from wip to archive
Socratic interview that captures domain language, decisions, and ADRs inside .neural/wip/<feature>/
Harvest knowledge from archived features into .neural/knowledge/ — run after archiving a feature, or invoke manually to rebuild the project knowledge base
SOC 職業分類に基づく
| name | neural-review |
| description | Plan vs implementation verification with goal-backward analysis and test-quality audit |
You verify, inline, that the implementation actually delivers what CONTEXT.md and PLAN.md promised — and that the tests written along the way prove behavior rather than shape.
The review runs in this same context because /neural:neural-execute no longer ships work through subagents — there is no "implementer bias" to escape from. The risk we still need to guard against is confirmation bias: treating the plan as proof. Counter it by gathering fresh evidence (read files, run tests, grep) every time. Never trust a prior REVIEW.md.
$ARGUMENTS. If empty, scan .neural/wip/ — one match → use it, multiple → ask.WIP=.neural/wip/<feature>/.$WIP/CONTEXT.md and $WIP/PLAN.md. If either is missing, abort: "Missing CONTEXT.md or PLAN.md — cannot review without specs."$WIP/docs/adr/.CONTEXT.md / PLAN.md, identify the tech stack.PLAN.md. Each task carries: expected files, behaviors to verify, acceptance.✓ completed — every expected artifact found and substantive, every behavior covered by a test.⚠️ partial — some artifacts found, others missing or weakly covered.✗ missing — task not implemented.X/Y (partial = 0.5).Grep the files changed for this feature. Record any hits.
| Pattern | What to search | Severity |
|---|---|---|
| Incomplete work | TODO, FIXME, XXX, HACK | Warning |
| Placeholder content | placeholder, coming soon, lorem ipsum, example.com | Blocking |
| Empty implementations | return null, return {}, return [], => {}, pass as sole function body | Blocking |
| Hardcoded secrets | sk_test_, your-api-key-here, password123 | Blocking |
| Debug leftovers | console.log, print(, debugger, binding.pry | Warning |
Read the Problem section of CONTEXT.md.
Derive observable truths — testable statements that must hold if the problem is truly solved. Example: "A user can POST /api/orders and receive 201 with an order id."
For each truth, verify four levels:
L1 EXISTS — the artifact exists at the expected path. Use Glob + Read.
L2 SUBSTANTIVE — real implementation, not a stub and not a reduced version of the requirement. Look for empty bodies, TODO, NotImplementedError, hardcoded mocks, commented-out core logic — and for partial delivery: a task that names a CONTEXT.md decision but ships "v1 / for now / hardcoded / basic version" of it. A requirement with no concrete evidence, or only weak evidence, is a FAIL — not a PASS.
L3 WIRED — connected to the rest of the system. Is the route registered? Is the component rendered? Is the function imported somewhere? Flag orphan code.
L4 FUNCTIONAL — runs and produces the expected outcome.
npm test, pytest, cargo test, whatever applies).Assign per truth:
PASS — all four levels verified.PARTIAL — EXISTS + SUBSTANTIVE but not fully WIRED or FUNCTIONAL.FAIL — any level fails.Write $WIP/REVIEW.md:
# Review: <feature-name>
**Date:** <current date>
**Verdict:** <PASS | PASS WITH WARNINGS | FAIL>
## Completion Score
**X/Y tasks completed**
| Task | Status | Notes |
|------|--------|-------|
| <task title> | ✓ / ⚠️ / ✗ | <details, including behavior coverage> |
## Goal-Backward Verification
### Truth: "<observable truth>"
| Level | Status | Evidence |
|-------|--------|----------|
| EXISTS | ✓ / ✗ | <path or detail> |
| SUBSTANTIVE | ✓ / ✗ | <detail> |
| WIRED | ✓ / ✗ | <import/route/reference> |
| FUNCTIONAL | ✓ / ✗ | <test result or gap> |
**Result:** PASS / PARTIAL / FAIL
<!-- Repeat for each truth -->
## Test Quality
- Disabled tests linked to feature requirements: <list or "none">
- Weak assertions on critical behaviors: <list or "none">
- Tests coupled to implementation (mocks of internal collaborators, asserting on call counts, bypassing the interface): <list or "none">
- Circular tests (system under test generates its own expected value): <list or "none">
## Issues
### Blocking
- ...
### Warnings
- ...
### Info
- ...
Verdict rules:
Evidence freshness rule. The verdict must be based on evidence gathered during this execution. Never reuse a previous REVIEW.md or assume results from a prior run still hold.
/neural:neural-archive to archive this feature."
/neural:neural-address-review— fix the warnings automatically/neural:neural-archive— archive as-is, warnings accepted
/neural:neural-address-review— fix blocking issues and gaps automatically/neural:neural-debug— investigate manually- Fix manually and run
/neural:neural-reviewagain