Use when a person says "interview me" or asks to be interviewed about an idea or an existing design document (a board, a plan, a change) until it is understood the same way by them and the agent, or when another skill needs open decisions resolved one by one. Runs in chat and leaves the resolved decisions there, for the caller to write where they belong. Keeping the discussion as a document is brainstorm's, turning it into a plan is write-plan's.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
실행 점수 미검증
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
The interview ends at shared understanding: the person and the agent would describe the object the same way, and every decision is agreed or deferred. Until then, keep going.
The object is a tree of decisions. Each is answered by what can be read or by the person.
Throw ideas in as you go. An option the person did not list, a consequence they did not name, a neighbouring decision the conversation points at: one line, marked as yours, beside the question it belongs to. The interview draws the person out; it also gives them something to push against.
Research every decision that rests on a claim about the world: a tool exists, it works with our versions, the industry does it this way. Read the official source, the specification, the package as published, its types and its changelog, and how reputable projects solve the same problem, from their sources. State the version read and the date. A search result or a blog is where reading starts, never where it stops.
One option, experiments: yes | no. Ask it first, with your recommendation, when the
subject makes it plausible, and later the moment reading cannot settle a claim or the
person doubts a tool. On a yes, read references/experiments.md. The caller stores the
answer with its decisions.
Before each question, read: the code, the history, the existing documents. A question about a screen goes through the point-at skill first.
One decision per message, in tree order, a branch once its parent is agreed. What reading settles is stated with its source, and the person confirms. Where a document says one thing and the code another, the person chooses which holds. What reading leaves open is asked: the decision with what it depends on, the question in one sentence, the recommended option first and marked, each option with the trade-off that decides it, and a closing line that takes a number or a rejection of the frame. A decision left unasked is one the implementation makes silently.
The short mode, offered whenever the full interview would be skipped: three questions
at most, on the decisions that change an output (kind contract) only, each with the
recommendation first. Every decision it leaves unasked is closed as the agent's default,
and named so.
Close in chat, once understanding is shared: every decision with its status and source. The caller decides where
that goes. The caller writes decisions as rows: read references/decisions.md.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
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).
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.