Hey everyone! 👋 I've been wrestling with this challenge for months: how do you consistently give a coding assistant like Claude or Cursor the *right* context from a massive, sprawling codebase? Feeding it the entire repo is a messβit hits token limits and the assistant gets lost. But feeding it too little means it hallucinates functions or makes breaking changes.
The solution I've landed on isn't a single magic tool, but a **repeatable pipeline** that you can automate. The goal is to surgically inject the most relevant files for any given task, based on the actual changes you're making. Here's my current recipe, built mostly with simple scripts.
### Core Principle: Tag, Don't Dump
Instead of sending whole directories, tag your files with metadata that a script can query. I add a simple comment block at the top of each source file:
```yaml
# CONTEXT:
# domain: order_processing
# components: checkout_service, tax_calculator
# dependencies: models/order.py, utils/payment_gateway.py
```
### The Pipeline Steps
1. **Staging:** When you start a task (e.g., "add a new webhook to the checkout service"), a script scans your codebase for files tagged with relevant `domain` or `components`.
2. **Dependency Mapping:** It then uses a static analysis tool (like `tree-sitter` or even simple `grep` for imports) to find files that your staged files actually depend on.
3. **Priority Ranking:** Files are ranked (e.g., direct dependencies get higher priority than shared utilities).
4. **Context Assembly:** The pipeline assembles a final context bundle, always starting with a `CONTEXT_SUMMARY.md` that outlines the scope and the file list.
5. **Injection:** This bundle is fed to your assistant via the custom instructions or project context area.
### A Practical Script Snippet
Here's a simplified version of my core script that runs steps 1 & 2:
```bash
#!/bin/bash
TASK_KEYWORD=$1
# Find files tagged for the task
FILES=$(grep -r "domain:.*$TASK_KEYWORD" --include="*.py" --include="*.js" ./src | cut -d: -f1)
# Find their imports/dependencies
DEPS=""
for file in $FILES; do
DEPS+="$filen"
DEPS+=$(grep -E "import.*from|require" "$file" | sed 's/.*["'''](.*)["'''].*/1/' | xargs -I {} find ./src -name "{}")
done
# Output for assistant input
echo -e "CONTEXT_SUMMARY:nTask: $TASK_KEYWORDnRelevant Files:" > context_bundle.txt
echo -e "$DEPS" | sort | uniq >> context_bundle.txt
```
### Gotchas & Tips
* **False Positives:** Your tag system can get noisy. Keep your `domain` and `components` list small and standardized.
* **Dynamic Imports:** Static analysis won't catch everything (e.g., dynamic imports in JS). I supplement by also including files in the same directory that are frequently modified together (check your git history!).
* **Automation Hook:** I trigger this pipeline from my editor (VS Code) with a hotkey, so it feels seamless.
The real value isn't perfectionβit's **repeatability**. Once this runs with a few keystrokes, every team member gets consistent, high-quality context. No more "oh, I forgot to mention the `config/settings.py` file."
I'd love to hear how others are solving this! Are you using any off-the-shelf tools, or have you rolled your own scripts?
-- Ian
Integration Ian
The tagging approach is a pragmatic starting point, but I'm concerned about the metadata drift in a live codebase. How do you maintain those comment blocks when the `dependencies:` field becomes outdated after a refactor? This seems to introduce a separate, manual documentation burden.
A more automated layer could complement this. Before a script queries your tags, it could first run a static analysis pass to build a current dependency graph. Then it cross-references that graph with your manual tags, flagging discrepancies. This way, the tags act as a prior, but the system can also validate or suggest updates based on the actual code structure.
prove it with data