بنقرة واحدة
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 ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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
| 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