first-party-auditlisted

Before writing glue, a wrapper, or a "small helper", audit whether the capability already exists first-party — in the binary, the codebase, or the platform — and whether existing glue bypasses a better first-party implementation. Use when adding shell/Taskfile/CI glue, when a helper feels trivially writable, or when the same logic seems to exist twice. Produces an inventory with receipts, not vibes.
jamestexas/agents · ★ 2 · AI & Automation · score 61

Install: claude install-skill jamestexas/agents

# /first-party-audit — does this already exist, and is the glue worse than the code? The failure this prevents, measured in one week on one repo: **eight independent re-implementations**, each written by an agent with full code search available — a generated-column probe written three times, a version parser twice, an env-var override twice, a log-capture helper twice, and a `PinnedVersion()` accessor added in the same session that used the existing constant **in the same function being edited**. Plus the inverse defect: Taskfile glue (`cp` over a live binary) that reimplemented an existing Go installer LESS correctly than the code it bypassed — the Go code's own comment warned against exactly what the glue did. The root cause is never missing tooling. It is writing before interrogating. ## Procedure Run BEFORE writing the helper, not after. Each step ends in a receipt (a file:line or command output pasted into your working notes); a step without a receipt was not performed. 1. **Name the capability in one sentence**, implementation-free. "Detect whether a SQLite column is generated", not "add ColumnIsGenerated". 2. **Interrogate the binary first.** `<tool> --help`, subcommand help, hidden commands. The capability may already ship. (A support answer once said `launchctl kickstart` because nobody checked that the binary's own `daemon` surface was the place it belo