Clarify Question Loop
Ask only questions that change the generated package, runtime adapter, safety
boundary, or public/private release decision.
For /hep-build creation or behavior-changing packaging, this is not a
substitute for the Builder Interview and Research Gate in
contracts/builder-interview-research-gate.md. Run that gate first: ask an 8-12
question first batch, research similar agent repositories or comparables and
academic/professional theory, then use this clarify loop only for the remaining
narrow ambiguities.
Procedure
- Classify the current best mode.
- If single-agent vs team selection would change the package shape and the
independent ownership boundaries are unclear, ask before generation. The
first batch must include this plain-language question: "이 일을 한 명의
전문가가 처음부터 끝까지 맡으면 되나요, 아니면 조사/분석/검토처럼 여러
전문가가 나눠 맡고 마지막에 합쳐야 하나요?"
- Follow up on role count, role-specific tools/permissions, whether outputs
must be synthesized, and whether artifacts are sequential dependencies or
independent parallel packets.
- Identify missing facts that would change files or safety.
- Ask one to five short questions, preferably three. If more than five
functional-quality questions remain, return to the Builder Interview and
Research Gate instead of pretending the package is ready.
- Do not ask for secrets. Ask for secret names or setup boundaries instead.
- After answers arrive, re-run mode classification if needed.
- Generate or repair the package using the answers and list assumptions.
Budgets and stop rule (briefing interview engine)
This loop shares the briefing interview engine's contract
(agentlas_cloud/interview/): a question is only worth asking if the answer
would change execution, not just its phrasing. Respect the surface budget
(chat 3-5 in one batch, stormbreaker <= 8 across two batches, build 8-12 plus
follow-ups). 'decide later' is always a valid answer — record it as deferred,
never re-ask. When answers you auto-confirmed from code/memory reach three in a
row, the next question must go to the human.
Default Questions
- Which runtime targets should be supported?
- Is this local-only, private-team, public open-source, or marketplace output?
- What tools, APIs, files, or services must it use?
- What should count as success?
- What must it never read, write, publish, or spend?
- 이 일을 한 명의 전문가가 처음부터 끝까지 맡으면 되나요, 아니면
조사/분석/검토처럼 여러 전문가가 나눠 맡고 마지막에 합쳐야 하나요?
Plain-Language Question Rule
Never ask non-technical users to choose internal labels such as
single-agent, team-builder, ownership boundary, memory/context, synthesis,
or produces/consumes. Translate them before asking:
- ownership boundary -> "누가 따로 맡아야 하는 일인지";
- memory/context -> "각자 따로 기억해야 할 자료, 기준, 진행 상황";
- tools/permissions -> "각자 써도 되는 계정, 파일, 웹사이트, 도구";
- synthesis -> "마지막에 결과를 한데 모으는 일";
- sequential dependency -> "앞 사람이 끝낸 결과를 다음 사람이 이어받는 순서".
If a question still sounds technical, split it into two shorter everyday
questions and give examples such as 조사, 분석, 검토, 승인.
Reference
See docs/clarify-question-loop.md.
1---2name: clarify-question-loop3description: Use when a meta-agent request is too ambiguous to safely generate, package, publish, or adapt without one to five targeted questions.4---5
6# Clarify Question Loop
7
8Ask only questions that change the generated package, runtime adapter, safety
9boundary, or public/private release decision.
10
11For `/hep-build` creation or behavior-changing packaging, this is not a
12substitute for the Builder Interview and Research Gate in
13`contracts/builder-interview-research-gate.md`. Run that gate first: ask an 8-12
14question first batch, research similar agent repositories or comparables and
15academic/professional theory, then use this clarify loop only for the remaining
16narrow ambiguities.
17
18## Procedure
19
201. Classify the current best mode.
212. If single-agent vs team selection would change the package shape and the
22 independent ownership boundaries are unclear, ask before generation. The
23 first batch must include this plain-language question: "이 일을 한 명의
24 전문가가 처음부터 끝까지 맡으면 되나요, 아니면 조사/분석/검토처럼 여러
25 전문가가 나눠 맡고 마지막에 합쳐야 하나요?"
263. Follow up on role count, role-specific tools/permissions, whether outputs
27 must be synthesized, and whether artifacts are sequential dependencies or
28 independent parallel packets.
294. Identify missing facts that would change files or safety.
305. Ask one to five short questions, preferably three. If more than five
31 functional-quality questions remain, return to the Builder Interview and
32 Research Gate instead of pretending the package is ready.
336. Do not ask for secrets. Ask for secret names or setup boundaries instead.
347. After answers arrive, re-run mode classification if needed.
358. Generate or repair the package using the answers and list assumptions.
36
37## Budgets and stop rule (briefing interview engine)
38
39This loop shares the briefing interview engine's contract
40(`agentlas_cloud/interview/`): a question is only worth asking if the answer
41would change execution, not just its phrasing. Respect the surface budget
42(chat 3-5 in one batch, stormbreaker <= 8 across two batches, build 8-12 plus
43follow-ups). 'decide later' is always a valid answer — record it as deferred,
44never re-ask. When answers you auto-confirmed from code/memory reach three in a
45row, the next question must go to the human.
46
47## Default Questions
48
49- Which runtime targets should be supported?
50- Is this local-only, private-team, public open-source, or marketplace output?
51- What tools, APIs, files, or services must it use?
52- What should count as success?
53- What must it never read, write, publish, or spend?
54- 이 일을 한 명의 전문가가 처음부터 끝까지 맡으면 되나요, 아니면
55 조사/분석/검토처럼 여러 전문가가 나눠 맡고 마지막에 합쳐야 하나요?
56
57## Plain-Language Question Rule
58
59Never ask non-technical users to choose internal labels such as
60`single-agent`, `team-builder`, ownership boundary, memory/context, synthesis,
61or produces/consumes. Translate them before asking:
62
63- ownership boundary -> "누가 따로 맡아야 하는 일인지";
64- memory/context -> "각자 따로 기억해야 할 자료, 기준, 진행 상황";
65- tools/permissions -> "각자 써도 되는 계정, 파일, 웹사이트, 도구";
66- synthesis -> "마지막에 결과를 한데 모으는 일";
67- sequential dependency -> "앞 사람이 끝낸 결과를 다음 사람이 이어받는 순서".
68
69If a question still sounds technical, split it into two shorter everyday
70questions and give examples such as 조사, 분석, 검토, 승인.
71
72## Reference
73
74See `docs/clarify-question-loop.md`.