Paper To Code

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

1. 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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: AlexShchuka
• Source: AlexShchuka/neuro-matrix
• License: MIT

Install and usage instructions live in the source repository linked above.