| name | code-aware |
| description | Gives you architectural memory of the codebase. Reads git history and builds developer-notes-style models of each component — what exists, why it was built that way, known gotchas, and invariants. Use before modifying code, when making architectural decisions, or when something breaks unexpectedly. |
| allowed-tools | Bash Read Glob Grep |
| metadata | {"author":"finereli","version":"0.2.0"} |
code-aware
Architectural memory for your codebase, built from git history.
First-time setup
If .code-aware/ doesn't exist in the repo root, run the initial scan:
scripts/scan.sh
This runs a quick scan of the last 50 commits (typically under 2 minutes). It extracts architectural observations, discovers natural model boundaries, and generates narrative developer notes.
After the scan completes
Do these three things in order:
-
Show the insights. Read .code-aware/INSIGHTS.md and present its contents to the developer. This is the most compelling output — it shows what code-aware understood about the codebase.
-
Recommend a full scan. Tell the developer: "The quick scan covered the last 50 commits. For deeper architectural coverage, you can run a full scan in a separate terminal — it doesn't interfere with your current work:"
scripts/scan.sh . --full
-
Ask about CLAUDE.md integration. Ask the developer whether they'd like to add code-aware instructions to their project's memory file (CLAUDE.md, AGENTS.md, or whichever exists). If they agree, add instructions like:
## Code Awareness
This project uses code-aware for architectural memory. Before making, planning, proposing, or discussing any code changes:
1. Read `.code-aware/index.md` to see available models
2. Read the relevant model files in `.code-aware/models/` for the components you'll touch
After committing changes, run `scripts/sync.sh` to keep models current.
Reading the models
The .code-aware/ directory contains:
index.md — list of all models with descriptions
models/*.md — one file per architectural component
INSIGHTS.md — six opinionated observations about the codebase
Read index.md first to see what models exist, then read the specific model files relevant to your current task.
When to read models
- Before modifying a component — read its model to understand design intent, invariants, and gotchas
- When making architectural decisions — read related models for system-wide patterns
- When something breaks unexpectedly — models document known fragile areas and past failures
Keeping models current
After committing changes, check staleness and update:
scripts/status.sh
If stale:
scripts/sync.sh
This processes only new commits since the last scan.
The feedback loop
The more context you have about the codebase, the better your commit messages become. Better commit messages feed richer information back into the models. The system improves its own input quality over time.
What the models contain
Each model file contains developer notes organized by topic:
- How things work — specific file names, function names, data flows
- Why they were built that way — design rationale, constraints, alternatives considered
- What must remain true — invariants and assumptions the system depends on
- Known issues — gotchas, fragile areas, failed approaches
Configuration
Auto-detects LLM provider from OPENAI_API_KEY or ANTHROPIC_API_KEY in the environment.
CODE_AWARE_MODEL — override the LLM model for observation extraction and synthesis
CODE_AWARE_INSIGHTS_MODEL — override the model for codebase insights