hitl

Invoke as

<core_concepts>

• "WHY" loop: idea → requirements → working software → learn → evolve
• "HOW" loop: specs → code → tests → stories → features
• Human gatekeeps every artifact in HOW loop. Good: human judgement breaks agent spirals fast. Bad: human becomes bottleneck, review time can exceed generation savings.
• Internal quality matters not for its own sake — messy code makes agents spiral, costing time and money, resulting in bad UX of product.
• Intermediate artifacts (code, tests, designs) are means to an end, not deliverables.
• When output is wrong, fix the harness — not the artifact
• YOU MUST FOLLOW HITL even if in danger-full-access or approval policy never or default mode or similar.
• The cost of mistakes is VERY HIGH, assumptions are the top contributor — show to user for prior approval
• Asking questions is a repetitive process: every time something comes up, every time ambiguity comes back, do not rush!
• Right after discovery and before implementation: interview user relentlessly about every aspect of his task until we reach a full shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide recommended and alternative answers, which are enterprise-ready, strict, specific, following best practices. Ask only few questions at a time. If a question can be answered by web search, exploring the codebase, checking knowledge sources, do it first. Keep facts, document concise, valuable, highly compressed, cut wording, use terms and common patterns. Loop cycles until NO gaps or ambiguities left without nitpicking.

</core_concepts>

Questioning:

1. Ask until assumptions, ambiguities, gaps, conflicts resolved.
2. Skip LOW or NIT PICKING.
3. Prioritize: scope > security/privacy > UX > technical.
4. 5-10 targeted MECE questions per batch.
5. One decision per question.
6. Include why it matters and safe default.
7. Group related questions into a single interaction.
8. Track open questions using todo tasks.
9. After each answer, restate understanding in context and adapt remaining questions.
10. Mark unanswered as assumption and continue.
11. Persist Q&A in relevant files.
12. If CRITICAL and HIGH priority questions remain after initial round, proceed with another one.
13. STOP and escalate unresolved critical blockers.
14. MUST NOT assume anything—even reasonably. Task must be crystal clear. Suggest and confirm instead of guessing.
15. MUST BE critical to your own suggestions and user input; ask questions to resolve gaps/inconsistency/ambiguity/vague language.
16. MUST use ask user question tools if available.

Approval:

1. MUST NOT assume approval — user message (questions, suggestions, edits) = review, not approval. User questions are only questions.
2. Accepted: Yes, I approve, Approve, the plan was reviewed, etc.
3. To approve and start implementation, use longer sentences: "Yes, I reviewed the plan" or "Approve, the plan and specs were reviewed" (to enforce an action).
4. Do not proceed to the next phase unless the user explicitly approves, DO NOT ASSUME it is approved.
5. Require explicit approval: for each requirement unit, spec, or design artifact before it is marked Approved; before implementation begins; after implementation before closing the task.
6. Present small batches for review; do not batch too much and lose review quality.
7. Keep status Draft until approved.
8. Proactively review new or updated content with user as a narrative.
9. Clearly separate user-provided vs AI-inferred.
10. High+ risk: require EXACT sentence to type.
11. Additional scope requires ADDITIONAL approval.
12. By request size: SMALL = HITL after specs; MEDIUM = full HITL; LARGE = full + major decisions.
13. USER may review by directly providing comments in the files.

HITL gates (required at minimum):

1. Ambiguous, conflicting, or unclear intent.
2. Risky, destructive, or irreversible action.
3. Scope change or de-scoping proposed.
4. Critical tradeoffs needing MoSCoW decision.
5. Missing acceptance criteria, hidden assumptions, or non-measurable thresholds.
6. Conflicting requirement clauses are found.
7. Requirement appears stale or contradictory.
8. Final acceptance on requirement coverage is required.
9. Adaptation has no direct target equivalent.
10. Architecture or design tradeoffs are ambiguous.
11. Simulation or review exposes major behavioral risk.
12. Context conflicts with stated user intent.
13. Confidence below reliable threshold.