Merge Readiness

<Use_When>

• A task, PR, or change set is functionally complete and needs a final human-understanding check before merge readiness
• Tests, QA, code review, security review, or other verification has already run, or missing evidence must be explicitly recorded
• The user wants AI to explain the change and then quiz the human on whether they can explain it
• You need a durable session audit record showing why the team can trust and understand the change before asking for merge approval </Use_When>

<Do_Not_Use_When>

• Requirements are still unclear before implementation; use /deep-interview
• The implementation is not done; use /ralph, /team, or /autopilot
• Tests or QA have not run and the user expects this command to replace them
• The user wants code review findings; use /review or the relevant review workflow </Do_Not_Use_When>

<Why_This_Exists> Real delivery is not only code that works. Teams need to understand why a change exists, what changed, what was deliberately not done, which risks were considered, and what future maintainers should believe about the change. This workflow makes that understanding explicit before merge approval is requested. Passing this gate never means the change is approved or merged; it only means a human can explain it. </Why_This_Exists>

<Depth_Profiles>

• Quick (--quick): small/local changes; correctness threshold >= 0.70; max 3 MCQs; required dimensions: why / change / risk
• Standard (--standard, default): normal feature/bugfix; correctness threshold >= 0.80; max 5 MCQs; required dimensions: why / change / tradeoff / risk / team
• Deep (--deep): high-risk, architectural, security, or cross-module changes; correctness threshold >= 0.90; max 8 MCQs (redundancy across all five dimensions)

If no flag is provided, use Standard. Thresholds and round counts are canonical in src/hooks/merge-readiness/mcq.ts and must stay in sync with this file. </Depth_Profiles>

<Execution_Policy>

• This is a post-task command. Do not implement code inside this mode.
• Gather repository and artifact evidence before asking the human for facts that can be discovered locally.
• Generate the explanation doc + MCQs in one AI step, then present MCQs one-per-round.
• The runtime (TS hook code) is the backbone: it owns validation, authoritative session state, objective MCQ scoring, and report rendering. The AI owns content generation + MCQ presentation via AskUserQuestion.
• Present each MCQ one-per-round via AskUserQuestion (deep-interview style). Record each selection via the runtime so it is scored objectively.
• Ask about explainability, not implementation trivia.
• Never ask the human to memorize line numbers, variable names, private helper names, or incidental implementation details.
• Score is the objective correctness rate (correct answers / answered), not a keyword heuristic.
• If the correctness rate is below threshold after all required MCQs are answered, mark result paused and do not claim merge readiness.