Frenchie Method Principles
Agents can move fast. Frenchie Method keeps the work traceable, testable, reviewable, and ready for release.
Move fast with agents. Keep the trail.
core belief
Frenchie Method treats AI agents as capable teammates, not autonomous owners. The agent can ask questions, write artifacts, implement code, run tests, and prepare reviews. The human still verifies decisions, approves risk, and owns what ships.
what it is
It turns a rough request into requirements, acceptance criteria, test cases, implementation plans, reviews, and release checks. The important part is not the ceremony. It is that another human or agent can pick up the trail later.
what it believes
The principles are simple: write down what matters, test before planning, design before UI implementation, isolate agent work in worktrees, review the result first, and keep release decisions explicit.
why worktrees
Worktrees keep parallel tasks isolated, make setup visible, and make cleanup a human-approved step. That is what lets speed feel controlled instead of chaotic.
workflow
The principles are easier to follow one decision at a time. Each step keeps agent speed tied to an artifact, a test, a review, or a human approval point.
Turn the rough ask into a requirement artifact first.
Most AI-agent rework starts before code exists. Frenchie Method turns the rough request into a requirement artifact the agent can follow and the human can correct.
Move important context out of chat and into files.
Chat is a weak source of truth. Frenchie Method writes important work to .frenchie/docs/feature/[feature-name]/ so another agent, session, or teammate can continue from the same trail.
Decide how the work will be proven before planning it.
Acceptance criteria describe what must be true; test cases describe how the team proves it. The two are not interchangeable, and Frenchie Method designs test cases before planning the implementation.
Shape UI behavior, states, and accessibility before code.
For user-facing work, Frenchie Method captures screen structure, interaction states, accessibility requirements, and wireframe-level decisions before code changes. Design before implementing for UI-heavy work, unless the user explicitly approves skipping the design artifact.
Isolate fast agent work from the main checkout.
AI agents move quickly. Worktrees isolate parallel tasks, preserve the main checkout, and make cleanup explicit. Frenchie expects dependency bootstrap, warns about ignored and generated local state, and performs no silent cleanup.
Inspect from the user's point of view, then compare the diff against the artifacts.
Review happens in two stages. /walkthrough inspects the result from the user's point of view — acceptance criteria, states, copy, data behavior, and error paths. /pr-review then compares the diff against the artifacts to surface drift, regressions, and missing tests. The two are distinct on purpose: a walkthrough catches what the user would notice; a diff-vs-artifacts review catches what reviewers and future maintainers would.
Review risky surfaces before release, not after implementation.
When auth, data handling, payments, secrets, file parsing, dependencies, or production behavior are affected, security review belongs before release.
Report readiness, risk, missing evidence, and rollback notes.
/release-check reports what is ready, risky, missing, and worth double-checking. /release is separate and only runs when the user explicitly asks and approves.
Hotfixes can compress the flow, but not skip proof.
Hotfixes can use a compressed path, but they still need reproduction, impact, fix evidence, tests, release-check, and a postmortem when users were affected.
Use reports and retrospectives to tune the method.
The artifact trail helps teams see where work gets stuck, where agents help, which checks catch real problems, and which prompts or templates need improvement.
The workflow should guide, warn, and continue when humans choose.
The orchestrator can be strict, but direct skill mode should help with the task at hand, warn when artifacts are missing, recommend the safer next step, and continue when the user chooses.
release boundary
/release is not part of the automatic flow. It remains explicit and user-approved.
artifact folder preview
Feature artifacts live under .frenchie/docs/feature/[feature-name]/. Teams decide what to commit and what to ignore.
.frenchie/docs/feature/[feature-name]/
$ ls .frenchie/docs/feature/google-drive-link-parsing state.json 00-source-context.md 01-requirement.md 02-acceptance-criteria.md 03-test-case.md 04-implementation-plan.md 05-design.md 06-test-report.md 07-walkthrough.md 08-review-report.md 09-release-checklist.md $ tree -L 1 .frenchie/docs/feature/google-drive-link-parsing .frenchie/docs/feature/google-drive-link-parsing/ ├── state.json ├── 00-source-context.md ├── 01-requirement.md ├── 02-acceptance-criteria.md ├── 03-test-case.md ├── 04-implementation-plan.md ├── 05-design.md ├── 06-test-report.md ├── 07-walkthrough.md ├── 08-review-report.md └── 09-release-checklist.md
quality model
Teams can tune the scoring model. Frenchie Method provides the structure; the human team decides the bar.
It solves the requirement and handles edge cases.
The code is readable, scoped, and consistent with the project.
The change has automated or manual evidence tied to test cases.
Risky surfaces are reviewed, especially auth, data, files, dependencies, and production behavior.
A human can understand the change without reconstructing the whole chat.
method plus kit
Frenchie Method does not require an API key for text workflows. Frenchie Kit is suggested when real file context is needed.
faq
Frenchie Method is a structured workflow for AI-assisted product development. It helps agents and humans move from requirement to release through shared artifacts, test cases, implementation plans, reviews, and release checks.
It is for solo builders, founders, small product teams, engineering leads, and anyone who wants AI-agent work to be traceable, testable, and reviewable.
No. It helps solo builders because the artifact trail keeps work recoverable across sessions, context resets, branches, and handoffs.
No. Frenchie Method gives your agent a workflow to follow. You keep using your preferred agent, repository, issue tracker, and review process.
No. Text-only Method workflows are free and do not require an API key. Frenchie Kit credits are used when hosted file parsing or generation capabilities are needed.
Artifacts keep important context out of fragile chat history. They make requirements, test cases, plans, reviews, and release checks reusable by humans and agents.
Worktrees let AI agents work in isolated checkouts so parallel tasks do not contaminate the main repo or each other.
The plan should be shaped by evidence. Test cases define how the team proves the work, so the implementation plan can build around that proof.
/release-check reports readiness and risk. /release is a separate explicit command that may merge or release only when the user asks and approves.
Yes, but only with enough evidence to protect users: reproduction, impact, fix, tests, release-check, and a postmortem when production was affected.
Frenchie Method calls out artifact drift. The human can update the artifacts, change the implementation back, or treat it as a scope change and rerun affected steps.
The workflow considers security throughout and triggers review when risky areas such as auth, data, secrets, files, dependencies, or production behavior are affected.
Yes. Direct skill mode should help with the current task, warn when Method artifacts are missing, recommend the safer next step, and continue if the user chooses.
