loading…

Hoard and Recombine

A high-leverage prompting and knowledge-management pattern: hoard working code solutions, TILs, and minimal prototypes, then prompt coding agents to synthesize new systems by combining those existing examples.

save(concept) -> /concepts/<slug>.md + raw provenance
recombine(task) -> grep hoard by task keywords -> link relevant pages

The Mechanism

1. Hoard running proofs: Knowing something is theoretically possible is weak; possessing a tested snippet (in a repo, TIL, or tool catalog) provides ground truth.
2. Recombine via prompts: Feed two or more working snippets into an agent (e.g. PDF.js canvas renderer + Tesseract.js WebAssembly worker) and prompt the agent to combine them into a single coherent interface or tool.
3. Reference codebases in /tmp: Direct agents to clone reference repositories into /tmp to inspect architecture, schemas, and API conventions without polluting the active repository commit tree.

Why it Works

Agents excel at bridging disparate known patterns. Providing working reference code eliminates hallucinated APIs, establishes clear types and constraints, and produces working artifacts with minimal back-and-forth steering.

Failure Modes

Symptom	Root cause	Fix
Hoard becomes a junk drawer	Saving without curation criteria	Only save what you know how to reuse; prune what you have not touched in months
Recombination never happens	Artifacts saved in inaccessible formats	Save as structured, greppable markdown with provenance
Duplicate knowledge drifts	Same insight saved in multiple forms	One canonical page per concept; link variants to it

Rule of Thumb

A hoard earns its keep at recombination time: if the last three tasks pulled nothing from it, the hoard is a liability, not an asset.

Related

• simon willison
• agentic engineering patterns
• build from scratch pedagogy
• context engineering
• tracer bullets