Paper-to-code: implementation without invention
BLUF: the paper is the only source of truth; every implementation decision is either anchored to it or explicitly flagged as our choice. The dominant failure mode is silent gap-filling — plausible defaults presented as the paper's content. That is neuroslop in code form, and this skill exists to make it structurally impossible.
Stage 0 — acquire the full text
- Prefer arxiv-mcp tools (
download_paper / read_paper) when available; otherwise WebFetch the abstract page and PDF.
- Appendices, footnotes, table captions, and figure captions are first-class sources — missing hyperparameters usually live there, not in the method section.
- If the authors published official code, locate it; it is a second, separately-tagged source — never a silent one.
Stage 1 — ambiguity audit, before any code
Classify every implementation-relevant decision; the tags below are this skill's specialization of the harness claim-typing discipline (epistemic boundary: confirmed ≠ associative):
| Tag |
Meaning |
Obligation |
FACT §X.Y / Eq. N |
stated in the paper |
anchor to the exact section/equation |
PARTIAL §X.Y |
mentioned but ambiguous |
quote the passage verbatim, list the readings |
UNSPECIFIED |
paper is silent |
our default + alternatives, never filled silently |
ASSUMPTION |
inference from context |
reasoning stated next to it |
FROM-CODE |
taken from the authors' implementation |
tagged as code-derived, not paper-derived |
QUESTION |
load-bearing gap that cannot be defaulted safely |
ask the developer before coding — not a guess |
A QUESTION blocks its code path until answered (mental model gate).
Stage 2 — implementation
- Non-trivial decisions carry their
§/Eq. anchor in the audit table; inline flags ([UNSPECIFIED], [ASSUMPTION]) appear only at load-bearing lines. These are constraint provenance the code cannot show by itself — not decoration, so they do not conflict with the no-decoration rule (invariant #9).
- Variable names follow paper notation where that stays readable.
- Standard components are imports: "standard transformer encoder" means a library call plus a dependency note, never a rewrite.
- Scope is the core contribution only, unless training / data / evaluation pipelines are explicitly requested. No baselines, no infrastructure beyond what the contribution needs.
Stage 3 — verification, split by oracle class
- Mechanizable class (external validators): shape checks, conservation or sanity equations stated in the paper, a toy-dimension forward pass on CPU. Run them and paste outputs — claimed completion requires executed machine-checkable evidence (invariant #23).
- Judgment class ("did we implement what they meant"): present the audit table and every divergence to the developer; their sign-off closes it.
- Never claim correctness of the method itself. The implementation matches the text; if the paper is wrong, the code is faithfully wrong — say so in those words.
Output contract
- Ambiguity audit table. 2. Code. 3. Verification outputs. 4. Open QUESTIONs. BLUF at every step.
Counter: when the developer explicitly asks for a quick sketch, pseudocode, or intuition-level walkthrough, the full audit is overhead — state in one line what is being skipped and sketch.
Provenance: discipline distilled from the paper2code pattern (PrathamLearnsToCode/paper2code, surfaced via the ai-boost/awesome-prompts digest); this text is written from scratch for the neuro-matrix harness — no upstream text reused.
1---2name: paper-to-code3description: Implement an academic paper (arXiv or any quantitative source) as verifiable code without inventing unstated details. Use when asked to implement, reproduce, or prototype a method from a paper. Produces an ambiguity audit before code, citation-anchored decisions, and machine-checkable sanity verification.4---56# Paper-to-code: implementation without invention78BLUF: the paper is the only source of truth; every implementation decision is either anchored to it or explicitly flagged as our choice. The dominant failure mode is silent gap-filling — plausible defaults presented as the paper's content. That is neuroslop in code form, and this skill exists to make it structurally impossible.910## Stage 0 — acquire the full text1112- Prefer arxiv-mcp tools (`download_paper` / `read_paper`) when available; otherwise WebFetch the abstract page and PDF.13- Appendices, footnotes, table captions, and figure captions are first-class sources — missing hyperparameters usually live there, not in the method section.14- If the authors published official code, locate it; it is a second, separately-tagged source — never a silent one.1516## Stage 1 — ambiguity audit, before any code1718Classify every implementation-relevant decision; the tags below are this skill's specialization of the harness claim-typing discipline (epistemic boundary: confirmed ≠ associative):1920| Tag | Meaning | Obligation |21|---|---|---|22| `FACT §X.Y` / `Eq. N` | stated in the paper | anchor to the exact section/equation |23| `PARTIAL §X.Y` | mentioned but ambiguous | quote the passage verbatim, list the readings |24| `UNSPECIFIED` | paper is silent | our default + alternatives, never filled silently |25| `ASSUMPTION` | inference from context | reasoning stated next to it |26| `FROM-CODE` | taken from the authors' implementation | tagged as code-derived, not paper-derived |27| `QUESTION` | load-bearing gap that cannot be defaulted safely | ask the developer before coding — not a guess |2829A `QUESTION` blocks its code path until answered (mental model gate).3031## Stage 2 — implementation3233- Non-trivial decisions carry their `§`/`Eq.` anchor in the audit table; inline flags (`[UNSPECIFIED]`, `[ASSUMPTION]`) appear only at load-bearing lines. These are constraint provenance the code cannot show by itself — not decoration, so they do not conflict with the no-decoration rule (invariant #9).34- Variable names follow paper notation where that stays readable.35- Standard components are imports: "standard transformer encoder" means a library call plus a dependency note, never a rewrite.36- Scope is the core contribution only, unless training / data / evaluation pipelines are explicitly requested. No baselines, no infrastructure beyond what the contribution needs.3738## Stage 3 — verification, split by oracle class3940- **Mechanizable class** (external validators): shape checks, conservation or sanity equations stated in the paper, a toy-dimension forward pass on CPU. Run them and paste outputs — claimed completion requires executed machine-checkable evidence (invariant #23).41- **Judgment class** ("did we implement what they meant"): present the audit table and every divergence to the developer; their sign-off closes it.42- Never claim correctness of the method itself. The implementation matches the text; if the paper is wrong, the code is faithfully wrong — say so in those words.4344## Output contract45461. Ambiguity audit table. 2. Code. 3. Verification outputs. 4. Open QUESTIONs. BLUF at every step.4748Counter: when the developer explicitly asks for a quick sketch, pseudocode, or intuition-level walkthrough, the full audit is overhead — state in one line what is being skipped and sketch.4950---51Provenance: discipline distilled from the paper2code pattern (PrathamLearnsToCode/paper2code, surfaced via the ai-boost/awesome-prompts digest); this text is written from scratch for the neuro-matrix harness — no upstream text reused.
AlexShchuka