# Digest

> Cold-open an unfamiliar repo Claude has never touched — read-only digest, then a 250-char summary and ready for the next move. Use when opening an old or inherited project with no context, or on "digest", "what is this repo", "get up to speed here".

- Skill: `danielimad/digest` (Agent Skill)
- Install (CLI): `npx skillmds@latest add danielimad/digest`
- Raw SKILL.md: https://api.skillmd.com/api/skills/danielimad/digest/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: danielimad (https://skillmd.com/u/danielimad)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/danielimad/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 — <inferred next moves>?" last. No changes made, ever, in this skill.

