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
parent 0616d16956
commit 6bdb802f01
98 changed files with 19321 additions and 0 deletions
@@ -0,0 +1,103 @@
+# 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:
+    - <bullet per extraneous addition>
+    - 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.
+```