mcpField
R
reference-hunt

reference-hunt

github.com/neeeophyteeDevelopment357141 installsUpdated 4w ago
Repository

About reference-hunt

A development skill for studying existing source code as a behavioral specification before reimplementing it in another stack. It emphasizes confirming extracted semantics, following target conventions, and respecting licenses.

Key features

  1. 01Identify the behavior to extract
  2. 02Summarize guarantees and edge cases
  3. 03Confirm the interpretation before coding
  4. 04Reimplement semantics using native idioms
  5. 05Track divergences and license constraints

Use cases

  1. 01Recreate a library behavior in another language
  2. 02Match an existing interface or visual system
  3. 03Port behavior from a vendored codebase
  4. 04Avoid copying code with incompatible licensing

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/neeeophytee/finding-unknowns-skills --skill reference-hunt

After installing, type/reference-huntin Claude Code to confirm it loaded.

Details

From the project README

Reference hunt

Some requirements are too intricate or too tacit to write down, but working code somewhere already embodies them. The best reference is not a screenshot or a description — it's source. Read it like a spec, then reimplement the semantics, not the syntax.

Steps

  1. Get the reference: a repo path, a vendored folder, a library name, or a site whose underlying code can be read. Ask what specifically to extract from it — behavior, structure, visual system, API shape — so you don't imitate the wrong dimension.
  2. Read the reference and produce a semantics summary before writing any code:
    • the behaviors and guarantees it implements (timing, ordering, error handling, edge cases),
    • the decisions that look deliberate versus incidental,
    • anything that won't translate to the target language or stack, with a proposed equivalent.
  3. Have the user confirm the semantics summary. This is the moment misreadings get caught cheaply.
  4. Reimplement in the target stack: same semantics, native idioms. Do not transliterate line by line, and do not copy code verbatim from references whose license doesn't allow it — note the license if it's unclear.
  5. Close the loop: list each behavior from the summary and where the new implementation honors it, plus any place you consciously diverged and why.

Guardrails

  • The reference defines what; the target codebase's conventions define how.
  • If the reference itself turns out to be buggy or inconsistent, surface that instead of faithfully reproducing the bug.
  • Respect licenses: extracting semantics is fine; copying incompatible code is not.

Comments

Markdown supported