mission-slice-sop

Name: mission-slice-sop
Author: mvschwarz

56stars9forks

How to install mission-slice-sop?

mvschwarz/openrig/mission-slice-sop

$npx -y skills add mvschwarz/openrig --skill mission-slice-sop

Installs into the current project.

Summary

Use when working a mission or slice — the full SDLC flow (intent → mini-requirements + proof contract → mockups → plan-lock → build → QA visual compare → rig proof drops → proof-lock) plus how to track, prove, hand off, and carry state across agents and compaction via the canon

Files · 1

View on GitHub

SKILL.md

1	# Mission/Slice SOP — how you work a mission & slice
2
3	Use this skill to actually do mission/slice work the way OpenRig expects: author the convention sections, track on the canonical files, prove on them, hand off through them, and survive compaction on them. Do the work described here; do not merely explain the protocol. The deterministic backstop is `rig scope audit` — the audit classifier is the source of truth for adherence. The conventions themselves live in ONE place: `docs/reference/sdlc-conventions.md` (shipped with the CLI package) — this skill teaches the flow; the SSOT defines the formats.
4
5	## The SDLC flow (intent → proof)
6
7	```
8	intent → mini-requirements + proof contract → (UI slices: mockups)
9	→ plan-lock (rig scope slice approve --scope spec)
10	→ build the LOCKED set
11	→ QA: mockup ↔ delivered VISUAL compare
12	→ proof drops (rig proof add <slice> …)
13	→ proof-lock (rig scope slice approve --scope delivery)
14	```
15
16	1. Record intent verbatim in the slice's `## Intent` section (`rig scope slice create` scaffolds it — every template kind).
17	2. Author the mini-requirements + proof contract: `## Mini-requirements` is the concise one-glance tier (approval starts there); `## Proof contract` is a checkbox list of promised deliverables, each written as an observable outcome. UI deliverables name their planned mockup. The IMPLEMENTATION-PRD opens with the mini-requirements; everything between intent and proof is elastic — for a small slice the mini-requirements may BE the whole PRD.
18	3. Plan-lock: `rig scope slice approve <slice> --scope spec` — "the PRD matches the intent; THIS artifact set is what gets built." One daemon-side write: frontmatter stamp + append-only audit row.
19	4. Build the locked set — look at the mockups, not just the spec text.
20	5. QA visual compare: for each deliverable, load the planned mockup, produce the real artifact in a test/demo environment, visually compare, and record the verdict.
21	6. Drop proof: `rig proof add <slice> --artifact-type qa --verdict PASS --candidate-sha <tip> --money-evidence "…" --evidences "1,3" --media "walk.webm,panel.png" --self-check "…"` — the C1 header's closed sets validate at drop time; `--evidences` joins the drop to its proof-contract items and `--media` names the curated proof/-relative media the drop stands behind (that pairing + media set is what the UI's DELIVERED section renders).
22	7. Proof-lock: `rig scope slice approve <slice> --scope delivery` — the terminal sign-off. Approval is freeze/sign-off, never proven-green: proven-green requires the recorded C1 verdicts.
23
24	## The three role contracts
25
26	- Planning agent: authors intent + mini-requirements + the proof contract; produces mockups for UI deliverables and attaches them to the locked set (a UI slice with no mockup is an incomplete plan; non-UI slices have none — not a gate); locks the plan.
27	- Build agent: builds against the LOCKED set only; looks at the mockups.
28	- QA agent (owns the compare): visually compares planned vs delivered per deliverable, records verdict + note via proof drops, and curates the canonical proof set (bounded, mapped to deliverables; the fix-loop pile stays in `proof/`, one drill-in down). On mismatch: fix-and-re-review or kick back with the reason — never escalate a raw mismatch to the human.
29
30	## The canonical files (the operating surface)
31
32	> The canonical files below are the operating surface of the work — you track on them, prove on them, hand off through them, and survive compaction on them. They are NOT side-artifacts to "ma

People who liked this also viewed

6 picks

Type

mission-slice-sop

56stars9forks

View on GitHub

How to install mission-slice-sop?

mvschwarz/openrig/mission-slice-sop

$npx -y skills add mvschwarz/openrig --skill mission-slice-sop

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Mission/Slice SOP — how you work a mission & slice
2
3	Use this skill to actually do mission/slice work the way OpenRig expects: author the convention sections, track on the canonical files, prove on them, hand off through them, and survive compaction on them. Do the work described here; do not merely explain the protocol. The deterministic backstop is `rig scope audit` — the audit classifier is the source of truth for adherence. The conventions themselves live in ONE place: `docs/reference/sdlc-conventions.md` (shipped with the CLI package) — this skill teaches the flow; the SSOT defines the formats.
4
5	## The SDLC flow (intent → proof)
6
7	```
8	intent → mini-requirements + proof contract → (UI slices: mockups)
9	→ plan-lock (rig scope slice approve --scope spec)
10	→ build the LOCKED set
11	→ QA: mockup ↔ delivered VISUAL compare
12	→ proof drops (rig proof add <slice> …)
13	→ proof-lock (rig scope slice approve --scope delivery)
14	```
15
16	1. Record intent verbatim in the slice's `## Intent` section (`rig scope slice create` scaffolds it — every template kind).
17	2. Author the mini-requirements + proof contract: `## Mini-requirements` is the concise one-glance tier (approval starts there); `## Proof contract` is a checkbox list of promised deliverables, each written as an observable outcome. UI deliverables name their planned mockup. The IMPLEMENTATION-PRD opens with the mini-requirements; everything between intent and proof is elastic — for a small slice the mini-requirements may BE the whole PRD.
18	3. Plan-lock: `rig scope slice approve <slice> --scope spec` — "the PRD matches the intent; THIS artifact set is what gets built." One daemon-side write: frontmatter stamp + append-only audit row.
19	4. Build the locked set — look at the mockups, not just the spec text.
20	5. QA visual compare: for each deliverable, load the planned mockup, produce the real artifact in a test/demo environment, visually compare, and record the verdict.
21	6. Drop proof: `rig proof add <slice> --artifact-type qa --verdict PASS --candidate-sha <tip> --money-evidence "…" --evidences "1,3" --media "walk.webm,panel.png" --self-check "…"` — the C1 header's closed sets validate at drop time; `--evidences` joins the drop to its proof-contract items and `--media` names the curated proof/-relative media the drop stands behind (that pairing + media set is what the UI's DELIVERED section renders).
22	7. Proof-lock: `rig scope slice approve <slice> --scope delivery` — the terminal sign-off. Approval is freeze/sign-off, never proven-green: proven-green requires the recorded C1 verdicts.
23
24	## The three role contracts
25
26	- Planning agent: authors intent + mini-requirements + the proof contract; produces mockups for UI deliverables and attaches them to the locked set (a UI slice with no mockup is an incomplete plan; non-UI slices have none — not a gate); locks the plan.
27	- Build agent: builds against the LOCKED set only; looks at the mockups.
28	- QA agent (owns the compare): visually compares planned vs delivered per deliverable, records verdict + note via proof drops, and curates the canonical proof set (bounded, mapped to deliverables; the fix-loop pile stays in `proof/`, one drill-in down). On mismatch: fix-and-re-review or kick back with the reason — never escalate a raw mismatch to the human.
29
30	## The canonical files (the operating surface)
31
32	> The canonical files below are the operating surface of the work — you track on them, prove on them, hand off through them, and survive compaction on them. They are NOT side-artifacts to "ma

People who liked this also viewed

6 picks

Type