dos-next-up
dos-next-up is a Claude Code skill that audits a repository's phased plans against actual commit history to produce a snapshot of what work is shipped versus pending. It walks the plans glob defined in dos.toml, verifies each phase candidate using the dos verify syscall, renders a self-contained dispatch packet to the configured output directory, and reports a gate verdict. Use this skill when you need a factual "where are we / what's next / who-does-what" assessment of any repository with plan documents and real commits, driven entirely by configuration rather than host-specific paths or conventions.
git clone --depth 1 https://github.com/anthony-chaudhary/dos-kernel /tmp/dos-next-up && cp -r /tmp/dos-next-up/src/dos/skills/dos-next-up ~/.claude/skills/dos-next-upSKILL.md
# dos-next-up — the generic plan-and-ship snapshot
> **This is the baseline screenplay DOS ships, not a prerequisite.** It drives the
> kernel syscalls (`verify`, `gate`) against *any* repo whose layout lives in
> `dos.toml`. It names no host directory, no host lane, and no host commit
> convention — every host specific comes from `dos doctor --json` (paths/lanes,
> via WCR) or `dos.toml [stamp]` (the ship grammar, via SCV). Copy it into your
> own skills dir, point `dos` at your workspace, and it runs.
The shape is domain-free: **discover the layout → walk the plans → audit each
pick against the truth syscall → render a packet → gate the empty case.** The
*policy* (which lanes, which plan grammar, where output lands) is data the
screenplay reads, never literals it hardcodes.
## Inputs
- `--scope <name>` (repeatable, optional) — narrow candidates to one lane (a
name from the active `[lanes]` taxonomy) or one plan id. Omitted = all plans.
- `--limit <N>` (optional, default 5) — how many top picks to render.
## Step 0 — Discover the workspace layout (one call)
Run the doctor verb and read the result. **This is the WCR on-ramp: every
path/lane below comes from here, never a literal.**
```bash
dos doctor --workspace . --json
```
Parse the JSON object. The fields you use:
- `paths.plans_glob` — the glob to walk for plan docs (whatever the workspace
declared). **Use this value; never assume a fixed plans directory.**
- `paths.next_packets` — where the rendered packet is written (the configured
output dir; `.dos/verdicts` under the generic default).
- `lanes.concurrent` / `lanes.exclusive` / `lanes.trees` — the active lane
taxonomy, if you need to group picks by lane or honor a `--scope`.
- `stamp` — the active ship-subject grammar (informational; `dos verify` applies
it for you — you never grep subjects yourself).
If `git` is `false`, warn the operator: `dos verify`'s git rung has no history to
read, so every pick will report `source="none"` unless a registry exists.
## Step 1 — Walk the plans glob → candidate picks
List the plan docs under `paths.plans_glob` (relative to `paths.root`). For each
plan doc, read its phase headings to extract `(plan_id, phase_id)` candidate
pairs — the next not-yet-shipped phases. Keep this generic: a "phase" is a
heading the doc marks as a unit of work; you do not need the job's exact
frontmatter. If a `--scope` was given, keep only plans/lanes that match it.
Collect a flat list of candidate `(plan, phase)` picks. Do not rank by any
host-specific signal — order by plan-doc order, then truncate later.
## Step 2 — Audit each candidate against the truth syscall
For **each** candidate pick, ask the kernel whether it already shipped — never
trust the plan doc's own stamp, and never grep commit subjects yourself:
```bash
dos verify --workspace . <PLAN> <PHASE> --json
```
Read the `ShipVerdict` JSON: `{shipped, source, sha?, plan, phase}`. `source`
tells you *how* the kernel knows: `registry` (a ship row), `grep` (a commit
subject under the active `[stamp]` grammar), or `none` (no positive evidence).
This is the SCV payoff — a foreign repo whose commits read `AUTH2: …` is
recognized iff its `dos.toml` declares the matching `[stamp]`.
Classify each pick into one of three dispositions — this is what the gate reads:
- **`shipped: false, source: "none"`** → **live**: a real next pick. Disposition
`{phase, live: true}`.
- **`shipped: true, source: "registry"`** → **done, cleanly**: a ship row exists.
Disposition `{phase, live: false, drop_reason: "shipped"}` — drop it.
- **`shipped: true, source: "grep"`** → a real **git ship**. Now check the plan
doc: does its heading for this phase carry a SHIPPED stamp? If **yes**, drop it
as a clean ship (as above). If **no**, this is a **stale stamp** — the work
shipped in git but the plan doc lags — and you must encode it so the gate can
catch the false-drain: `{phase, live: false, drop_reason: "shipped",
"ship_via": "direct", "plan_doc_stamped": false}`.
The `ship_via: "direct"` + `plan_doc_stamped: false` pair is the *exact* shape
`dos gate` classifies as STALE-STAMP (a `grep` ship the plan doc doesn't reflect).
**Do not put verify's `source` value into `ship_via`** — `ship_via` is the gate's
own direct-ship marker, set to the literal `"direct"` only for an unstamped git
ship; a `registry` hit is a clean `shipped` drop, never STALE-STAMP.
Keep the first `--limit` live picks as the packet's dispatch list.
## Step 3 — Render the dispatch packet
Assemble a self-contained markdown packet **yourself** (DOS ships no packet
template in the kernel — see the friction log: the `[render]` packet-template
seam is a named open axis). Write it under `paths.next_packets`, named
`next-up-<UTC-date>-<N>.md`. The packet has, generically:
1. **Header** — the workspace root, the active lane taxonomy, the run timestamp.
2. **Portfolio snapshot** — one row per plan: plan id, how many phases, how many
verified shipped (from Step 2), the next live phase.
3. **Dispatch list** — for each live pick, a self-contained prompt another agent
could be launched with: the plan id, the phase id, the plan-doc path, and the
one-line goal. Keep each prompt standalone (no shared context). **The dispatch
list IS a proposed fan-out partition** — if these picks are about to be launched
in parallel, price the partition first with
[`dos-plan-price`](../dos-plan-price/SKILL.md) so a colliding set is caught
before any agent launches, not when the colliding lease is refused mid-wave.
4. **Already shipped** — the picks Step 2 found `shipped: true`, with `source`/`sha`.
Alongside the packet, emit the gate sidecar so Step 4 can classify it — write
`<paths.next_packets>/.dispositions-<tag>.json` with the kernel's contract. One
entry per pick the packet considered, using the Step-2 classification:
```json
{
"schema": "oc3-dispositions-v1",
"tag": "<tag>",
"dispositions": [
{"phase": "AUTH2", "live": trueAdjudicate a GitHub issue's "this is resolved" claim from witnesses the claimant didn't author — then close it carrying the evidence, or refuse with the typed gap. Use when an issue looks already-solved, after landing a fix that should have closed one, or to sweep open issues for silently-resolved ones.
Pick the next most important open GitHub issue this agent can actually complete, make its done-condition true, land it with witnesses (suite + parity + commit-audit), and priority-tag every issue touched along the way. Use when asked to "work the backlog", "complete the next most important issue", or to fix a specific issue number end-to-end.
Cut a versioned release of the DOS kernel — bump the version, draft release notes, commit, tag, push to master, and create a GitHub release. The tag push triggers the gated PyPI publish pipeline (publish.yml); the skill surfaces the run and its approval gate.
Promote an already-shipped rolling release (vX.Y.Z) of the DOS kernel to a named stable channel — gated on a green kernel suite + a green third-party CI run on the candidate + a clean truth syscall + a soak window. Writes an evidence file and adds a stable/<codename> git tag on the same commit. Does NOT bump versions or build new artifacts.
One automatic plan-class lifecycle tick. Reads the DECLARED class set + transition list from the workspace `[lifecycle]` table (not a hardcoded taxonomy), evaluates each trigger, spawns a read-only JUDGE-rung adjudicator (the `dos.judges` seam — advisory, fail-to-abstain) to approve/defer each candidate transition, applies the gated transitions as plan-meta edits + one commit per cycle, and logs to the run archive. Failsafes (per-cycle cap, per-plan cooldown, a veto class) are `[lifecycle]` data; the judge content is a host `dos.judges` driver. Every path/class comes from `dos doctor --json`. Use to garden a plan portfolio's lifecycle automatically, judge-gated. The DOS lifecycle gardener (SKP Axis 5, docs/207 Phase 5c).
Run /dos-dispatch on a recurring cadence, alternating with /dos-replan when the backlog drains — the dispatch→replan→dispatch cycle. The continue/stop/next-mode decision is the kernel's typed loop decision, not inline prose: each iteration is classified (`dos gate`) into a verdict and the loop's counters (drained-twice, the unclear/dirty-zero breakers, the iteration cap) drive the next step. Several loops on disjoint lanes run concurrently, each taking its own lane lease via `dos arbitrate`. Driven entirely by `dos` verbs + the workspace's `dos.toml`. The DOS reference loop workflow (SKP Axis 5).
End-to-end plan-and-ship for one lane — snapshot the portfolio with /dos-next-up, take a lane lease via `dos arbitrate` so parallel dispatches don't collide, gate the empty case via `dos gate`, ship the packet, and archive the run under the configured run dir. Driven entirely by `dos` verbs + the workspace's `dos.toml`; names no host path, lane, or commit convention. Use when you want to plan and ship the next batch on one lane in a single command, with concurrency safety. The DOS reference dispatch workflow (SKP Axis 5).
Ground a "keep working until the goal is met" stop condition in a witness the agent did not author, instead of letting the agent self-certify "done". A harness goal/Stop-hook condition is normally checked by the model re-reading its OWN work — consistency, not grounding. This skill turns the operator's goal into checkable EFFECT claims and wires `dos hook stop` so the Stop is refused until git ancestry (a shipped phase) or an effect read-back corroborates the claimed effect. Driven by `dos` verbs and the workspace's own `dos.toml` — no host-specific paths, lanes, or commit conventions. Use when you want a self-stopping agent (or a `/loop` worker) to be unable to declare a goal complete on its own say-so. The single-agent self-stop analogue of `dos-witness-claim`.