agentsclimarketplace

Port audit

Skill ecfromthedc/ec-rt-skills/port-audit

Audit a Python, Node, or other original against its Rust or cross-language port for CLI, schema, output, side-effect, and failure parity; determine cutover readiness and identify required repo-native fixture evidence. Use when comparing a rewrite to its source, checking port drift, deciding which implementation can become the source of truth, or preparing to retire the original.From its SKILL.md

Install
npx -y skills add ecfromthedc/ec-rt-skills --skill port-audit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.6 KB, 684 tokens by cl100k_base, as published. Nobody here has run it

Port Audit

Produce one evidence-backed verdict: READY, BLOCKED, or NOT_COMPARABLE. Default to read-only. Do not fix drift or retire either implementation unless the user asks.

Establish the contract

  1. Read repository instructions and resolve the exact source and port revisions.
  2. Trace current entrypoints and callers. Ignore dead modules and roadmap prose.
  3. Define equivalent reachable call-chain boundaries before scoring. If responsibilities live at different layers, compare the callers that complete the same behavior; if no boundary can be paired, mark the surface MISSING (unresolved boundary) and return BLOCKED.
  4. Treat the running original as the executable specification unless a committed contract explicitly supersedes it.
  5. Inventory observable behavior only:
    • commands, flags, defaults, and exit codes;
    • accepted inputs and validation;
    • stdout, files, JSON, HTTP bodies, and ordering;
    • state mutations and external side effects;
    • error and retry behavior.

Record each surface as PARITY, DRIFT, MISSING, or N/A with source and port locations.

Prove parity

  1. Reuse an existing fixture or golden test before creating one.
  2. Start with one small fixture that exercises the highest-value common path. Add another only when a distinct critical contract cannot fit the first.
  3. Run both implementations on the same local input without credentials or live-service writes.
  4. Compare raw bytes when consumers observe bytes. Parse before comparison only when the contract is semantic, such as JSON with irrelevant key ordering.
  5. Do not normalize away timestamps, ordering, whitespace, missing fields, or errors unless the committed contract says they are irrelevant.
  6. If implementation is authorized, prefer a repo-native regression test in the port repository. Otherwise provide the exact commands and expected comparison without editing.

Decide cutover readiness

Return READY only when every critical reachable surface has parity evidence and the original is no longer required for an uncovered runtime path.

Return BLOCKED when any critical surface is missing, drifting, untested, or still operationally owned by the original. Name the smallest next proof or fix.

Return NOT_COMPARABLE when the supposed port serves a different contract or the original is already retired by design. Do not force a migration from a stale premise.

Guardrails

  • Keep creative policy, credentials, deployment, and network execution out of fixtures.
  • Do not equate matching types, dependencies, line counts, or function names with behavior parity.
  • Do not invent a universal runner or shared abstraction. Leave proof where the port's normal test command will keep running it.
  • Preserve error paths and side-effect order; successful output alone is insufficient.
  • Stop after the first cutover-blocking drift if the user requested only the next actionable issue.

Report

Use this compact shape:

Verdict: READY | BLOCKED | NOT_COMPARABLE
Source: <revision + entrypoint>
Port: <revision + entrypoint>

| Surface | Status | Evidence |
|---|---|---|
| ... | PARITY/DRIFT/MISSING/N/A | paths, fixture, command, or exact mismatch |

Runnable proof: <repo-native command>
Next action: <one smallest action, or "retire original">

What ships with it: 1 file

230 B alongside SKILL.md

agents/

Gives 0 of the 12 instructions most audit compliance skills give in 684 tokens

Counted across 937 of the 1,487 authors here whose files we hold, read 2026-08-07

  • Fetch latest guidelines before each reviewin 43 of 937, across 3 files
  • Group findings by severityin 43 of 937
  • Check files against all fetched rulesin 42 of 937, across 2 files
  • Output findings in terse file:line formatin 41 of 937, across 3 files
  • Ask user which files to review if none specifiedin 41 of 937, across 3 files
  • Read specified files or prompt user for filesin 39 of 937, across 1 file
  • Generate the audit reportin 33 of 937, across 30 files
  • Assign a severity to every findingin 25 of 937
  • Run automated accessibility scansin 23 of 937, across 13 files
  • Output a markdown audit reportin 22 of 937
  • Map findings to WCAG criteriain 20 of 937, across 10 files
  • Confirm audit scopein 19 of 937, across 9 files

Said here and by no other author read

  • resolve exact source and port revisions
  • trace current entrypoints and callers
  • define equivalent reachable call-chain boundaries before scoring
  • treat the running original as the executable specification
  • inventory observable behavior only
  • record each surface with source and port locations

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.