Digest

Digest — cold repo orientation (read-only)

Purpose: land in a repo with zero prior context and come out understanding it, WITHOUT changing anything. This is orientation, not documentation — write nothing to the repo, run nothing that mutates state. If the user then wants it documented, hand off to /full-document.

Docs folder convention. This skill and its siblings read and write repo docs under .docs/ by default. If the repo's runbook names a different docs folder, the runbook wins. Nothing else depends on the name.

Order (cheap → deep, stop-early when the picture is clear)

1. Docs first — README, .docs/, docs/, CLAUDE.md, CONTRIBUTING, any *.md at root. If they exist and are current, they're the fastest truth.
2. Identity — package manifests (package.json / pyproject / go.mod / Cargo.toml / *.xcodeproj / app.json), lockfile → language, framework, package manager, runtime.
3. Shape — top-level dirs + entry points (main/index/App), routing, the folder taxonomy. Read structure, not every file.
4. Backend & data — env keys (names only, never values), migrations/schema, supabase/prisma/drizzle config, API surface (/v1 routes, edge functions).
5. Integrations — external services wired in (Stripe, Supabase, Cloudflare, EAS, third-party APIs), inferred from deps + config + env key names.
6. State — git: current branch, last ~10 commits, uncommitted changes, how far ahead/behind. What was last happening here.
7. Scars — skim for // hack, // TODO, // FIXME, defensive workarounds, a legacy//quarantine dir — the mistake-prone edges.

Efficiency

• Use search/structure tools over reading whole files; sample representative files per subsystem, don't read all.
• Big repo → fan out read-only explorers by subsystem, synthesize their findings. Don't blow context reading linearly.
• Read-only permission posture throughout; if something would write/deploy/install, don't — note it as a suggested next step instead.

Output (the landing)

1. ≤250-char summary: what the project IS, its stack, its current state — dense, plain, no preamble. This is the headline; lead with it.
2. Then (only if useful, still tight): a 3-6 line map — key dirs, entry point, backend, integrations, active branch/last-commit.
3. Ready line: 1-2 inferred next moves based on what you found (uncommitted work in progress, obvious TODO, failing thing, or "clean — what do you want to do"). Then stop and wait.

Reply shape: summary first, map second, "ready — ?" last. No changes made, ever, in this skill.