By skyforbes Most of my prompt struggles on real codebases aren’t about wording, they’re about context size:
- I don’t want to shovel half the repo into every prompt
- But I do want the model to understand the overall architecture and key relationships
Lately I’ve been experimenting with a two-step setup before any “real” prompts:
1. Build a low-token “skeleton” of the project
- Walk the codebase
- Keep function/class signatures, imports, docstrings, module structure
- Drop the heavy implementation bodies
The idea is: give the model a cheap, high-level picture of what exists and how it’s laid out, without paying for full source.
2. Build a symbol map / context graph from that skeleton
From the skeleton, I generate a machine-readable map (YAML/JSON) of:
- symbols (functions, classes, modules)
- what they do (short descriptions)
- how they depend on each other
- where they live in the tree
Then, when a task comes in like “refactor X” or “add feature Y”, I:
- query that map
- pull only the relevant files + related symbols
- build the actual prompt from that targeted slice
So instead of “here’s the whole repo, please figure it out”, the prompt becomes closer to:
In practice this seems to:
- shrink token usage a lot
- make behavior more stable across runs
- make it easier to debug why the model made a decision (because I know exactly what slice it saw)
I wired this into a small local agent/orchestration setup, but I’m mostly curious about the pattern itself:
- Has anyone else tried a “skeleton + symbol map” approach like this?
- Any gotchas you ran into when scaling it to bigger repos / mixed code + docs?
- Do you see better ways to express the “project brain” than a YAML/JSON symbol graph?
Would love to hear how others here are handling context once it no longer fits in a clean single prompt.