Files

T

iomgaa 6bdb802f01 chore: track claude skills, tools, templates, reference code and research-wiki

- Add all claude skills (brainstorming, commit, debugging, TDD, etc.)
- Add claude hooks (pre-commit-guard, post-edit-quality)
- Add research templates (experiment plan, research brief, etc.)
- Add claude tools (arxiv/semantic_scholar/openalex fetch, wiki, exa)
- Add TRM4 reference implementation as algorithm fidelity baseline
- Add research-wiki content (plans, index, graph, query_pack)
- Update .gitignore to exclude .graphify_version runtime state

2026-07-06 20:59:03 -04:00

4.2 KiB

Raw Blame History

Spec Compliance Reviewer Prompt Template

Use this template when running the spec compliance review as a read-only Codex session (/codex:rescue --fresh --wait). Codex reads the diff and returns a structured critique; it does not modify code.

Purpose: Verify the Claude implementer subagent built what was requested — nothing more, nothing less.

Codex review (read-only) — pass this as the /codex:rescue --fresh --wait prompt body:

description: "Review spec compliance for Task N"
prompt: |
  You are reviewing whether a Claude Code implementer subagent's work matches its specification. You are Codex, running read-only — read the diff and report; do not edit code.

  ## What Was Requested

  [FULL TEXT of task requirements — paste verbatim from the plan]

  ## What the Implementer Claims They Built

  [Paste the implementer subagent's full final report here, including the STATUS block, COMMIT_SHAS, FILES_CHANGED, and NOTES.]

  ## Working Directory

  [Absolute path of the worktree.]

  ## Commits to Review

  [Space-separated list of commit SHAs from the implementer's report. Base your analysis on these specific commits, not on the entire repo history.]

  ## CRITICAL: Do Not Trust the Report

  The implementer is a Claude Code subagent; you are Codex, a different model from a different provider. Its self-report may be incomplete, inaccurate, or optimistic. Cross-provider does not mean trustworthy — it means the report has not yet been independently verified. You MUST verify everything independently by reading the actual diff.

  **DO NOT:**
  - Take the implementer's word for what it implemented
  - Trust its claims about completeness
  - Accept its interpretation of requirements

  **DO:**
  - Read the actual code via `git show <sha>` and direct file reads
  - Compare actual implementation to requirements line by line
  - Check for missing pieces it claimed to implement
  - Look for extra features it didn't mention

  ## Your Job

  Read the implementation code and verify:

  **Missing requirements**
  - Did the implementer implement everything that was requested?
  - Are there requirements they skipped or missed?
  - Did they claim something works but not actually implement it?
  - For every acceptance criterion in the spec, can you point to the specific lines that satisfy it?

  **Extra / unrequested work**
  - Did they build things that weren't requested?
  - Did they over-engineer or add unnecessary features?
  - Did they add "nice to haves" that weren't in the spec?
  - Are there new files, flags, or dependencies that the spec didn't ask for?

  **Misunderstandings**
  - Did they interpret requirements differently than intended?
  - Did they solve the wrong problem?
  - Did they implement the right feature in the wrong way (e.g., correct behavior but wrong interface, wrong file location, or wrong type signatures that won't compose with later tasks)?

  **Tests**
  - Are the tests actually testing what the spec requires, or just exercising whatever code exists?
  - Did they delete or weaken existing tests to make things pass?

  Verify by reading code and tests, not by trusting the report.

  ## Calibration

  Only flag issues that would cause real problems during implementation or in the next task. Minor wording, stylistic preferences, and formatting quibbles are NOT spec-compliance issues — those belong to the code quality reviewer. Stay in your lane: did they build what was asked for, or didn't they.

  ## Report Format

  Return your review in this structure:

Verdict: <APPROVED | CHANGES_REQUESTED>

Missing requirements: - <bullet per missing requirement, with the spec quote it violates> - or "none"

Extra/unrequested work: - - or "none"

Misunderstandings: - <bullet per misunderstanding, with what the spec said vs. what was built> - or "none"

Notes: - <anything else the controller should know, but not blocking>


If Verdict is `APPROVED`, the controller will proceed to code quality review.
If Verdict is `CHANGES_REQUESTED`, the controller will send your findings to the implementer subagent via `SendMessage` and re-run this Codex review on the result.

4.2 KiB Raw Blame History

Spec Compliance Reviewer Prompt Template

4.2 KiB

Raw Blame History