# Codebase Context > Analyze a repository before engineering work begins and produce a concise context bundle covering structure, entry points, dependencies, tests, conventions, and likely risk areas. Use when the user asks for a codebase overview, wants a Phase 0 understanding pass, or when another skill would benefit from a grounded map of an unfamiliar project before implementation, review, or refactoring. - Skill: `jovd83/codebase-context` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add jovd83/codebase-context` - Raw SKILL.md: https://api.skillmd.com/api/skills/jovd83/codebase-context/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - License: MIT - Author: jovd83 (https://skillmd.com/u/jovd83) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jovd83/codebase-context --- # Codebase Context Build a reliable mental model of a repository before deeper engineering work begins. This skill is a read-first, structure-first analysis pass. Its job is to reduce blind edits, uncover likely ownership boundaries, and hand downstream work a context bundle that separates observed facts from reasonable inference. ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Telemetry & Logging > [!IMPORTANT] > All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate: > `./log-dispatch.cmd --skill --intent --reason ` (or `./log-dispatch.sh` on Linux) ## Use This Skill When - The user asks for a repository overview, architecture summary, or onboarding pass. - A coding task is high risk and should start with a grounded understanding of the repo. - Another skill needs a quick but credible map of entry points, dependencies, tests, and conventions before implementation. - The codebase is unfamiliar, legacy, large, or polyglot enough that guessing would be risky. ## Do Not Use This Skill For - Implementing features, fixing bugs, or writing tests as the main task. - Replacing deep file-by-file investigation when a narrow debugging question already points to a specific module. - Performing security review beyond basic secret avoidance and risk flagging. - Inventing architecture that is not supported by repository evidence. ## Memory Model Use the lightest memory boundary that fits the task. - Runtime memory: Keep the current repository model in working memory for the active task or thread. - Project-local memory: Only persist the context bundle to a file when the user asks for a saved artifact or when a downstream workflow clearly benefits from a local handoff document. - Shared memory: Out of scope for this skill. If cross-agent or cross-project memory is needed, hand off to a dedicated shared-memory mechanism instead of embedding it here. Do not silently promote runtime observations into persistent memory. Persist only information that is stable, useful, and appropriately scoped. ## Workflow Follow this sequence unless the user requests a narrower slice. 1. Establish scope. Clarify the repository root, the user's goal, and whether the output should stay in-chat or be written to a project file. 2. Scan efficiently. Use fast file discovery and avoid generated or irrelevant directories such as `.git`, `node_modules`, `dist`, `build`, `coverage`, `.next`, `target`, and virtual environments. 3. Detect ecosystem signals. Inspect manifests, lockfiles, CI config, test config, and top-level docs to identify language, framework, build system, and operational conventions. 4. Map structure and entry points. Identify the main code areas, likely bootstrap files, public interfaces, routes, commands, jobs, or service boundaries. 5. Estimate test shape carefully. Locate test suites, frameworks, and obvious source-to-test relationships. Report uncertainty instead of inventing precision. 6. Sample conventions. Inspect representative files to capture naming, layering, dependency direction, and common patterns. 7. Surface risks and unknowns. Call out large blind spots, generated code, missing tests, mixed conventions, or areas that require deeper investigation. 8. Deliver the context bundle. Use the template in `assets/context-bundle-template.md`. If the repo is unusual or large, consult `references/analysis-playbook.md` and `references/output-contract.md`. ## Dispatcher Fit When `skill-dispatcher` is selecting this skill, `codebase-context` should usually be chosen when: - the current step is a read-only Phase 0 repository understanding pass - the next skill would benefit from a `repo_context` or `codebase_context_bundle` - the user task is high risk enough that acting before understanding the codebase would be unsafe Typical dispatcher fit: - `intent`: `index_codebase`, `prepare_engineering_context`, `summarize_repository_architecture`, or another Phase 0 repository-analysis intent - `current_artifact_type`: `repo_path`, `workspace_context`, or `routing_request` - `target_artifact_type`: `repo_context`, `codebase_context_bundle`, or `structural_summary` - `allowed_write_risk`: `low` If the task requires both analysis and implementation, this skill is best used as the first step in a `SEQUENCE`, followed by the downstream execution skill. ## Handoff Contract When this skill is invoked from a dispatcher-led workflow, consume inputs in this shape when available: - `intent`: normalized routing intent for the current analysis step - `current_artifact_type`: usually `repo_path`, `workspace_context`, or `routing_request` - `target_artifact_type`: usually `repo_context`, `codebase_context_bundle`, or `structural_summary` - `repo_context`: any existing stack evidence, routing notes, or prior context bundle fragments - `constraints`: delivery boundaries such as `read-only`, `artifact-only`, `stay concise`, or `focus on tests` - `preferred_stack`: the repository-native stack when already known - `allowed_write_risk`: expected to be `low` for normal analysis work Return a result that is easy for a dispatcher or downstream skill to consume: - `deliverable`: markdown context bundle or structural summary - `artifact_type`: `repo_context`, `codebase_context_bundle`, or `structural_summary` - `confidence`: overall confidence level for the artifact - `recommended_next_step`: the next human or skill action that would reduce risk fastest - `follow_on_skill_type`: optional hint such as `execution`, `feedback`, or `analysis` when the next phase is obvious ## Output Contract Produce a markdown context bundle with these sections, in this order: 1. `# Codebase Context: ` 2. `## Executive Summary` 3. `## Tech Stack` 4. `## Structure` 5. `## Entry Points` 6. `## Dependencies` 7. `## Test Coverage` 8. `## Conventions` 9. `## Risks and Unknowns` 10. `## Recommended Next Steps` Within the bundle: - Mark confidence where it materially matters: `High`, `Medium`, or `Low`. - Distinguish observed facts from inference. - Use `Unknown` or `Not found` when evidence is missing. - Prefer approximate language over false precision. - Keep the bundle concise enough to be usable as handoff context. If the user requests a saved artifact, write the bundle to a local markdown file and optionally validate it with: ```bash python scripts/validate_context_bundle.py path/to/context-bundle.md ``` ## Quality Bar A strong context bundle should: - Tell a downstream engineer where to start reading. - Show the likely architecture without pretending certainty where none exists. - Highlight risky or weakly understood areas early. - Preserve the repository's own terminology and conventions. - Be immediately reusable in a later implementation or review task. ## Guardrails - Stay read-only unless the user explicitly asks for the bundle to be saved or updated in the repository. - Never include secrets, tokens, or credential values in the output. - Do not claim test coverage percentages unless they are directly supported by repository evidence or a coverage artifact. - Do not over-scan large repos. Sample representative directories and say what was sampled. - Do not confuse generated code, vendored code, or build outputs with primary source unless the task specifically requires them. - Do not collapse facts and interpretations into a single claim when uncertainty matters. ## Escalation Rules Pause and say so when: - The repository root is ambiguous. - The repo is so large that a representative sample may miss critical architecture. - The user appears to want implementation, debugging, or security review rather than a Phase 0 analysis pass. - The context bundle would be materially stronger if saved as a file for later reuse. ## Bundled Resources - `assets/context-bundle-template.md` Use this as the default response skeleton. - `references/analysis-playbook.md` Read this for monorepos, large repos, mixed-language repos, or ambiguous entry points. - `references/output-contract.md` Read this when you need stricter guidance on confidence, evidence, and section quality. - `examples/sample-context-bundle.md` Review this when you need a model example of the final artifact. - `evals/evals.json` Use these prompts to regression-test the skill's triggering and output quality. - `fixtures/` Use these packaged repository fixtures for end-to-end regression testing. - `benchmarks/README.md` Read this when you need to understand or extend the deterministic scoring harness. - `README.md` Read this for the repository's human-facing explanation of dispatcher alignment, CI, fixtures, and maintenance expectations. - `scripts/validate_context_bundle.py` Use this only when a bundle has been written to disk and needs a quick structural check. - `scripts/score_context_bundle.py` Use this to score one generated bundle against one fixture. - `scripts/run_fixture_benchmark.py` Use this to run the full fixture benchmark suite across packaged examples.