version: "1.0.1" name: present-gate description: "First-officer gate-presentation rendering — the captain-facing gate-review template and assembly rules, including workflow-owned finding labels. Invoke at the gate point after the FO has decided a stage must be presented." user-invocable: false

Present Gate

This skill carries the first-officer's captain-facing gate-presentation rendering: the gate-review format template and the assembly rules for filling it. The decide-to-gate and AC-cross-check policy stays always-on in the FO contract; this skill loads at the gate point to render the decision the FO has already made.

Presentation channels

Chat is the default channel. After the prepared room and binding commit, render the gate template as exactly one root-assistant message before the next decision-mutation tool call. The message must name the entity and stage, a compact bound Briefing snapshot, one recommendation, and the decision ask; exact headings are not required. A short digest prefix may identify the snapshot in prose; request.json, the canonical Briefing, and recorder validation retain the exact full digest authority. Prior narration, child/tool output, or a later summary does not complete presentation. Delegated authority does not waive presentation. Only then hand the captain's semantic decision to ${SPACEDOCK_BIN:-spacedock} gate record ... --decision. An override changes only where the captain sees the review; gate policy and recorder ownership stay unchanged.

A qualifying chat review is semantic: wording may vary while those five facts remain explicit. The presenter emits once; the lifecycle, prompt, and host adapter do not duplicate its review.

A workflow or session may declare one presentation override. Apply this contract:

1. Pass only the emitted room after its bind commit. Wait for gate prepare to succeed and «state.commit» to durably bind its exact emitted room= value. Give the selected override exactly that room through its declared interface as an opaque handoff.
2. Reconstruct no authority. Do not pass or reconstruct entity, workflow directory, Briefing path/id/digest, actor, approver, destination, or any implementation coordinate beyond the room. Do not read request.json to build another caller surface.
3. Record only prepared-room authority. When the selected channel returns a recorder-ready room, run ${SPACEDOCK_BIN:-spacedock} gate record <entity> --room <room>. The recorder re-reads the frozen request and arbitrary canonical Briefing locator, recomputes request/Briefing/Result/inventory pins, derives the complete association in memory, and writes no association.json. Once the override receives the room, a failed handoff or missing, advisory, or invalid Result leaves that attempt open; do not fall back to chat or another channel, and never write entity frontmatter directly.

The generic Spacedock contract ends at the opaque handoff: it names no override executable, transport, presentation implementation, or evidence-production mechanics. Spacedock's binary owns provider-neutral room verification and recording.

Gate Presentation

Present gate reviews in this format:

Gate review: {entity title} — {stage}
Chosen direction: {one-line summary of the ensign's chosen approach, or `n/a` for stages without a chosen-direction concept (e.g., simple work stages, merge)}
Recommend {approve | reject: {one-line reason}}.
Reviewed snapshot: {bound Briefing identity and compact digest prefix}
 
Checklist (from ## Stage Report in {entity_file_path} lines {start}-{end}):
- DONE: {≤10-word gist of item}
- SKIPPED: {gist} — {one-line reason}
- FAILED: {gist} — {one-line reason}
 
{If reviewer findings exist, render them under `Reviewer findings` in the active workflow's declared category order and exact labels. Preserve each recorded category and omit empty categories. If the workflow declares none, use one neutral `Findings:` list. If no reviewer ran, omit this whole block.}
 
Assessment: {N} done, {N} skipped, {N} failed.
 
Decision: {one-line decision prompt naming what approval/rejection does in concrete terms — e.g., "approve to enter implementation in worktree `.worktrees/...`" or "reject to bounce back to {feedback-to target} with the authorized findings above"}.

Captain-facing assembly rules

The template is the floor, not the ceiling. The FO MUST hold to the following discipline when filling it:

1. Lede first, decision last, nothing between them buried. The first three lines (title, chosen direction, recommend) and the final line (decision) are the spine. Everything else is supporting evidence; if the captain stops reading after line three, they can still vote.
2. Chosen direction is required as FO prose. When the stage selected among options (ideation picks an approach, validation picks PASS/REJECTED), name it on the Chosen direction: line; don't make the captain infer from the Checklist gist or open the entity file. For stages without a chosen direction, use n/a.
3. Cite the Stage Report; render a one-line gist roll-up. Do not paste it into the gate message. Under Checklist:, render one bullet per DONE/SKIPPED/FAILED item as a verb-noun gist (≤10 words, FO paraphrase, no new facts). For SKIPPED/FAILED, append — {one-line reason}. Cite the full report by file path and line range. If a decision-relevant reviewer finding directly questions a checklist item's evidence, inline that item's evidence paragraph under the finding so the captain can decide without opening the file. Otherwise no Stage Report content appears.
4. Reviewer findings preserve workflow classification. Render findings in the active workflow's declared category order and exact labels, preserving each recorded category and dropping empty categories. If the workflow declares none, use a neutral Findings: list. Presentation never classifies.
5. Recommendation appears exactly once. The Recommend {approve | reject: {reason}} line is the only place the FO states its verdict. Do not duplicate it elsewhere or re-explain it in an enumerated list.
6. Bounce-back recommendations name the concrete asks. If recommending reject, the reason line names the specific concerns by content, not by reference. Bad: "address the reviewer's five concrete notes." Good: "tighten AC-2 substring assertion; correct the file X claim; cut the format-pedantry aside."
7. No format-pedantry asides. Format drift (1./2./3./4. instead of **AC-N**, missing trailing period) is not load-bearing for a gate decision. Surface it only when the active workflow's policy makes it gate-blocking, under that policy's exact category label.
8. One sentence of worktree heads-up when approval changes worktree state. When approving opens or closes a worktree, the Decision line names it: "approve to enter implementation in worktree .worktrees/{worker_key}-{slug}". One sentence, not a section.
9. Target length: 15-25 lines of FO-authored prose. The full gate message should fit in 15-25 lines. If it exceeds 25, the FO is over-narrating; cut.
10. FO-authored prose speaks the workflow's declared label. Where the gate-summary prose the FO writes — the Chosen direction: line, the Checklist: gist roll-up, the Decision: line — names the kind of thing under review, use the workflow's declared entity-label / entity-label-plural from «state.boot»(), not the generic "entity". A ticket workflow's Decision line says "approve to enter implementation on this ticket"; an experiment workflow says "experiment". The {entity title} placeholder and the structural headings (Gate review:, Checklist:, Decision:) stay generic — only the FO-authored noun localizes.
11. Surface verification state as evidence, not as a label. When the gate turns on checks that ran outside this presentation (CI lanes, a validation report), hold them to the shared core's self-evidence bar (## Working Principles): state which relevant checks actually ran and passed, and read any failure from this run's evidence (the failing test/assertion), never from an inherited "known flake" label. The captain votes on which checks are green and why a red is red.