Use when code is hard to follow and is to be audited or reworked: long if/else or switch chains, cascades of type checks or parse attempts, kind fields compared to strings, flag parameters, deep nesting, a function hard to read. Also for complexity guardrails, or one long conditional function pasted. Produces a ranked audit of families, one family reworked behind characterization tests, or the guardrails.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Branching is the symptom; the cause is usually late typing. Data enters typed by a schema and is handled as a bag, so every consumer rediscovers its shape by trying parsers and comparing strings. Look for that before splitting a function, and look for a domain rule before touching anything: ifs over values are the domain, and "reviewed, left alone" is a result.
One artefact each, and a stop. Read only the reference of the phase being run.
| Phase | Produces | Stops for | Read |
|---|---|---|---|
| 1 Audit | the report: families ranked, a shape each, what each must preserve | the person's choice of families and their order | references/audit.md, and references/measure.md for the numbers |
| 2 Characterize | one commit of tests pinning today's outputs, green on the old code | an output that looks wrong | references/characterize.md |
| 3 Rework | one family, commit by commit, the tests unchanged | any diff in a pinned output | references/rework.md |
| 4 Guard | a complexity limit, exhaustiveness, a check for the pattern, a convention proposed | the person's yes on the convention | references/guard.md |
references/target-shapes.md when a family is given its shape (phases 1 and 3). references/languages.md when a shape, an exhaustiveness check or a lint rule is named: the project's language and version decide its form.
| The ask | Phases |
|---|---|
| audit, where is it complex, what to clean up | 1, then stop |
| one function pasted | 1 on it alone, no measuring; name the other places likely to share its data |
| apply, rework family X, an approved audit | 2 then 3, one family at a time |
| guardrails, stop this coming back | 4 |
A phase whose input is missing runs first: no rework without its tests, no tests without the family's audit entry.
Two measures, three bands each, the line the audit measures against, the rework aims for and the guard enforces:
| Measure | Good | Review | Fail |
|---|---|---|---|
| Cyclomatic (independent paths) | 1 to 6 | 7 to 10 | 11+ |
| Cognitive (nesting-weighted) | 0 to 10 | 11 to 15 | 16+ |
A reworked function in a fail band is not done: split it further, or name the rule it encodes in an inline exception. A review band is read, not rewritten by default. The bands are a house convention (the thresholds in the literature are McCabe's and Sonar's choices, not findings).
Add no dependency without the person's yes: not an analyzer in CI, not a pattern-matching library, not a rule engine.
When the project plans its work in documents (a plan, a ticket per change), the audit is their input and each family is one piece of work that runs phases 2 and 3.
| Thought | Reality |
|---|---|
| "The shape is obvious, I'll declare the type" | The schema, enum or generated client already infers it. A second copy drifts. |
| "The change is mechanical, characterization is overhead" | The accidental fall-through and the null for corrupt input live in the mechanics, and are lost there silently. |
| "That pinned output is wrong anyway, I'll fix it on the way" | Reported in phase 2, fixed as its own change. Folded into the rework it is invisible in review. |
| "This switch needs a default, to be safe" | A default hides the next case from the compiler. Unknown input is handled once, at the parse. |
| "Complexity 40, it must be reworked" | A high count with no fingerprint is usually a business rule. Reviewed and left alone is a result. |
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Use whenever a document is produced for the user to read and react to while it evolves: a brainstorm board, a plan, a design language, a prototype, a PR analysis, a review report, a live PDF. Also when a document must be registered, opened, listed, moved or retired, or a prototype's bindings checked. Not for code, tests or configuration, or any file nobody opens in a browser.
日本語の概要は準備中です。原文の説明を表示しています。
Use when a person wants to think an idea through and keep the discussion: a feature, a tool choice, an architecture question, before a plan or without one, with the agent through an interview. Produces a board in aiview holding the decisions, the diagrams and what was investigated. Not for a swarm of seats working it (brainswarm), not for an implementation plan and not for bug fixes.
日本語の概要は準備中です。原文の説明を表示しています。
Use when a person wants a swarm of role seats to work a topic on the swarm board under a chosen protocol: a brainstorm (ideas before any judgment), a debate (questions argued to decisions, a skeptic endorsing) or an editorial (one text drafted, read by seats standing for its readers, revised), a protocol or template the project keeps as a `protocol-<name>` skill (or an older `brainswarm-<name>` one), or a custom protocol recommended for the person's intent, or a seat's brief names a brainswarm protocol. Produces the run's record in aiview, written by the orchestrator alone. Not for one person thinking aloud with the agent (brainstorm, interview) and not for a plan's slices (execute-plan).
日本語の概要は準備中です。原文の説明を表示しています。
Use when dispatched to cold-read a plan, as an agent that was not in the conversation that wrote it, to say whether it can be carried out from the document alone. Produces what the reader would build, its questions, and a verdict, ready or not ready, repeated as the writer fixes the plan. Not for judging the design (interview, pr-review), not for the mechanical checks (aiview plan check, tracker check), and not for writing the plan (write-plan).
日本語の概要は準備中です。原文の説明を表示しています。
Use when a page is wanted to work on something with the person during development, fed the project's real data (comparing model answers, walking an agent call by call, measuring an output against its template), when such a workbench has to change, be reworked or its feed broke, or mid-session when turns went into aligning with the person on how to do a kind of work that recurs and real project data could show it. Produces the page in aiview, kind `workbench`, and the project's `workbench-<bench>` skill with its feed and operating steps. Not for designing a product screen (design-prototype) or verifying user stories (verification-skill-create).
日本語の概要は準備中です。原文の説明を表示しています。
Use when a person asks to design a new module's interface or to rework an existing module so that it hides much behind little, in any tier (backend, frontend, test support, tooling), or says a module's callers know too much about it. Produces a module document in aiview, how a caller uses it, its one public entry point as signatures, what stays outside and the gap from today, discussed with the person until agreed. Not for writing the task that carries the rework out (orchestrate's tasks) and not for the rework itself.
日本語の概要は準備中です。原文の説明を表示しています。