I made Claude Code slower. On purpose. Here's why.

Alex — Thu, 09 Apr 2026 14:10:09 +0000

You're 40 minutes into a Claude Code session. You've lost track of what you decided.

Claude is re-reading files it already read. You're not sure if you're building the right thing anymore, and you're not sure when you stopped being sure.

This is not a Claude problem. It's a structure problem. That's why I built FRAME.

What FRAME is

FRAME is a set of Markdown files that give Claude Code a role to play and a gate to stop at. Nothing installs beyond copying a few files. No config, no runtime, no dependencies. You run /frame load sw-development and Claude Code knows it's a Requirements Engineer now, and that it doesn't move until you confirm what you're building.

The core mechanic: a cartridge defines the phases, roles, and gates for a particular kind of work. The engine reads the cartridge and runs the session accordingly. You keep control at every gate — nothing advances without your y.

That's it. The rest is Markdown.

Two runs, same task

I wanted to test this honestly, so I ran the same bug fix twice — once with plain Claude Code, once with FRAME's sw-development cartridge. Same prompt, same codebase, same starting branch.

The bug: _get_daily_limit() crashes when NOTEBOOKLM_DAILY_LIMIT is set to a non-numeric value or zero. Fix it and add tests.

Plain Claude Code read the function, wrote the fix, wrote the tests, committed. About a minute. No questions asked. The fix was correct.

FRAME started by asking questions. Branch name? Hard constraints? Acceptance criteria beyond what was stated? Anything explicitly out of scope? It produced a SHAPE block before touching a single file:

Goal       : Fix _get_daily_limit() crash - non-numeric or zero env var
Stack      : Python 3.9+, pytest
Branch     : fix/frame-daily-limit-validation
Constraints: none
Acceptance : - Non-numeric → returns 50, no exception
             - Zero → returns 50, no exception
             - Negative → returns 50, no exception
             - Valid numeric → still works correctly
             - At least one test per bad-input case
Out of scope: all other functions, no refactoring, no interface changes

You confirm this, or you push back. Only then does it write code.

Some minutes later, the fix landed. Same correctness as plain CC. But then the QA Engineer ran a pass — mapping every acceptance criterion to a test, checking for gaps. It flagged one: whitespace-only strings (" ") aren't covered. A fourth test, not in the original brief.

Plain CC found its edge cases by instinct. FRAME found them by process.

The honest framing

FRAME didn't produce better code. It produced a documented contract for what the code was supposed to do — agreed before anything was written, verified after.

For a contained bug fix where you know exactly what you want, plain Claude Code is hard to beat. One minute versus ten is a real difference.

FRAME earns its keep when "what does done look like?" isn't obvious before you start. When the session is a decision, not just a task. When you're about to build something that depends on choices you haven't made yet, and you don't want to discover mid-BUILD that you've been building the wrong thing.

The ten minutes isn't overhead. It's the work of agreeing on what you're building before you build it. For the right task, that's the most valuable ten minutes in the session.

That right task looks like: a feature with ambiguous requirements. A codebase you haven't touched in six months. An audit where you need to explain every finding to a stakeholder. A project plan that has to survive a conversation with someone who wasn't in the room when it was made.

In those sessions, the documentation FRAME produces isn't a side effect — it's the point. The SHAPE archive records what was agreed before code was written. The phase archives record what was decided at every gate. The final output is something you can hand to someone who wasn't there and they can reconstruct exactly what happened and why. Plain Claude Code produces an output. FRAME produces an output and a record.

How it works

A session has five phases: SHAPE, BREAKDOWN, DESIGN, BUILD, CHECK.

SHAPE is where the Requirements Engineer extracts the goal, stack, constraints, and scope. No code is touched. The output is a PROJECT.md you confirm before anything else happens.

BREAKDOWN is where the Orchestrator turns the goal into work units — small enough to complete in one context window, sequenced by dependency. The first time I saw the unit list appear I understood why FRAME works: a project that felt overwhelming at the goal level becomes a list of five things, in order, with clear scope. The Tur-Tur effect — something that looks impossibly large from a distance resolves into ordinary steps up close.

DESIGN is where the Architect turns the unit list into a plan — interfaces, dependencies, sequencing decisions. Nothing is built yet. The point is to make implementation choices explicit before a Developer touches a file.

BUILD executes one unit at a time. Gates between units let you /clear context without losing state — FRAME writes everything to file before it stops.

CHECK runs a Code Reviewer and QA Engineer pass. This is where the acceptance criteria table appears, mapped to actual test coverage. Gaps surface here, not in production.

The cartridge is just Markdown. You can read every instruction Claude Code is following. You can edit them. You can build your own in an hour using the cartridge-creator cartridge.

What makes it different from SPARC, claude-flow and others alike

Those tools are powerful. If you want multi-agent orchestration, parallel execution, XML-structured plans, and a framework with a full ecosystem — use them. They're built for that.

FRAME is deliberately smaller. No multi-agent complexity. No tooling overhead. No XML. The entire engine is one Markdown file. The design principle is: if it needs an installer to be useful, it's already too complicated.

If you want a framework, use SPARC or claude-flow. If you want structure without infrastructure, this is for you.

Get it

git clone https://github.com/SeriousByDesign/frame.git
cd frame
bash install.sh

Then, in any Claude Code session:

/frame load sw-development

FRAME is domain-agnostic — the engine stays the same, the cartridge defines the kind of work. Available initially: sw-development, code-audit, blog-writing, linkedin-profile, project-planner, cartridge-creator. Each one is a validated workflow you can use as-is or modify. Build your own with cartridge-creator.

v0.3.0 added four more: codebase-analysis (structured documentation reports from an existing codebase), findings-to-tasks (turns audit findings into actionable tasks), skill-creation (designs and validates new Claude Code skills), and document-and-commit (documents and commits code changes made outside of FRAME).

Where it is

This is v0.3.0. Validated across real sessions — software development, code audit, blog writing, LinkedIn profile creation, cartridge authorship, project planning. All core design decisions are closed.

It's not done. I'm looking for people who like to run it on real work, file issues when it breaks, and tell me where the friction is. If that's you, the repo is at github.com/SeriousByDesign/frame. Just want to give it a go? You're welcome as well. Everyone is.

Break it. That's the point of v0.3.0.

DEV Community: Alex