Don't let the same persona handle design, implementation, and review.

If this sounds familiar

SYMPTOMS

• I asked for authentication, but it also included standardizing error handling.
• The diff involves 40 files, and I lack the motivation to read them all, so I approve them superficially.
• Three days later, I can't even explain why this implementation was chosen.
• I want to run tasks in parallel, but fear of conflicts forces me to run them one by one.
• The screens generated always look like something I've seen before.

This is not a capability issue. It happens because you are assigning design, implementation, review, and merging to a single persona. If this were a human team, no one would allow the same person to decide on the design, implement it, review it, and merge it.

The solution is reducing permissions

PERMISSIONS

All five personas use the same model. There is no difference in intelligence. The only difference iswhat they are allowed to do.

AI chooses the most plausible next step within the given context. If you say "Create a login feature," it is plausible to do everything related to it. If you say "Change only inside src/auth/** and satisfy these three acceptance criteria," the most plausible next step becomes something entirely different.

Workflow

FLOW

Request → [Architect] Split into Issues (create non-overlapping scopes)
         │
         ├─ [Coder] issue/12-xxx ─┐
         ├─ [Coder] issue/13-yyy ─┤  Parallel
         └─ [Coder] issue/14-zzz ─┘
                                   │ One PR at a time
                                   ▼
                            [Reviewer] Check acceptance criteria and scope → Merge
                                   │
                                   └─ Conflict → [Conflict Resolver] → Reviewer

Parallel implementation, sequential merging. Merging three things simultaneously means that even if each is correct individually, you cannot isolate the cause if the combination breaks. You end up re-examining all three, which is slower than doing it sequentially.

What this setup built

EVIDENCE

A record you can check beats a description. These four personas built one small CLI, and the whole process is public.

mdlinkcheck — a CLI that finds broken relative links in Markdown. 139 tests, two CI workflows passing.

• Issues — each one carries scope, dependencies and acceptance criteria, written before any code
• Pull requests — each maps to exactly one Issue and stays inside its declared scope
• The parallel run — three Issues implemented concurrently in separate worktrees, merged one at a time

The history is not cleaned up. What went wrong is still in it. Two Issues declared a scope that did not exist; a Coder stopped and reported a missing dependency instead of editing a file outside its scope; and the tool itself caught 17 broken links in its own README. A history with no rejections only proves that review was not doing anything.

Then four more, built the same way

One tool is indistinguishable from luck. Four more CLIs, same persona configuration, different jobs, all MIT and all with no dependencies.

Tool	What it looks at	Tests
ccheck	.claude/ configuration — the parts that are written correctly and do nothing, each finding citing the documentation	74
scopecheck	Which of your open Issues cannot run at the same time	all passing
sharedfiles	Where parallel work will collide, from git history alone. No declarations, no configuration	all passing
transdrift	Whether a translation has fallen behind its source. Not yet published	43

ccheck implements only what the documentation states outright — as an error, as skipped, or as ignored. A checker that calls a valid configuration broken is worse than no checker. What it deliberately does not check is published too.

The tables the findings rest on are readable on their own — everything that is configured correctly and does nothing (33 hook events, 71 of 223 settings keys, five permission-rule forms).

mdlinkcheck history Reference

Two configurations

PACKAGES

The contents are identical across tiers. What differs is how many people may use it and whether you may share it internally. You can move up a tier by paying the difference. The terms ship in LICENSE.txt.

View Quartet on GitHub Purchase Quintet

All three tiers are on the same page — pick one at checkout. The contents are identical; what differs is the licence that ships with it. The kit includes the guide and the README in both English and Japanese.

If you need an invoice rather than a card receipt, Gumroad issues a receipt, not an invoice, so that has to be arranged before you buy — open a licence inquiry and say which tier and how many seats. Purchase orders and Japanese qualified invoices (適格請求書) go the same way. There is also a Japanese storefront if you would rather pay in yen.

Why your UI always looks the same

WHY YOUR SCREENS LOOK GENERATED

Hero section centered on the full screen. Three-column monospace cards with icons. Purple gradient. Pure black text on a pure white background. You recognize it instantly, and once recognized, you lose trust in it.

The cause is letting the Coder decide on the design. If asked to make decisions without specifying colors, fonts, or spacing, the output will be the most frequent form in the training data. This is not an issue of AI's aesthetic sense; it is a lack of input.

In Quintet, the UI Designer writes the specification before implementation. Structure → Tokens → States → Motion → Copy are determined in order, and the Coder implements based solely on the specification. If design elements not written in the spec are required, implementation stops and is sent back.

When not to use this

WHEN NOT TO USE THIS

This adds overhead. The number of steps per task definitely increases.

• Exploration / Prototyping (stage where acceptance criteria cannot be written)
• Changes that can be completed in one file (no point in creating a PR for a typo fix)
• Work with inherently linear dependencies (splitting does not enable parallelism)
• Tasks that take 30 minutes

There are also limits. Since the Reviewer uses the same model as the Coder, it cannot detect errors inherent in the model's systematic knowledge. If a library's API is consistently misremembered, the Coder will make a mistake, and the Reviewer will judge it as correct. The countermeasure is to include executable verification in the acceptance criteria.