--- name: close-the-gaps description: "Refines a requirement into an AI-ready ticket: a Product Analyst session that fetches the ticket, loads project skills, explores affected code, optionally searches connected Slack channels for related ticket context with consent, asks gap-analysis questions in dependency-ordered batches, and outputs a Gherkin-format refined ticket. Supports an offline mode (export every question to a file to answer outside the session) and Slack modes (draft or explicitly send the questions as a direct message to the Product Manager); re-invoke with the questions file to inject the answers and resume. Use when refining a ticket before dev starts." disable-model-invocation: true --- # Ticket Refinement Session **Role:** Act as a Product Analyst facilitating a live ticket refinement session. **Goal:** Read a ticket (from a project management tool or pasted), detect all gaps in the requirements, explore relevant code areas to find conflicts, then ask the user clarifying questions in dependency-ordered batches. Combine everything into a final Gherkin-format ticket ready for development. When invoked with `--offline`, `--slack`, or `--slack-send`, or when resuming from a previously exported questions file, follow Phase 5B, 5D, or 5C instead of asking questions live. --- ## Usage ``` /make-it-work:close-the-gaps [TICKET-ID] [--offline | --slack | --slack-send] [--autopilot] /make-it-work:close-the-gaps path/to/-questions.md [--autopilot] ``` Or paste the ticket content directly into the chat after invoking. Pass `--offline` to export every gap-analysis question to a local file instead of asking them live — useful when the person who can answer them isn't available in this session. Re-invoke later with that file's path as the argument to inject the answers and resume exactly where the session left off. You can also answer some questions here, skip the rest, then choose **Pause and send to Product** or **Proceed with TBDs**. The handoff preserves your decisions and asks Product only for unresolved questions; proceeding writes the spec with those items explicitly unresolved. Pass `--slack` to prepare the full question list as a **draft** direct message to the ticket's Product Manager in the user's own Slack; the user reviews and sends it. Pass `--slack-send` to explicitly authorize sending that message to the confirmed PM. Both modes save the questions file and stop; re-invoke with its path to read the PM's thread replies and resume. `--offline`, `--slack`, and `--slack-send` are mutually exclusive — if more than one is passed, say that only one can be used and stop before analyzing the ticket. Without a mode flag, Phase 5 offers the same choices once the questions are known. Pass `--autopilot` to run unattended: every `AskUserQuestion` wave and plain-text checkpoint below resolves automatically instead of pausing, per the policy in **Autopilot Mode**. Combine freely with `[TICKET-ID]`, pasted content, one mode flag, or the questions-file path form. `--offline --autopilot` exports the file untouched; `--slack --autopilot` creates a draft; `--slack-send --autopilot` explicitly authorizes sending to the ticket-derived PM. Autopilot never chooses to send on its own. Its resolutions apply the next time an exported file comes back through the injection path. Without `--autopilot`, every interactive point pauses for a human exactly as documented below. ## Autopilot Mode When invoked with `--autopilot`, still **construct** every question/options payload exactly as the interactive path below would — wave batching, the 2–4 option cap, `(Recommended)` placed first, `Skip — decide later (TBD)` placed last — just don't call `AskUserQuestion` or wait at a checkpoint. Auto-resolve per the table below instead. **Hard-stop exceptions — never auto-resolved, even in autopilot mode:** 1. **Phase 1 ticket-fetch failure with nothing pasted.** If a tracker fetch fails and no ticket content was ever supplied, autopilot cannot fabricate a ticket. Stop and require a human to paste the content. 2. **Phase 1 pending offline export** (`make-it-work//-questions.md` exists with `**Status:** Awaiting Answers`). None of its three choices — resume it, overwrite it and continue this fresh session, or abort — carries a designated default anywhere in this skill's text, and one of them is destructive: overwriting discards a file that may hold previously recorded answers. Autopilot does not guess among the three. It prints the file's path and the three choices, then stops and requires a human. "Overwrite it and continue this fresh session" is named here as never auto-selectable on its own, independent of which of the other two choices a human later makes. 3. **Phase 5C conflicting checkboxes** (more than one box checked for the same question, including a filled-in "Other:"). There is no safe way to infer which of two explicit, conflicting human selections was intended. Stop and show the user what was checked, exactly as the interactive path already does. **Decision log:** write `make-it-work//close-the-gaps-autopilot-log.jsonl` when Phase 1 resolves the ticket or slug, overwritten fresh for this autopilot run (it describes that run only). If a ticket fetch fails before a ticket or slug can be resolved, stop without creating a ticket-scoped log and include the hard-stop in the chat summary. Field shape follows the shared schema in `docs/autopilot-log-schema.md` — this skill uses all three `kind` values (`askUserQuestion`, `checkpoint`, `open_text`); `multiSelect` is present but always `false` (this skill never presents a `multiSelect` question; it batches independent single-choice questions into one call instead); `chosen` is therefore a string, the `open_text` free-text answer, or `null` — never an array. Every line also still includes `rationale` (one sentence), per the shared schema's core fields. `phase` examples: `"Phase 1"`, `"Phase 5A"`, `"Phase 5C"`. `site` examples: `"wave-1-q2"`, `"blank-q3"`, `"followup-1"`. When Bash is permitted, use the shared writer in `docs/autopilot-log-schema.md` with `--ticket ""` for this log, invoking each writer command in its own Bash tool call; preserve this skill's timing and never use it to bypass a denied log write. This file is a run artifact: never treat it as a Phase 3 "code finding," never embed it in a `*-questions.md` export, and never reference it from Phase 6's own `## Decision Log` table — the two logs serve different audiences (this one is for auditing the autopilot run itself; Phase 6's is part of the deliverable ticket). **Resolution table** (one row per interactive site, in the order they can appear): | Phase | Site | `kind` | Autopilot resolution | |---|---|---|---| | Phase 1 | ticket-fetch failure, nothing pasted | `checkpoint` | Hard-stop exception above — stop and require a human. | | Phase 1 | pending offline export (resume / overwrite / abort) | `checkpoint` | Hard-stop exception above — stop and require a human. Never auto-select "overwrite it and continue this fresh session." | | Phase 1A | optional Slack context search | `checkpoint` | Skip without asking unless the user explicitly requested channel research for this ticket; then search within that scope. Slack delivery flags never grant research consent. | | Phase 5 | mode choice (answer here / draft in Slack / send via Slack / export to a file), no mode flag passed | `askUserQuestion` | Choose `Answer here (Recommended)`; never automatically authorize sending. | | Phase 5A | per-question wave batch | `askUserQuestion` | Choose the option labeled `(Recommended)`. | | Phase 5A | genuinely open-ended question (no pre-enumerable answer) | `open_text` | Answer with your own best inference from Phase 2–3 findings, prefixed `[autopilot best-guess]`. | | Phase 5E | unresolved questions (proceed with TBDs / pause and send to Product) | `askUserQuestion` | Choose `Proceed with TBDs (Recommended)`; preserve skips and blocked dependencies without inventing answers or authorizing delivery. | | Phase 5D | Product Manager confirmation | `checkpoint` | Accept the PM derived from the ticket without confirmation. If none can be derived, fall back to Phase 5B (log `chosen: null` with the reason). | | Phase 5C | Slack draft never sent, delivery unconfirmed, or no PM reply yet (wait / answer live) | `checkpoint` | Answer live — resolve every question through the rows below; never send or resend. | | Phase 5C | more than one checkbox checked for the same question | `checkpoint` | Hard-stop exception above — stop and require a human. | | Phase 5C | recorded answer's code finding changed in a way that contradicts it | `askUserQuestion` | Re-resolve using the same options the file recorded; choose `(Recommended)`. Log the rationale as the drift that triggered re-resolution, e.g. `" no longer matches the recorded finding; re-resolved via Recommended."` | | Phase 5C | blank checkbox-style question | `askUserQuestion` | Reuse the header, gap type, and options exactly as recorded in the file; choose `(Recommended)`. | | Phase 5C | blank open-ended question | `open_text` | Answer with your own best inference, prefixed `[autopilot best-guess]`. | | Phase 5C | `## Follow-up Needed After This Round` item | `open_text` | Answer with your own best inference from the embedded ticket/code findings, prefixed `[autopilot best-guess]`. | Only the Phase 5 mode-choice and Phase 5A/5C/5E `askUserQuestion` rows carry a `(Recommended)` label in this skill — do not invent one for the two Phase 1 checkpoints, which are hard-stops with nothing to auto-resolve, or for the Phase 5C conflicting-checkbox checkpoint. **Marking autopilot answers in the deliverable itself:** apply the marker convention from `docs/autopilot-log-schema.md` to Phase 6's `## Decision Log` table — append `_(autopilot)_` after a `(Recommended)`-resolved answer, keep the `[autopilot best-guess]` prefix on an `open_text` answer — so a reviewer reading the refined ticket alone, without `make-it-work//close-the-gaps-autopilot-log.jsonl`, can see which decisions weren't confirmed by a person. A question that was already answered unambiguously in an offline file before this run needs no marker — a human already decided it. At the end of an autopilot run, print a short human-readable summary of every auto-resolved decision (including any hard-stop that was hit) and the log file's path if one was created, so someone can audit the run afterward. --- ## Phase 1 — Ticket Ingestion **0. Detect an injection run first.** If the argument is a path to an existing `*-questions.md` file, this is an **injection** run: read the file in full, skip the rest of Phase 1, restore the original ticket content, the loaded-skills list, the code findings, and any `### Related Channel Context` from its `## Session Context` section — then re-read each skill named in that list, so its content is available for Phase 6's re-check — and go directly to **Phase 5C — Offline Injection**. Otherwise, ingest the ticket as usual: - If a ticket ID is provided, fetch it via the available MCP integration (e.g., Atlassian, Linear, GitHub Issues). If the fetch fails (not found, no access, tool unavailable), say so plainly and ask the user to paste the ticket content directly instead of retrying silently or fabricating ticket content. (autopilot: see Autopilot Mode — this is a hard-stop, never auto-resolved.) - If content is pasted, parse it as-is — work with whatever is there, even if vague or incomplete. - Extract: ticket ID, canonical ticket URL when available, summary, description, acceptance criteria, linked tickets, and any attachments or comments. Keep a URL returned by the tracker or supplied with the ticket; for Jira, a confirmed site URL and issue key can also resolve the `/browse/` link. - Retain the built-in Jira `reporter` and any returned custom-field names/metadata for Slack recipient resolution in Phase 5D. **Product Manager is a Jira custom field**, not a built-in field; its omission from the initial issue response does not establish that it is absent or empty. - Record the **source**: either "Fetched from `` issue ``" or "Pasted directly, no tracker ticket" — Phase 5B will embed this so Phase 5C can later check for ticket drift. - Derive ``: the ticket ID if there is one; otherwise a kebab-case slug of the title; otherwise `spec-YYYY-MM-DD` — the same rule Phase 6 uses for its own output filename. Reuse this one value for the rest of this phase, for Phase 5B's export filename, and for Phase 6's final spec filename, so all three always agree. - **Check for a pending offline export:** if `make-it-work//-questions.md` exists with a `**Status:** Awaiting Answers` marker, warn the user: "A pending offline export exists at `` with unanswered questions." and ask them to choose: **resume it** (re-invoke with that file's path instead — stop here), **overwrite it and continue this fresh session** (delete the stale file, then continue below), or **abort** (stop here, no changes). Do not continue past this check silently. (autopilot: see Autopilot Mode — this is a hard-stop, never auto-resolved.) - Record the selected mode flag (`--offline`, `--slack`, or `--slack-send`) for Phase 5. Reject conflicting mode flags before any analysis. `--slack` always means draft-only; generic or legacy Slack selection does not authorize sending. - Acknowledge to the user: "Loaded ticket [ID]: [summary]. Starting analysis..." --- ## Phase 1A — Optional Slack Context Search Follow [the Slack context-search contract](references/slack-context-search.md) after ticket ingestion and before drafting refinement questions. When Slack channel search is connected, offer **Search Slack** or **Skip** once. After consent, search **all accessible channels by default**, using ticket identifiers and relevant terms; channel selection is optional. Use read-only tools, summarize useful findings with message links, and surface conflicts rather than treating Slack discussions as unquestionable requirements. An unavailable or unsuccessful search does not block refinement. Autopilot skips unless explicitly requested. This is independent of later PM message delivery and applies when run by implement too. Injection/resume restores saved context without a fresh search. --- ## Phase 2 — Skills Loading Look at the list of available skills for this project (shown in the session context). Skills are organized in two layers: - **Domain skills** — cover specific functional domains. Load the ones whose scope overlaps with the ticket. - **Use-case skills** — cover specific end-to-end flows. Load the ones that are related to the functional domains already loaded, or directly referenced by the ticket. **How to detect which skills to load:** 1. Read the ticket content and extract key nouns, verbs, and domain terms. 2. Match them against skill names and descriptions visible in the session. 3. Load relevant domain skills first, then any use-case skills whose scope overlaps with the ticket. 4. When a use-case skill references a domain skill (or vice versa), load both — cross-referenced skills often contain the constraints that matter most. 5. When in doubt, load the skill — a false positive is cheaper than a missed constraint. 6. Regardless of keyword match: if the ticket introduces new persisted state or a new user-visible side effect, also check whether any available skill describes account/session-lifecycle concerns (e.g., data deletion, disconnect, logout) or audit/compliance logging for this project, and load it even if the ticket's own keywords don't reference it. Look for skills describing these *concepts*, not a specific skill name — every project names them differently, and some projects won't have one at all. Do not mention which skills were loaded unless the user asks. Just use them. --- ## Phase 3 — Targeted Code Exploration Using the loaded skills as a map, explore only the code areas relevant to this ticket. Do not do broad exploration — be surgical. When this exploration spans multiple files, multiple loaded skills, or multiple repos in a workspace — an independently reviewable unit of work, not a single targeted lookup — dispatch it to a fresh subagent (the `Explore` or `general-purpose` agent type, via the Agent tool) and work from its returned report, rather than reading every file directly in this session. This does not relax the surgical-not-broad rule above; it changes who does the surgical reading. A single, narrow confirmation (does this function exist, what are this enum's values) stays inline — forking has overhead that isn't worth it for a one-grep fact-check. Look for: - Enums, status definitions, and state machines that this ticket touches - Existing logic that would be affected or extended - Any current behavior that conflicts with what the ticket describes - Edge cases already handled that the ticket does not mention Do not summarize findings to the user yet. Use them internally to build the question list. --- ## Phase 4 — Gap Analysis (Internal Draft) Focus strictly on the **"what"** — product behavior, user-facing outcomes, business rules. Do NOT flag implementation choices, architecture patterns, or technical how-to gaps. Scan for all of the following gap types: 1. **Unclear language** — phrasing that could mean two different things 2. **Missing definitions** — terms used without being explained (e.g., "the relevant record", "the user", "the system") 3. **Unstated assumptions** — behavior implied but never written down 4. **Conflicting requirements** — two statements in the ticket that contradict each other 5. **Skill conflicts** — requirements that contradict flows, status names, transitions, or rules documented in the loaded skills 6. **Code conflicts** — behavior described in the ticket that conflicts with what already exists in the codebase 7. **Missing edge cases** — scenarios not covered: what happens on error, empty state, concurrent actions, retry 8. **Missing acceptance criteria** — things that must be true for the feature to be "done" but are not stated 9. **Scope ambiguity** — unclear whether something is in or out of scope 10. **Missing actor or trigger** — who initiates this? What event triggers it? Under what conditions? 11. **Cross-surface consistency** — when a loaded domain/UC skill documents other components or flows related to this one, does the ticket's change need to extend to them, or should it explicitly exclude them? (e.g., a new control on one surface governed by a domain skill that also governs a sibling dialog/page/flow) 12. **Cross-cutting concern interaction** — does this feature introduce new persisted state, a new notification, or any other side effect that needs to be considered by concerns that apply system-wide, regardless of domain — e.g., account or data deletion, session/logout handling, audit or compliance logging, data export/portability? These often live in a different area of the codebase than the one the ticket's own keywords would naturally point to. Before finalizing the question list, re-scan each loaded skill for other components or flows it documents besides the one the ticket directly targets — don't rely only on what surfaced during the first pass of Phase 3. Also re-scan for other documented business rules, named states/modes, or exclusions that apply to the same underlying data or calculation the ticket touches (e.g., an existing "outlier" or "recovery" classification, an exclusion list, a special-cased threshold) — a new feature that reacts to a calculated value often needs to say whether it respects an exception the loaded skill already documents for that same calculation. A structured process should catch these gaps more reliably than general thoroughness would; skipping this re-scan is the most common way it doesn't. This draft is internal only. Do not output it. Use it to generate the question list for Phase 5. --- ## Phase 5 — Interactive Q&A If `--offline` was passed in Phase 1, follow **Phase 5B** below instead of asking anything live. If `--slack` or `--slack-send` was passed, follow **Phase 5D** in draft or send mode respectively. Otherwise, ask the mode choice below, then follow the phase it selects. **Mode choice (no mode flag passed).** Ask one `AskUserQuestion` (`multiSelect: false`) whose question states the actual question count: *"I've analyzed the ticket and found [N] questions to resolve. Where should they go?"*, with options `Answer here (Recommended)` → Phase 5A; `Draft in Slack` — prepare a DM to the ticket's PM for the user to review and send → Phase 5D draft mode; `Send via Slack` — send the questions directly to the confirmed PM → Phase 5D send mode; and `Export to a file` → Phase 5B. Offer each Slack option only if the integration supports that action. Selecting `Send via Slack` is explicit authorization for this ticket's refinement message; do not add a separate send-confirmation question later. Keep Phase 5D's recipient confirmation. (autopilot: see Autopilot Mode — always `Answer here` unless a mode was explicitly selected.) When run by implement, skip this choice — see **When run by implement**. ### Phase 5A — Live Q&A Once semantic dependencies are identified, use `scripts/questions.mjs waves` under [the question-helper contract](../../docs/deterministic-artifacts.md#refinement-questions) to validate and schedule batches. Recompute after an answer materially changes the graph. Tell the user: > "I've analyzed the ticket and found [N] questions to resolve. I'll ask them in batches, grouped so you can navigate and revise answers within each batch before submitting." Emit this announcement with the actual question count before the first live question, even if the run must stop for answers and never writes a spec. Do not replace it with an unnumbered paraphrase. **Group the question list into waves before asking anything.** `AskUserQuestion` accepts up to 4 questions in a single call and renders them as navigable tabs the user can jump between and revise — but every question in that call is fixed and visible at once, so it only works for questions that don't depend on each other's answers. 1. For every question, check whether any *other* pending question's wording, options, or relevance could change depending on how it's answered. If so, that question **depends on** the other and must go in a **later** wave — never the same batch, since the user could revise the earlier answer after already seeing the dependent one. 2. **Wave 1** = every question with no unresolved dependency on another pending question. Most gap types (Unclear language, Missing definition, Missing edge case, Missing acceptance criteria, Scope ambiguity, Cross-surface consistency, Cross-cutting concern, etc.) are independent of each other by default and belong here unless one specifically hinges on another's answer (e.g., "which entity does this apply to" gates "which field on that entity"). 3. Each subsequent wave = questions whose dependencies were fully resolved by the previous wave's answers, plus any new follow-up questions those answers surfaced. **Ask each wave in one `AskUserQuestion` call:** - If a wave has more than 4 questions, split it into consecutive batch calls of ≤4 — order between those calls doesn't matter, since everything in the wave is mutually independent. - If a wave contains a genuinely open-ended question with no pre-enumerable answer, ask that one separately as plain text; do not force it into the `AskUserQuestion` array. (autopilot: see Autopilot Mode — resolved as `open_text`.) For each multiple-choice question in a batch, include it in the `questions` array with: - `header`: a short label (≤12 characters) for this question — use the gap type abbreviated, or a one-word topic (e.g. "Duration", "Scope", "Conflict"). Never put the full question text here. - `question`: `"[Gap type]: [The question]\n\n[One sentence explaining why this matters.]"` - `[Gap type]` must be one of: `Unclear language`, `Missing definition`, `Unstated assumption`, `Conflicting requirements`, `Skill conflict`, `Code conflict`, `Missing edge case`, `Missing acceptance criteria`, `Scope ambiguity`, `Missing actor/trigger`, `Cross-surface consistency`, `Cross-cutting concern` - `options`: up to 3 substantive choices **plus always one final option**: `{ label: "Skip — decide later (TBD)", description: "Leave this open; it will be listed as an unresolved item in the refined ticket." }` - The `AskUserQuestion` tool caps options at 4 per question, so use at most 3 substantive choices + the Skip option. If a gap genuinely has more than 3 meaningful answers, either narrow to the 3 most likely/valuable and let Skip implicitly cover the rest, or split it into two sequential questions (e.g., resolve the category first, then the specific value) rather than forcing a cramped single question. - Wait for the whole batch's answers before building the next wave. (autopilot: see Autopilot Mode) - Record each answer (or skip) before proceeding. Rules: - Batch every mutually-independent question of a wave into a single `AskUserQuestion` call (≤4 per call) — do not artificially split independent questions across separate calls one at a time; that throws away the navigation/revision UI for no reason. - Frame questions as **closed (multiple choice)** whenever possible. - When the answer cannot be pre-enumerated, ask in plain text instead of calling `AskUserQuestion` with fewer than two options. - **Always recommend one option per question.** Place the recommended option first in the list and append `(Recommended)` to its label. Base the recommendation on product best practices, what the codebase already supports, and what is least likely to introduce scope creep. Exception: for a `Cross-cutting concern` question, "do nothing to the existing flow" is often the smallest-scope option but not the safest one — recommend whichever option keeps the system's existing compliance/lifecycle guarantee intact (e.g., new state actually gets cleared where an existing erasure/cleanup flow promises completeness), even if it takes slightly more scope than doing nothing. - Never place the Skip option first — it should always be last. - If a wave's answers create a new gap, unblock a dependent question, or surface a follow-up, fold it into the next wave rather than re-opening or re-batching a wave already asked. - Never ask about implementation details, technical choices, or architecture. - Skipped questions are recorded and included as TBD in the final output. - A skipped gating answer does not resolve its dependencies. Defer dependent questions whose wording or relevance cannot yet be determined; keep their conditions and any unformulatable follow-ups unresolved rather than guessing or treating them as out of scope. Continue with independent questions. - After the last answerable wave, follow **Phase 5E**. Say "All questions answered. Generating refined ticket..." only when nothing remains unresolved. ### Phase 5E — Unresolved Questions Apply after live Q&A or offline/Slack injection, before Phase 6. If nothing remains unresolved, proceed directly to Phase 6 without another question. Otherwise summarize the resolved and unresolved counts, including skipped questions and follow-ups blocked by a skipped answer, and offer exactly two choices in one `AskUserQuestion`: - **Proceed with TBDs (Recommended)** — generate the refined ticket with the existing answers and an explicit unresolved checklist. This completes refinement with TBDs; it does not resolve them or authorize development past existing readiness gates. - **Pause and send to Product** — preserve existing answers, hand off only unresolved questions, and pause without generating a spec. Explain in the option description whether delivery can send via Slack or will require a manual file handoff. This selection explicitly authorizes the displayed unresolved-question message to the confirmed PM; do not ask another send-confirmation question. For **Proceed with TBDs**, go to Phase 6. Keep unresolved conditional questions in the TBD list with their gating condition; do not add Decision Log rows for questions that were never asked or invent acceptance criteria for unresolved behavior. For **Pause and send to Product**, use Phase 5D send mode when supported, otherwise its documented draft/file fallback. Discover available delivery capabilities before describing the choice. Preserve the session snapshot, code findings, all recorded answers and notes, original question IDs, and dependency conditions in the questions file. Keep answered questions checked as read-only context for this handoff; turn only skipped questions back into unanswered fields, retaining a note that the user deferred them to Product. Include unresolved conditional branches per Phase 5B and preserve unformulatable follow-ups under `## Follow-up Needed After This Round`. Omit branches ruled out by resolved decisions from the message; never re-ask resolved questions. In the message, summarize answered decisions as context separately from the unresolved questions and retain the original Q-numbers. Leave the file `Awaiting Answers` and stop through the normal Phase 5D handoff. On resume, preserve resolved answers and apply Phase 5C only to unresolved or newly applicable questions. An explicit human answer or recorded code drift can reopen a decision under the existing conflict/drift rules. Follow this choice again only if the resumed round leaves unresolved items; do not send another message without a new explicit handoff selection. Preserve any existing pending/unknown delivery metadata and reconcile it under Phase 5C before considering a new delivery. ### Phase 5B — Offline Export Build the **complete** question list up front — every wave, not just Wave 1 — since there is no live back-and-forth to reveal later waves incrementally: 1. Compute Wave 1 exactly as in Phase 5A. 2. For each question, enumerate every later-wave question that depends on it, for each of its own options, **recursively** — a question two or three waves deep (e.g. a chain like Trigger → Detect → Reinvoke) is still written out, chained through its own immediate gating question rather than only checked against Wave 1. Write each dependent question directly after the question it depends on, so the file's order always presents a gating question before anything conditioned on it. Label each with the exact condition under which it applies (see template below). If a later question's wording or options cannot be enumerated without an answer that doesn't exist yet (e.g. it depends on free text with no fixed set of branches), do not force it into the file — record it instead under a `## Follow-up Needed After This Round` section at the end of the file, in plain language; Phase 5C resolves it live rather than exporting a second file. 3. Do not call `AskUserQuestion`. Do not ask anything in chat. Write the file to `make-it-work//-questions.md` (the same base name Phase 1 derived and Phase 6 will use), using this template: ```markdown # Offline Questions — > **Status:** Awaiting Answers > Fill in the checkboxes and notes below, save this file, then re-invoke: > `/make-it-work:close-the-gaps ` ## Session Context ### Source <"Fetched from issue " or "Pasted directly, no tracker ticket">, exported ### Original Ticket ### Skills Loaded - — ### Code Findings - Q1 — ``: ### Related Channel Context ## Questions ### Q1 — [Gap type] **Question:** **Why it matters:** - [ ]