Context-driven development: how to give coding agents the project, not just the repo

Context-driven development means a coding agent reads the project's context before it writes code: the goal, the decisions already made, the outcomes in flight, and the work that is open. The repository tells an agent what exists. The project tells it why, and what should happen next. Give it both, at the start of every session.

What is context-driven development?

Context-driven development is a way of working where written project context comes first and code follows from it. The agent reads that context at the start of a session, works inside it, and the context is updated when the work changes it.

The term is spreading through open-source agent tooling. One open-source plugin collection for coding agents lists a context-driven development plugin built around tracks, specs, and phased implementation plans. The common idea across these tools is simple: an agent should not have to guess what the team is trying to do.

Why is the repository not enough context?

The repository is not enough because it records what was built, not what was decided. Code shows the path the team took. It rarely shows the paths the team rejected, the result the work is meant to move, or the call that is still open.

That gap causes familiar mistakes. An agent revives an approach the team already dropped. It follows an old TODO that conflicts with the current goal. It makes a product decision while calling it an implementation detail. The code it writes can be clean and still be the wrong work.

What do repository instruction files cover?

Repository instruction files cover how to work in the code. They are the right place for build commands, style rules, and warnings.

AGENTS.md describes itself as a README for agents: a project overview, build and test commands, code style, testing, and security notes. Claude Code reads CLAUDE.md files at the start of every session, and it can read an existing AGENTS.md in place of one.

These files are the first layer of context, and every repository should have one. They work best for rules that change slowly. They are a poor home for facts that change every week, such as which decision was made yesterday or which piece of work is next.

What project context should a coding agent read?

A coding agent should read the goal, the decisions, the outcomes, and the open work, in one short pack. The goal tells it what matters. The decisions tell it what not to reopen. The outcomes and open work tell it where its task fits.

A practical checklist:

• The goal. The one metric the project aims at.
• Recent decisions. What was picked, why, and what was not picked.
• Outcomes in flight. The result each current piece of work should move.
• Open moves. The next pieces of work, and who owns each one.
• Current documents. The specs and plans the work is based on.

Keep it short. An agent's context window is shared with the code it reads, so a long dump of old notes can crowd out the work in front of it.

How does Ask The W give coding agents the project?

Ask The W serves the project as one context pack that a coding agent reads at the start of a session. The pack covers the W Card, the North Star, outcomes, decisions, next moves, and current documents.

The Ask The W plugin connects through https://my.askthew.com/api/mcp. It works with Claude, ChatGPT, Claude Code, Codex, Cursor, and other AI apps that support MCP connectors. Claude Code and Codex install it from their plugin marketplaces.

Once connected, the agent can read the pack with get_project_context, and read full project documents when it needs more. The pack comes from Way by Ask The W, which keeps the decisions, outcomes, next moves, and North Star.

The agent can also write back, but only when a person asks. It can push an update, record a decision, or add a move to Way. Every write needs an explicit request from the user. A person still decides what gets built and what the project commits to.

How do you start with context-driven development?

Start by writing down the three decisions you would least want an agent to reopen. Put them where the agent reads at the start of every session, and check whether its next change respects them.

Then add the goal and the open work. When a session changes a decision, record the change in the same place, so the next session starts from the new state rather than the old one.

For how this works with Ask The W, see context-driven development.