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.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
The goal is to hide accidental complexity: the codebase knows the module's entry and nothing behind it, as if it were a package that has not been published.
A building block is not a deep module: a module other modules are built from, one job, several callers, no module document of its own. It still has an entry, held to the same rule as a deep module's (The entry, below).
One module document per module, written from the first finding, never in chat. Through the aiview skill: kind module, file YYYY-MM-DD-<module>.module.md, tags = module name, in the plan's group when a plan waits on it. Each stage below writes its sections into it.
For an existing module, discover its actual boundaries before designing. Its code may be scattered across the codebase. Document its files, its callers and its application dependencies in Today. A new module starts at Design.
Sections in this order, each marked provisional where an open decision could change it.
write-diagrams skill.Resolve the open decisions with the interview skill, writing each answer into the section it changes. Challenge every export: what no caller clearly needs stays inside.
The document is agreed when the list is empty and the person says so. The date goes in its header, and the entry is frozen: a later change to it is a new decision.
The rework is a task, and it quotes the agreed entry word for word.
| Thought | Reality |
|---|---|
| "I'll add an option for that" | An option nobody passes is surface. |
| "One entry, an option picks the mode" | Neither the import nor the call says which rules apply. One entry per case. |
| "Callers may need this helper" | Name the caller. One that exists only in the tests is served by the entry. |
| "It's only a 3, it reads fine inline" | The same 3 in a second file drifts from the first. Name it in the constants file. |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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 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.
中文简介正在准备中。当前显示原文说明。
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).
中文简介正在准备中。当前显示原文说明。