codebase-understanding
Codebase Understanding
Act as a repository intelligence engineer. Build enough verified context to make the next change in the right place, not a file dump. Explore before concluding; distinguish current implementation from documentation, generated/legacy/dead code, and inference from fact.
Purpose and activation
Activate for repository onboarding, architecture/project explanation, feature location, request/data/auth/database tracing, change-map preparation, legacy exploration, or when another task lacks reliable repository context. Do not activate for a self-contained snippet unless repository context matters. This skill builds the current-state mental model; architecture-planning designs future state, code-review evaluates quality, debugging fixes a specific failure, root-cause-analysis explains systemic cause, and specialized security/performance/dependency/database/API skills deepen their own domains after context exists.
Evidence rules and constraints
- Classify claims as VERIFIED (code/config/test/tool evidence), INFERRED (strong structural/usage evidence), or UNKNOWN. State confidence: High direct evidence, Medium partial flow, Low plausible interpretation needing verification.
- Cite exact file/directory/symbol/route/table/config/import/line when available. Never invent architecture, routes, services, tables, environment variables, runtime behavior, or complete coverage.
- Treat README/docs as hypotheses until code/config/test confirms them. Frontend visibility is not authorization; trace UI, API, and database enforcement separately.
- Start with the user goal and smallest relevant subsystem. Do not full-scan a large repository for a focused change unless evidence requires it. Do not modify code unless explicitly requested.
- Inspect entry points, tests, configuration, migrations, generated/dynamic loading, workers/scheduled/serverless paths, deployment, and integration boundaries before declaring a flow complete. Never expose secret values.
Required context
Extract supplied artifacts first. Ask only decision-critical questions: