Gibson Audit

---
name: gibson-audit
description: "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')."
---

# 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 (headers, rate limits, sandboxing), and
   anything touching production data. These paths get Tier-C treatment
   regardless of what the repo's own docs say.
6. **Deployment posture** — if a live/preview URL exists, run
   `scripts/posture-probe.sh <url>` from the Gibson clone for headers/cookies/
   rate-limit reality. Preview/staging only — never burst production.

## Report format

Two parts, always both:
- **For the owner (plain English, Ask Contract style):** what the repo is, how
  healthy it is, what's missing before agents can safely run unattended, and
  anything that genuinely needs their decision. No jargon unexplained.
- **Gap list (machine part):** checkbox list of missing guardrails with the
  exact `gibson-setup` action for each. Return it inline by default. If asked
  to persist it as `gibson/audit.md` in the target, that write goes through a
  worktree + branch like any other mutation (Law 3) — persisting the audit is
  the one thing that graduates this skill out of read-only mode, so it follows
  the write rules.

Truthfulness rule (Law 8): report what IS, including pre-existing test failures
and scary findings. Never soften a gap because it's awkward.