Crypts and Commits: How I'm Working With AI (For Now)
The Audience I Didn't Know I Had — Part Three
One of the stranger things about working with AI coding tools right now is that an idea can feel both useful and temporary.
AI is reducing the cost of producing code. That is exciting. It also means an idea that feels like a differentiator today may be something a competitor can reproduce over a weekend tomorrow. The question is not only, “How much time did I put into this?” It is, “How long does this idea have value?”
That is an uncomfortable question for anyone whose work depends on producing things other people find valuable. It is especially uncomfortable when the thing you are building is development tooling. I can describe the basic ideas behind my package in this article, and there is a reasonable chance someone could vibe-code their own version from the description alone.
There are at least two possible responses to that reality.
One is to keep the idea close: be as secretive as possible, extract whatever value you can before the shelf-life expires, and hope the implementation stays difficult to copy for long enough to matter.
The other is to be public about the idea. Show the work. Explain how you are using the tools, what your team is learning, and where the approach may fail. Generate value not only from the code itself, but from demonstrating judgment and practice in a world where the code is becoming cheaper.
I understand the first response. I am choosing the second.
That is why I am releasing Crypts and Commits.
From a habit to something installable
In the previous post, I described a long-running habit: leave a project in a state where another person can take it over. That person might be a teammate, a new hire, or a future version of me who no longer remembers why the system is arranged the way it is.
AI coding agents made that habit newly valuable. They are stateless between sessions unless the relevant context is supplied again, and they have far more patience for reading context than a human developer should reasonably be expected to have. But the old warning still applies: documentation must be read, and it must not be trusted blindly. A useful handoff is not just a pile of text. It is a record that gets revised when the work reveals that reality differs from the plan.
Crypts and Commits is my attempt to make that practice repeatable without requiring every developer to maintain their own personal collection of Markdown files and prompt rules.
It is not an attempt to make the agent autonomous. It is an attempt to make the developer more capable while working with an agent.
That distinction matters. The package is meant to preserve continuity, reasoning, and receipts. It is not meant to replace the developer’s judgment or turn a coding assistant into a manager.
What Crypts and Commits does
Crypts and Commits bootstraps an MCP server and a set of skills into the current repository. The server keeps working context in the project file system, under normal git tracking. The skills tell the coding agent how to work with that context.
When a project is new, the developer documents the modules and adds the relevant rules. Once the project is set up, someone else can bootstrap the same repository and begin working with the skills, rules, and documentation already there.
The central unit of work is called an encounter. An encounter records four things:
- Requirement - What needs to be accomplished.
- Rationale - Why are we doing this.
- Plan - Steps required to make the change.
- Verification - How are we making sure the change is correct.
The developer still prompts the agent normally. The agent does more of the clerical work: recording the plan, updating it as the work changes, and preserving the artifacts that explain what happened.
The important result is not the names of the files or the mechanics of the server. It is that the context becomes project context instead of private chat history. A useful understanding of the work can survive a session ending, a developer switching tools, or another engineer picking up the repository.
The escape hatch is intentional
One of the design choices I care about most is that a developer does not have to create an encounter before they start working.
They can begin a session, investigate a bug, make a change, and then ask the agent to create an encounter afterward. At first glance, that might look like a way to write a paper trail that pretends the work was planned in advance. That is not the intent.
Sometimes the honest answer to a new request is, “I do not know how I am going to implement this yet.” That is especially true while debugging. You can read a ticket, have an initial hypothesis, and still need to explore the code before you understand the actual problem. An AI coding assistant is not a magic clarity tool.
A framework that demands a formal plan before a developer is allowed to understand the problem is not helping the developer. It is imposing process for its own sake.
The developer needs to remain in charge: deciding when to follow the workflow, when to work outside it, and when to remove it entirely. That is not a loophole in Crypts and Commits. It is one of the core promises of the package.
Context should travel farther than one chat window
The package also exists because I do not think a team should be dependent on one coding assistant.
Between outages, usage caps, and the uncertainty around the current tooling market, “Claude is down right now” should not mean the work stops. A developer should be able to begin a task in one agent, switch to another, and carry the relevant context with them.
This is not a magical one-click migration of an entire project between vendors. It is more practical than that. The skills come from a common workflow definition and are tuned for the individual coding harness. The project context remains in the repository. If a developer needs to switch, an agent is usually self-aware enough of its own harness that porting the skills is close to asking one agent to translate them for another.
That is the team-scale version of the handoff described in Part One. In that case, I planned an architectural change with Claude Code, and a teammate implemented it with Windsurf. The documentation carried the context between different people using different tools. Crypts and Commits is meant to make that sort of continuity less dependent on one person’s personal habits.
Why the name is a game
The name comes from tabletop gaming. I am a gamer for life, and I wanted a vocabulary that moved away from the usual corporate language of tickets, issues, and epics.
That choice is more than a preference for a different coat of paint. Crypts and Commits is not an attempt to replace Jira. The context it captures is not intended to manage a project or improve communication among stakeholders. Its audience is the developer and the agent working together. It is meant to preserve the deeply technical context of how and why code is changing — the detail that helps the next agent session or developer continue the work safely.
In Crypts and Commits, the human developer is the game master and the coding agents are the players. The metaphor is deliberately about authority. The game master establishes the world, interprets what is happening, and gets to change direction. The players take action inside that world.
It also does useful work for the agent. A coherent metaphor gives the system a vocabulary that can imply related behavior without requiring an explicit rule for every term. The metaphor is not just a theme painted on top of the package. It is part of the interface.
I should name one influence honestly. GasTown helped me see how agent workflows could be organized around a strong metaphor and repository-backed artifacts. But the orientation is different. GasTown pursues more autonomy and coordination among agents. Crypts and Commits is built around a developer working with an agent and retaining authority over the work.
It has to be easy to ignore
The initial reaction to this kind of framework is predictable: it can look formal and verbose. It can look like bureaucracy.
That concern is valid. I do not want to build another Jira-shaped process and call it a breakthrough because an AI is involved.
When I introduced the workflow to colleagues, the useful demonstration was not a policy explanation. I built a feature end-to-end, showed that it worked, and checked in the code. Then I started another change in one agent and switched to another partway through, using the package’s documentation to carry the context.
The most important part was offering to go off script and work without the framework while still inside the agent. Showing how easy it was to ignore or remove created more buy-in than insisting that everyone use it.
Crypts and Commits is a dependency and a directory. It does not infect application source code or change how the deployed application runs. A developer can step outside it. A team can remove it. That freedom is not a failure of the process. It is evidence that the developer remains the person in charge.
The agent can carry the formal documentation without asking the human to absorb every page of it. The human decides whether that structure is useful for the work in front of them.
A real-world sibling, not the point of the story
There is a related package at my employer, Revel Labs, called Chi-Town. It is closed source, company-owned, and developed with company time and company assets. Crypts and Commits is my separate open-source package, built with personal time and personal assets. The two packages share broad ideas, but not code.
Chi-Town uses a Chicago permitting metaphor: the human is the Mayor, while the agents are city clerks. It is a sibling joke to the tabletop framing, and it reflects the same intent. Even inside a bureaucracy-flavored system, the human is the person with the most freedom.
I am naming Revel Labs and Chi-Town directly because the company has encouraged employees to write about our AI experiences. This lets me talk about the working approach without exposing client details. But Chi-Town is not the package I am introducing here. Crypts and Commits is the public artifact: the one a reader can inspect, install, adapt, or decide to replace.
Build in public, verify in reality
Crypts and Commits is developed using itself.
That was deliberate. If the package cannot help develop and maintain the package, I do not think it has earned the right to claim it can help develop anything else. It is a form of self-bootstrapping, but more importantly it is a forcing function. It requires me to work within the technical discipline I am asking other people to trust.
The repository is meant to be evidence for that claim, not merely marketing language. Readers can inspect it and decide for themselves whether the practice is visible in the work.
I do not know whether Crypts and Commits will have the same value in six months. It may be replaced by a better idea. If it is, I expect I will be interested rather than defensive. The implementation itself may have a short shelf-life.
That is exactly why I would rather show the work than hide it.
The durable value, if there is one, is not that I have found the final answer to AI-based development. It is that this is an inspectable record of one current way I am trying to work: keep context in the repository, let the agent do more of the clerical work, and keep the human free to exercise judgment.
I may be publishing enough here for someone else to build their own version. That is scary. It is also the point. If implementation gets cheaper, I would rather be known for showing how I — and the teams I lead — are learning to use these tools responsibly than for protecting one short-lived idea behind a curtain.