flow-kit is eight prompts and a folder copy, with no runtime to maintain

No runtime, no dependency, no version to track

The central decision is that this is not a tool.

The reasoning is stated plainly: once a tool is installed, it brings version problems, dependency conflicts, and eventually an unexpected breaking change. This package inverts that. It is a set of files that you copy into a project, and there is nothing to run.

The consequences are stated as a list. No package manager install of any kind, no interpreter install, no command-line tool. It works in seven named editors and assistants, provided only that the editor supports mentioning a file by path. And because every rule lives in a file rather than in code, changing behaviour means editing a document.

The trade is acknowledged in one line: there is more manual work, and in exchange nothing can break when a tool updates underneath you.

The content itself is described as borrowed and rearranged. Useful pieces from several agent frameworks were selected and re-sequenced to fit one workflow, and every name and command-line dependency was removed, leaving only prose instructions. Installing once means there is no upstream version to track afterwards.

Installation is copying a folder into the project root

There is no installer, and the layout diagram is the whole procedure.

The folder goes at the top level of a new project, alongside the source directory. Inside it sit the methodology document, the rules document, a prompts directory and a templates directory.

What happens next depends on the editor, and the documentation gives one route per tool rather than a single universal one. Two editors get a command that copies the prompt files into their own configuration directory so the stages appear as slash commands. One editor gets a command that wraps each prompt as a skill. Another gets a single instruction to copy the rules file to its conventional rules filename, after which the prompts are mentioned by path.

Everything else, including several assistants not named individually, uses the generic route.

The generic route is a message asking the agent to read three files as a baseline before anything else happens: the methodology, the rules, and the first prompt. After that, each stage adds one more mentioned file as the process advances. So the marginal cost of a stage is one mention, and the cost of getting started is three.

One editor turns the prompts into skills with a directory copy:

mkdir -p .claude/skills/flow-change
cp flow-kit/prompts/0-change.md .claude/skills/flow-change/SKILL.md
# other stages likewise

The entry file routes stages and invents the change id

The friction reduction is the part of the design that is genuinely different, and it is one file.

Instead of naming a stage, you mention the entry file and then say what you want in ordinary language: start something new, continue, execute a particular task, review, test, or integrate. The file decides which stage that means.

It also generates the change identifier, so nobody has to invent a name for the work before it starts. It loads whatever artefacts that stage needs. And it is described as asking clarifying questions on its own rather than waiting to be asked.

The argument underneath is that mentioning a file by path is the lowest common denominator across every one of these tools, so a single file is the one thing guaranteed to work everywhere.

Two additions sit on top. Editors that support slash commands can take a copy of the same file as a command, which removes the mention entirely. And a condensed rules document can be injected permanently into an editor's global configuration, which leaves the agent following the rules even when only routing is being asked for.

The documentation's own recommendation is to configure both.

Three invocation styles, and a recommended combination

The three styles are compared on two axes: one-time setup cost and per-session friction, with a note on who each suits.

Slash commands cost one copy command and then no mentions at all. They suit the editor whose workflow directory you can write to.

Global injection costs one copy of the condensed rules document and leaves one mention per session. It is described as the most universal option because every editor has some form of resident rules file.

Copy and paste costs no setup and leaves between one and three mentions per session. It suits someone who moves between several assistants and does not want to configure any of them.

The condensed document deserves a note, because it is not the same as the rules document. It is a shortened merge of the methodology and the rules, written specifically to be pasted into a global configuration where length would be a liability. The full version stays available for explicit mention when you need the detail.

The recommendation is the combination: slash commands for zero friction where they work, global injection underneath, so that when a slash command is unavailable the fallback still costs only one mention.

Eight stages produce artefacts in a per-change directory

The full path for a new project is a fixed sequence of eight stages, and each one writes a single document.

The first stage turns a vague idea into a change proposal by asking questions back at you, and it is where the identifier gets generated. The second turns that proposal into executable requirements with acceptance criteria and a domain vocabulary. The third turns requirements into a technical design with decision records and risks. There is an extra stage between the second and third for user interface work, covering aesthetic direction, design tokens and a self-check against generic machine-made interface output.

The fourth breaks the design into atomic tasks that can run in parallel, each with a verification field. The fifth executes one task in a fresh context, with tests, a commit and a way to resume if interrupted. The sixth derives a test matrix from the acceptance criteria. The seventh reviews in two or three rounds. The eighth walks acceptance testing, diagnoses failures, and archives.

Every artefact lands in a directory named for the change, so two changes in the same repository never share state.

That directory layout is what makes the second half of the process readable months later, since each document states what was decided before the code was written.

The fast path compresses two stages, it does not delete them

For an existing repository, the documentation is explicit that the minimum path is not to skip artefacts.

What changes is that the requirement and design stages may be very short. If those documents are missing, a lightweight version is written first, and then the sequence continues from task breakdown onward.

The task stage is the hard requirement. It needs the requirement and the design in order to fix what acceptance means, which technology stack applies, and which files may be written, and that last one is the boundary that stops an agent editing outside its assignment.

There is also a same-day mode, described as running the whole thing on four steps with four artefacts: a requirement that includes the context document, a shortened design, the task breakdown, and development with self-verification. The design in this mode may be short provided it still names the stack and the boundaries.

The instruction is to upgrade to the full sequence once the short version runs cleanly, which is a sensible order because the expensive failures in this kind of process come from a missing boundary rather than a missing heading.

Two of the nine prompts are marked as not standalone

Every file carries a column recording whether it works on its own, and the criterion is stated rather than assumed.

The test is: set the whole process aside, hand the single file to an agent or use it as a template, and see whether it still produces something useful.

Seven of the nine stage files are marked as fully standalone, and the scenarios given are concrete: the first for anyone who knows they want to build something and cannot articulate it, the requirement stage for turning a spoken request into a document, the design stage for architecture review, the test stage for adding coverage to existing code, and the review stage for auditing a diff before a merge.

Two are marked as partly standalone, and the reason in each case is a dependency on a document that an earlier stage writes.

The development stage is the strict one. It depends on the verification field inside the task document, and the documentation goes further than saying it needs that file: a single call is permitted only if a person supplies a temporary minimal task document by hand, with seven named fields, and the agent is explicitly not permitted to invent one to get around the task stage. That is the single hardest rule in the package, and it is aimed at the failure the author describes observing: an agent skipping steps to reach the part it finds interesting.

Editorial conclusion

This fits someone who wants a written process for AI-assisted work without taking on a dependency, since nothing is installed and nothing can break under you when an upstream tool ships a change. It does not fit a team that wants enforced gates in a build, because nothing here runs without a person or an agent deciding to read the file. Two things to know before adopting it. The two later prompts are documented as only partly standalone, so the task stage in particular needs its input to exist. And the author records having watched an agent skip stages during a run, which means the process depends on the agent following instructions rather than on anything stopping it.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. rihebty/flow-kit on GitHub