| name | tabletop |
| description | Front-loaded pre-spec thinking — walk values, trade-offs, halt conditions and kill conditions across a card or cluster to produce aligned specs |
| argument-hint | [card-id | card-id-1 card-id-2 ... | "goal string"] |
| allowed-tools | Bash Read Edit Write AskUserQuestion |
/orb:tabletop
Tabletop is the canonical pre-spec session for substantive R&D. One session, one card or a cluster in scope, one or more specs out. The output is the spec's contract — values, trade-offs, halt conditions, escalation triggers, kill conditions, hot-wash — never the spec's solution.
Choice 0017 (tabletop-output-is-contract) pins the load-bearing rule: tabletop captures what to optimise for and what would stop us; the spec captures the AC contract; the drive captures the implementation. Conflating these is the failure mode this skill exists to prevent.
Agent prose follows the discipline in .orbit/STYLE.md (see card 0026 — .orbit/cards/0026-agent-prose-discipline.yaml).
@.orbit/STYLE.md
Usage
/orb:tabletop [card-id | card-id-1 card-id-2 ... | "goal string"]
A goal-string invocation infers the card cluster from orbit card list, surfaces the inferred set with one-line rationales, and confirms via AskUserQuestion (approve / modify / extend) before alignment work begins.
When to use
- Substantive R&D where alignment cost would compound across the work
- Cross-cutting work touching two or more cards in one cluster
- Goal-scoped work where the cluster of cards isn't pre-determined
Trivial-skip advisory
When the work appears trivial — single-line change, typo fix, single-AC scope — the skill surfaces a prose nudge at session open:
"This looks trivial; a direct /orb:spec is recommended. Tabletop is reserved for substantive R&D where alignment cost would otherwise compound. Proceed anyway? (y/N)"
The advisory is prose, not AskUserQuestion — the operator chooses by typing or by continuing. The skill does NOT refuse. Per card 0019 scenario 10.
Before Q1 — name the capability ambition
State the underlying capability ambition of the card cluster in one sentence before scope-carving begins. Carving multiple specs out of one cluster requires a concrete defence drawn from {technical dependency, hard budget, operator-bandwidth, parallelism}. "Manage risk" and "ship incrementally" are explicitly rejected as standalone defences — name the dependency, the budget, or the parallelism, or carve as one spec.
The 10 questions
Walk these in declared order. Prose opens each question; AskUserQuestion closes the pick when the fork is discrete. Reach for past run-logs before inventing scenarios; flag imagined ones inline with [imagined].
- Q1 — Goal narrowing. Lock the goal in one sentence the author would say to a colleague.
- Q2 — Values. Name what the work is optimising for; surface the load-bearing one.
- Q3 — Trade-offs. Enumerate what the work trades against the chosen values; confirm the cut is the simplest cut that holds them.
- Q4 — Failure modes. Enumerate ways the work fails; classify each as halt-worthy or engineering-hygiene.
- Q5 — Lateral approaches. Name the alternatives that aren't being picked, with reasons. Held in reserve as fallback paths.
- Q6 — Success criteria. Pin binary, measurable criteria that trace to a value or trade-off.
- Q7 — Escalation triggers. Name when the agent should halt and surface to the author mid-flight, with the proposed action.
- Q8 — Adjacent code. Enumerate which layers/modules the work touches; route file-level questions to Implementation Notes in the sidecar.
- Q9 — Budget. Name the working-day budget at Claude-execution pace, not at conservative-engineering quotes.
- Q10 — Kill conditions. Name the failure of each load-bearing claim, with a named pivot path.
Hot-wash debrief
After Q10, capture meta-observations in prose — what kept coming up, what was unclear, what reframes surfaced. Two to five bullets per category: recurred, surprised, friction, meta-patterns-for-future-tabletops. Fresh, before formal write-up sanitises the signal.
Per-scenario verification classification
Every scenario the resulting spec will cover carries one verification classification line in the tabletop sidecar — verifies: capability (the test exercises the underlying capability directly) or verifies: stand-in (real thing is X), accepted because Y. No third option. The classification lives in a dedicated Verification posture section in the sidecar (or, if compact, inline in Trade-offs). /orb:spec carries this verbatim into each AC (see spec SKILL.md halt rule).
Output
One session, N specs (N ≥ 1); each spec gets its own folder under .orbit/specs/<date>-<slug>/ with its own tabletop.md sidecar.
# Tabletop — <Topic>
**Date:** YYYY-MM-DD
**Cards in scope:** <cluster>
**Output spec:** .orbit/specs/<spec-id>/spec.yaml
---
## Values
<from Q2 — the load-bearing value and what falls out of it.>
## Trade-offs
<from Q3 — each named trade-off classified acceptable / expensive-but-worth-it / halt-trigger.>
## Halt conditions
<from Q4 halt-worthy entries — each names a measurable trigger and a revert or pivot path. Anti-patterns like "halt and reassess" or " " >
Next step: /orb:spec against each output spec folder to crystallise the AC contract from the tabletop's values, trade-offs, halt conditions, escalation triggers, kill conditions, and acceptance criteria.
