You know the loop. You ask an agent to add authentication. It adds authentication. You ask for structured logging, then for tests, then for a CI step to run those tests, then a health check endpoint because the deploy needs one. Six prompts later you have a working feature, and you’ve spent the whole session doing what a template used to do in fifteen minutes: filling in the blanks one at a time, just prompted instead of coded.

It’s scaffolding through a chat window.

Before going further, it’s worth naming what’s actually being solved for here. It isn’t a context store. It isn’t a skill either. The goal underneath both is getting the right context into an agent’s hands reliably, without you retyping it every session. A context store is one way to do that today. Skills are another. Whatever ships next, a sharper memory layer or some tool nobody’s built yet, will be chasing the same need.

The challenge Link to heading

What would it take to make your next entire app build one-shot? Not “mostly there after a few rounds of fixes,” but a single prompt that produces production-ready code on the first pass. Could you actually give an agent enough context to execute the whole implementation in a single go?

For most of us, the honest answer is no. The model isn’t the constraint; I hadn’t written down what “everything” looks like.

Why prompting one piece at a time keeps you stuck Link to heading

Every prompt you send only encodes what you happened to type into it that day. Ask for auth and you’ll get some implementation of auth, JWTs or sessions, whichever the agent has seen most often. Unless you say which one your team actually uses, you’re rolling dice, and you’ll roll them again tomorrow on a different repo, because nothing you said today stuck.

The real cost of piece-by-piece prompting isn’t obvious because it doesn’t feel slow, it feels fast. The problem is that it never compounds. You are the context the agent is missing, and you have to keep supplying it, one message at a time, across every repo you touch.

Build a context store instead Link to heading

There’s a better unit of work than the prompt: a context store. A centralised written place that holds the conventions and decisions you’ve already made.

Picture the loop this way: You request a feature and the agent checks the store, so it can write code that already matches how you work, and when it makes a decision worth keeping, that decision gets written back into the store. Next time, a different repo, a different week, nobody has to relearn it.

That loop is the trick.

What about skills? Link to heading

A context store isn’t the only way to carry knowledge between repos and agents. Skills are the other pattern you’ll run into, and they solve a real but different slice of the problem.

A skill is a packaged, triggered set of instructions: a name, a description, steps to follow, sometimes tools bundled in. When something in the conversation matches, the skill fires a process without guessing the right way. Being event driven gives skills an edge. They’re also well known, with a distribution pattern everyone understands: package it up and hand it off.

But being event driven, a skill only helps if something, a keyword or a command, tells the agent to reach for it. That makes skills a great fit for narrow, nameable jobs: running a release checklist, deploying to a specific platform, formatting a changelog. But it’s a poor fit for the sprawling, disparate stuff that doesn’t have one obvious trigger, that isn’t a clear task so much as a way of working. Nobody reaches for a skill called “make error handling project specific.”

That gap is exactly what a context store is for. It’s built for holistic, wide-reaching conventions that need to be everywhere, not just the moments that happen to match a pattern.

Both are great tools: skills are how you hand over a runbook for something you already know, and a context store is how you hand over the conventions nobody thinks to ask about until the code’s already wrong. I propose that most repos need both.

What actually goes in it Link to heading

Governance Link to heading

Somebody has to own the store itself, or it turns into a dumping ground. That means a taxonomy for what belongs where, and an index that maps every page to a domain so an agent (or a new hire) can find the right doc in one hop. It also means a trigger for when each page needs revisiting, tied to a real event rather than “someday.”

Language and code Link to heading

A style guide per language you actually use, not a generic one pulled from a blog post. Error handling and exception conventions, so an agent doesn’t invent its own halfway through a file. API contract and versioning rules, so the fifth endpoint it writes looks like the first.

Testing and quality Link to heading

What “tested” means at your company: coverage scope, which layers get unit tests versus integration tests, how dependencies get pinned and bumped, and which lint and type checks are non-negotiable before a commit lands. Write this down once and an agent stops guessing.

Security and identity Link to heading

Auth and credential precedence: which system wins when two disagree. Where secrets actually live and how they get delivered to a running service. The least-privilege rules your IAM setup is supposed to enforce, spelled out plainly enough that an agent requesting a new permission can tell whether it’s reasonable before it asks.

CI/CD and developer experience Link to heading

Pipeline stages and merge gates. Pre-commit hooks and the repo hygiene they enforce. A release and versioning scheme that isn’t reinvented per project. One command surface, so “how do I run this” has a single answer no matter which repo you’re in. And a note on which tooling and docs an agent should reach for first, so it isn’t guessing at your stack from scratch.

Infra and observability Link to heading

Infrastructure as code conventions, plus resource naming and tagging. A deploy and rollback model that’s actually been used in anger. Logs, metrics and traces, not just whichever one someone remembered to wire up. Liveness and readiness checks, and the alerting sitting on top of them.

LLM Wiki Link to heading

Organising knowledge stores used to be arduous. llm-wiki, Karpathy’s structure for this kind of storage, is what changed that for me. That, combined with Google’s extensible OKF format, is what I landed on. It’s easily visualised in Obsidian, but is still just folders of markdown files.

How do we work together? Link to heading

I made this exact change to this blog’s own .claude/CLAUDE.md this week. Instead of cramming every convention into one file that grows forever, it now points at an external context store: a folder called the AgentContextStore that any agent working on this repo is told to consult before making an architectural or engineering decision.

What I want to do next is to encourage us all to do the same. Store the ways you want to work, whether that ends up as a context store entry, a skill, or whatever tool replaces both, and share it when we work together, so our agents code right first time.

A good context store means I don’t have to explain the project’s conventions every time a new hot shot developer joins, and I can hit the ground running with a new repo in the first minute, because it already has almost everything it needs to know.

Start with one module Link to heading

Don’t try to write the whole context store this weekend. Look at the list above and find the thing that’s thinnest in your own fave repo right now, the one where every agent session ends up asking you the same question. Write that module down this week. Point your CLAUDE.md or AGENTS.md at it.

Do that once, and the next feature you ask an agent to build might not need six prompts. It might just need one.

And if what you’re writing down turns out to be a narrow, nameable job rather than a sprawling convention, package it as a skill instead. The format matters less than the outcome: context, wherever it lives, that an agent can reach for without you saying it out loud again.