← ClaudeAtlas

steering-headlisted

Use when one private repo decides and audits for public repos it owns: before building an instrument, when writing a bare #N issue reference, or when an artifact's home repo is unclear.
MrBinnacle/skills · ★ 0 · AI & Automation · score 68
Install: claude install-skill MrBinnacle/skills
# A private steering head over public repositories ## Problem A common and unnamed topology: **one private repository decides, and two or more public repositories ship.** The private repo holds the reasoning, the audits, the doctrine and the staging of launches; the public repos hold the artifacts the world sees. It works well, and it has failure modes that only appear at the seams between the repos. Every one of them produces a *confident* wrong answer rather than an error, because each repo is internally consistent and the contradiction lives in the gap. ## Context / Trigger Conditions - You are in the steering repo and about to answer a question about a sibling **from memory, from the steering repo's own docs, or from public literature**. - You are about to build any instrument — a script, metric, harness, gate, checker, receipt schema, dashboard, fixture set or scoring procedure. - You are writing, parsing, or matching an issue reference that may be read in a different repo than the one it names. - You are aggregating board health, drift counts, coverage or defect totals **across** repos. - An artifact has just been produced and more than one repo could plausibly hold it. - An index, map or manifest in one repo points at tickets in another. ## Solution ### 1. The nearest prior art is the sibling, and it outranks the literature Before building an instrument, **read the siblings.** A prior-art sweep that cites the outside literature and skips the repo one dire