Mission/Slice SOP — Part A

Use this skill to actually do mission/slice work: track on the canonical files, record what you proved, hand off through them, and survive compaction on them. Do the work described here; do not merely explain the protocol.

Full convention SSOT: repo docs/reference/sdlc-conventions.md; installed $OPENRIG_HOME/reference/sdlc-conventions.md. This skill is the concise Part-A teaching surface and does not replace the full convention.

Resolve the work first

Run rig whoami --json, then resolve project.yaml -> mission.yaml -> active slice.yaml -> selected component or wave map -> addressed context. The complete lookup and precedence rule is docs/reference/product-journey-sdlc.md#resolve-the-selected-path (installed: $OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path). Read the selected addresses and source needed for this task; skills available in your profile are capabilities, not a mandatory reading list. No composition means light Part A. Role names and idle seats add no gates. Explicit rigor and authored wave boundaries retain their named checks.

The light inner loop is ground yourself → build → test with your own eyes → iterate → record and return the whole outcome. The builder may hold this check on a tiny change. Independent review runs only when selected, and once at an authored wave boundary rather than once per slice.

Part B is defined in the conventions SSOT and runs only when explicitly assigned to named work. If you believe it is needed, state the reason to the owner and continue on the selected path until that choice changes.

Proportionality — this SOP serves shipping; it is not the work itself

The working product is the deliverable. This bookkeeping exists so the work survives handoff, compaction, and review — nothing more. Match it to stakes. The rig scope audit backstop is advisory and fail-open: it never blocks a build and is not a gate you clear before proceeding. If you're spending more time on the convention files or the audit than on the running product, stop and go build. Running the full apparatus on a small change is the letter-worship failure, not diligence.

The three role contracts

• Planning agent: records what the slice is for and what "done" looks like, in the slice's own words; produces mockups for UI deliverables so the builder has something to look at (a UI slice with no mockup is an incomplete plan; non-UI slices have none — not a gate).
• Build agent: builds it, and looks at the mockups. Verifies by running the thing.
• QA agent (owns the compare): compares planned vs delivered per deliverable, records the verdict and the note. On mismatch: fix-and-re-review, or kick back with the reason — never escalate a raw mismatch to the human.

These three are a division of labour, not a chain of gates. One agent may hold all three on a small slice.

The current file contract

These files are the operating surface of the work — you track on them, record on them, hand off through them, and survive compaction on them. Keep them current because that is what lets the work survive. But they serve the product; they are not the product. If you're polishing files while the actual thing isn't shipping, you've inverted it: go build, then update them.

• Slice: SPEC.md, PROGRESS.md, PROOF.md, and proof/.
• Mission: SPEC.md and NOTES.md.

Per-file rules — WHO / WHEN / HOW

SPEC.md

• WHO: the planning owner authors it; builders and reviewers read it as the scope and intent source.
• WHEN: at creation and whenever scope changes.
• HOW: a slice carries intent: in frontmatter and opens with ## Intent, ## Mini-requirements, and ## Proof contract. A mission carries its intent and mission-level specification in the same authored node file. Keep depth proportional to the work.

PROGRESS.md

• WHO: the orchestrator owns the current state; every agent logs its own outcomes.
• WHEN: on material delivery-state changes and at acceptance.
• HOW: keep current delivery state in ## Current state, naming who the next move waits on, and check that against the source (the PR on GitHub, the queue) before you rely on it; append material outcomes with links to proof under ## Outcomes. Retain historical entries and existing checkboxes without treating them as current acceptance authority. For a selected proof policy, use rig proof show <slice> for current readiness; keep frontmatter stage/verified honest.

PROOF.md + proof/

• WHO: the impl/QA pair that worked the slice.
• WHEN: before you call a slice done.
• HOW: say what you verified and how you verified it — by effect: you ran it and looked at the result. Put supporting media under proof/. State plainly what is proven and what is not; an honest "this half is untested" is worth more than a checkmark. If a drop verb is in play for this slice, prefer it over hand-placing files so the artifact carries its own provenance.

NOTES.md

• WHO: any agent updates §1 (top-of-mind); each seat owns and appends to its own §A–§X.
• WHEN: on material mission-context changes; a compacting agent files its state here BEFORE compaction and reads it on restore.
• HOW: accruing tribal knowledge — §1 ≤ 5–15 lines (gates, open decisions, surprises); per-seat continuation entries (latest = truth; other seats read-only). Pointer-first; don't duplicate.

The lifecycle (4 legs)

SCAFFOLD (rig scope creates the files from templates) → POPULATE (agents fill them as work happens) → PROJECT (the Living Notes UI reads them into INTENT → PLAN → DELIVERED) → VERIFY (rig scope audit, advisory). "Loose freeform write + deterministic verify."

Hot-potato (handoffs)

End every turn by passing the ball — a rig queue handoff to the next agent. The handoff verb is transactional: it closes the source as handed-off and mints the successor owned by --to, so the baton cannot be dropped. A handoff terminates only at the orchestrator seat, which holds the context to judge whether a park is legitimate.

A plain rig queue create row is informational — a durable message. It is not a baton and does not carry this obligation. Use handoff when you are passing real work; use create when you are informing.

Never go idle holding a baton.

Records

The rules for recording a slice's state are in the conventions SSOT (docs/reference/sdlc-conventions.md in the OpenRig source repository, $OPENRIG_HOME/reference/sdlc-conventions.md when installed). Read them before you stamp, judge or report:

• Stamps, stages and proof: A2 (rig proof judge, rig scope slice stage and verified) and B2–B3 (rig scope slice approve --scope spec|delivery, rig proof add and --candidate-sha).
• Built and merged: the release-mission paragraphs of A1 (candidate:<sha>, merged:<pr-number>, arrangement.source.integration_ref).
• Dispatch data: the DISPATCH DATA row of the component menu (the worktree_path= body line).
• Editing judged evidence resets the judgment. An accepted rig proof judge records the sha256 of the evidence it cites; edit that evidence (the cited section, when it cites a heading), the contract item's text or the scope's proof policy, and the item reads unknown until you judge it again.

Verify (deterministic backstop)

Run rig scope audit at slice-close. Every convention check is advisory / fail-open — it records and advises, never blocks a write. Fix what's real, skip what isn't, keep moving. A clean audit score is not required to proceed.

Reading terminal captures — KNOWN GOTCHA: ghost-text autocomplete is NOT real

When you rig capture a pane, greyed / ghost autocomplete suggestions are NOT real content — they are autocomplete previews, not typed, staged, or committed input. This has been faking agents out a lot: reading a ghost suggestion in a peer's input box as "staged text they're about to send," then reasoning on a string that was never there.

Rule: ignore ghost/autosuggest text entirely. Only committed/rendered pane output is real. When it matters, verify at source (git, the queue, the actual event) — never off a capture's ghost line.

A plain capture loses the grey, so rig capture reads it for you. For a Claude Code or Codex seat, a [rig capture: <seat>: input box: ...] note on stderr (and inputBox in --json) says whether the input box's text is likely a harness suggestion or typed, from where the cursor is and whether the text is drawn faint. Don't act on likely-suggestion text as anyone's intent, and treat unknown as unknown: verify at source.

Moment-of-truth checklist

• Starting a slice? → do you know what it's for and what done looks like? mockups attached (UI slices)? Are you on the light path? (You are, unless the mission owner assigned the overlay.)
• Finishing a slice? → does PROOF.md say what you actually verified, by effect, including what is NOT covered? PROGRESS.md updated? mission NOTES.md refreshed? handed off via rig queue handoff?
• Compacting? → file your state in mission NOTES.md; on restore, read it plus the active slice's SPEC.md, PROGRESS.md, and PROOF.md.
• Starting on a mission? → read mission SPEC.md, NOTES.md, and the conventions SSOT.