gibson-auditlisted

Audit any repository for Gibson-readiness: what the product is, stack, test/CI/gate coverage, backlog shape, risk surfaces (money, auth, consent/PII, security boundaries, production data), and a plain-English readiness report with concrete gaps. First stage of the /gibson pipeline; also useful standalone ('audit this repo', 'is this repo ready for the fleet', 'gibson readiness check').
The-AIE/the-gibson · ★ 1 · Data & Documents · score 67

Install: claude install-skill The-AIE/the-gibson

# gibson-audit — know the repo before touching it Input: a repo path or GitHub URL (clone to a scratch location if URL-only). Output: a readiness report the owner can read without knowing how to code, plus a machine-usable gap list the `gibson-setup` skill consumes. ## What to inspect (read-only by default — the ONLY write this skill may ever make is persisting the audit report, and that goes through a worktree per Law 3) 1. **Product identity** — README, package.json/pyproject, deployed URLs. One paragraph: what this software does, for whom. 2. **Stack + build reality** — language, framework, how to build/test/run. Actually run the test suite if cheap; report pass/fail truthfully. 3. **Guardrails present vs missing** — checklist against the Gibson baseline: - `AGENTS.md` (or section) with fleet rules? - CI running tests on PRs? Required checks configured? - Branch protection on the default branch? - Risk classifier / Tier-C gating (money, auth, consent/PII, security boundaries, production data)? - DCO or sign-off convention? - Secrets hygiene (gitleaks or equivalent)? - Kill switch (`gibson/HALT` support comes free with the loop)? 4. **Backlog shape** — open issues: how many are well-scoped with acceptance criteria vs vague? Is there a plan doc? (No usable backlog → the pipeline must run `gibson-direct` before `gibson-run`.) 5. **Risk surfaces** — grep for ALL Law 7 categories: money/payments, auth, consent/PII, security boundaries