context density in successful openers

analysis of what constitutes dense, effective context in thread openers.

defining “context density”

context density = information per character that reduces agent ambiguity.

high density ≠ long messages. the densest openers pack actionable specifics into minimal tokens:

• file paths (anchors to codebase)
• line references (surgical precision)
• domain vocabulary (assumed expertise)
• verification criteria (success definition)
• thread continuity (inherited context)

the density paradox

from first-message-patterns.md:

u-shaped success curve: brief (60.8%) and extensive (64.6%) outperform moderate (54.7%) and detailed (42.8%).

interpretation: moderate-length messages often have the WORST density. enough complexity to require steering, not enough context to avoid it. they hit a “valley of confusion.”

density markers ranked by impact

1. FILE REFERENCES (+25% success)

file references are the single strongest density signal. they:

• anchor the agent to specific code locations
• eliminate “which file?” questions
• enable immediate tool calls without exploration

golden example (T-019b83dd):

@pkg/simd/simd_bench_test.go @pkg/simd/dispatch_arm64.go...

8 files attached → 0 steering, 5 approvals.

2. THREAD CONTINUITY (+31% continuity rate)

from context-anchors.md:

thread references inherit:

• prior decisions (“I told you to verify bugs before fixing”)
• accumulated context
• established vocabulary

3. LINE-LEVEL SPECIFICITY

golden example (T-019b69d9):

please look at the FUTURE: statement on line 95 of 
@app/dashboard/src/dash/routes/query/aplHelpers/generateStructuredRequestFromQueryRequest.test.ts

20 turns, 2 approvals, 0 steering. agent knew EXACTLY where to look.

4. DOMAIN VOCABULARY

threads that use jargon without explanation outperform:

• “SVE vs NEON” (not “ARM SIMD architectures”)
• “APL syntax” (not “our query language”)
• “race condition” (not “timing bug”)

this signals shared context depth. agent matches expert level.

5. VERIFICATION CRITERIA

every golden thread (0 steering, ≥2 approvals) embedded success criteria:

• benchmarks (“benchstat before.txt after.txt”)
• tests (“run the tests with —tags=integration”)
• dry-runs (“make sure both platforms build”)

explicit verification removes “is this done?” ambiguity.

what LOW density looks like

anti-patterns absent from golden threads:

optimal density formula

from the data:

1. file anchors first — start with @ references
2. line precision when possible — “line 95” beats “the FUTURE statement”
3. thread continuity — spawn pattern (“Continuing work from T-xxx”)
4. domain vocabulary — assume expertise, don’t explain
5. embedded verification — “run tests before committing”
6. brief OR extensive — avoid the 150-500 char valley

density vs length

surgical works for simple tasks: “fix typo in @file.ts line 42”

kitchen sink works for complex tasks: extensive context front-loads all decisions.

moderate explanations fail: complex enough to need context, too brief to provide it.

user patterns

precision_pilot’s approach proves extensive context works when committed. 4,280 char avg openers → 82.2% success.

steady_navigator’s approach proves density over length. moderate length but interrogative style (“how”, “what”) forces precise scoping.

synthesis: the density checklist

before hitting send:

• file anchors: did I @ reference specific files?
• line precision: can I point to a line number?
• thread link: is this spawned from prior work?
• domain vocab: am I using correct jargon?
• verification: how will I know it worked?
• length check: am I in the 150-500 valley? if so, go shorter OR add more anchors

caveats

• success = RESOLVED + COMMITTED (conflates “answered” with “deployed”)
• extensive messages may include automated context injection
• user sample sizes vary (36 vs 1,218 threads)
• density is heuristic, not directly measured in tokens