to-execution
I kept losing work to my own agents. Not in some dramatic way. Just: open a new Claude Code session, ask for a feature, and watch it quietly undo choices the last session made. Different naming. Different file structure. Sometimes it'd refactor something another agent wrote two hours ago because it had no idea that agent existed.
The frustrating part is that Claude Code is good. Like, really good. But every session starts with amnesia, and I got tired of being the only one who remembered what we decided yesterday.
So I built a thing. It's called to-execution and honestly I don't know if anyone else needs it, but it solved my problem and I now run it on every project.
What it actually is
You run npx to-execution init, answer some questions about your project, and it stamps out a folder called .excn/ that becomes your project's memory:
.excn/
CONTEXT.md # glossary + team roster
PHILOSOPHY.md # your project's working rules
PROCESS.md # how work moves (same everywhere)
TEAM_DIRECTIVE.md # who owns what, routing
adr/ # decision records
issues/ # one JSON file per issue
sprint-1/ # issues pulled into a sprint
sprint-2/
prds/ # product requirement docs
sprints/ # one JSON per sprint
schemas/ # JSON schemas for everything
retros/ # sprint retrospectives
research/ # research digests
progress/ # agent-written tracking
runtime/ # heartbeats, pid files
viewer/ # local status page
Agents read this stuff when they start up. The glossary tells them what your terms mean. The team directive tells them which files belong to which agent. The process doc tells them the order things happen. It's just files. JSON and markdown. But because there's a schema for everything, agents follow it. When they don't, a reviewer catches it and fails the step.
The lifecycle, or: why I make myself do an interview before writing any code
Work moves in a fixed order:
grill → PRD → issues → sprint → retro
The "grill" is the part I almost skipped building. It's a structured interview where you have to define what you're building before anyone writes code. I thought it was going to be annoying overhead. It turned out to be, and I realize how this sounds, the most useful part of the whole system.
While building the framework itself, a grill caught that one of my workflows was trying to own three different things: the glossary, the PRD, and design decisions all at once. I would've found that collision weeks later when agents started stomping on each other's files. The grill surfaced it in twenty minutes. The split into separate workflows, each owning one artifact, took a sprint to ship.
After the grill you get a PRD. The PRD gets broken into issues, each one a slice an agent can ship on its own. Issues go into a sprint. When it's done, a retro records what happened.
There are also automated reviewers that check the sequence. They read a rubric and return PASS or FAIL with the specific rules you broke. Can't skip steps. Can't wing it. Two reviewers ship with the framework and you write your own for whatever your project cares about (code standards, naming, whatever) from a shipped template.
It's built on Claude Code but the folder structure and the lifecycle would work with anything that can read files.
The retro thing, which I think is actually the best idea in here
Agent definitions and process docs don't get edited mid-sprint. Period. If something needs to change, it goes through the retro: observations pile up during the sprint, proposed edits get checked against the project's principles at close, and I approve or reject before anything lands.
Before I added this, agent behavior drifted constantly. Any session could edit any definition, and over a few days the project's "rules" would quietly become something nobody intended. It's kind of like if your team's coding standards got silently rewritten every time someone opened VS Code. That's what was happening.
The retro gate fixed it. Definitions stopped mutating between sessions.
Where it's at
The framework's own repo has 11 closed sprints and 12 decision records. I run it across several other projects too: backend platform stuff, CLI tools, data pipelines, this site, a Slack integration. Each one has its own .excn/ directory with its own glossary and team.
What I don't know
I don't know if this works with more than one person driving. Right now it's me and agents. The grill quality depends on you asking good questions, and I haven't tested whether someone unfamiliar with the system can run one well. Setup takes a real session, maybe an hour. And the structure adds friction that doesn't pay off on a weekend hack. You need a project that's going to live for a few sprints.
The repo is public. npm install to-execution.