clarify

What problem does it solve? Ambiguous user requests often lead to either premature planning with wrong assumptions or excessive clarification questions that interrupt the user. This protocol structures how an architect agent inventories, classifies, and resolves uncertainties before asking the user anything. ## Core Features & Use Cases - Four-Stage Clarification Funnel: Inventories all material uncertainties, classifies each as self_resolved, critic_resolved, research_needed, user_decision, or deferred_nonblocking, then filters them through a critic sounding board before surfacing anything. - Critic Verdict Mapping: Maps SoundingBoardVerdict outcomes (UNNECESSARY, RESOLVE, REPHRASE, APPROVED) to concrete funnel actions, with hard constraints preventing the critic from dropping always-surface categories like destructive behavior, security risk, or breaking changes. - Structured Decision Packets: Presents remaining user decisions grouped by category with rationale, recommended defaults, options, and blocking markers, and records every resolved item as an explicit assumption. - Use Case: When a user asks an architect agent to plan a feature with unclear scope or migration impact, the agent runs this funnel to resolve what it can internally and only escalates genuine user decisions. ## Quick Start Ask the architect agent to plan an ambiguous feature request and it will load this protocol to run the clarification funnel before presenting any decision packet.