Orient Roadmap

/orient-roadmap

> What comes next, and what gates it? > Answers with — the increment arc (built → current → next) · what ships now · the gates · the next clusters · the runway. > Does not answer — how far along (/orient-status) · what changed (/orient-map) · what is stuck (/orient-gaps). > Owns for the family — the horizon fields: arc_current, arc_idx/arc_count, paramount_ref, runway_span, deferred_count.

Computes a fresh, honest read of where the work is going — the increment arc (built → current → next), what is shipping now, the gates, the next increment's clusters (the paramount one starred), and the runway of stage boxes (now → gated-next → future) plus the deferred lanes — and returns it as one ephemeral bundle (a structured YON record + a human markdown read + a small visual). It is the orient- family's forward-horizon lens: where /orient-map looks back (delta + topology) and /orient-status reports the node you stand on, orient-roadmap looks ahead across multiple horizons. Emits the roadmap slice of the shared record at [references/orient-spec/orient-record.yon](references/orient-spec/orient-record.yon).

> Structured execution spec: [protocol.yon](protocol.yon). Read it for the canonical steps, rules, and gates; this file is the human-readable, self-sufficient explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

The shared record, render contract, worked fixtures, and value validator travel inside [references/](references/). The repository-only round-trip guard is release evidence; its absence from an installed copy does not block execution.

When to use

• "Show me the roadmap / the runway / what's next" on a project, repo, plan, or task — you want the forward horizons, not the node you're on.
• "What are the increments and the lanes" — you want the built → current → next arc, the next increment's clusters, and the runway of gated stages laid out as one board.
• "What's the plan from here" — the prospective board (increments not yet reached, the runway of gated stages, the deferred lanes), not the retrospective delta.

How it works (self-sufficient — works without protocol.yon)

orient-roadmap delegates the gathering to a bounded, read-only subagent so the calling session (a human's, or an agent orienting itself) never sees the search/inference noise — only the result bundle comes back. Nothing is stored; every call recomputes from current reality. It is horizon-first: the forward increments and the runway lead; the retrospective delta is /orient-map's job, not this one's.

1. Take the north-star / intent and the last-look anchor as inputs, never prompt for them. Intent (the goal / what the arc is aiming at) gates the whole board: if intent can't be grounded, render what exists but cap every intent-dependent horizon to guessed and never emit a confident runway from the void. The anchor (a git ref, a PLAN.md, a HEAD@time) is caller-supplied or git-inferred, never written to disk. Never fabricate a north-star or an anchor.

1. Spawn one bounded subagent (read-only, depth-1, single wave; budget ≤ ~8–12 tool calls, hard timeout ~60–90s, stop at the first evidence tier that gives a confident answer). It runs the cheap-first evidence ladder and returns this signal (not raw logs):

• git tier → the commit subjects / merged work = the built items (✅ now-shipping chips), the current branch/frontier = the current increment.
• plan/doc tier → from a PLAN.md/roadmap/checklist: the increment arc (built → current → next), the gates, the next increment's clusters (which is the paramount one), the runway stages (now → gated-next → future), and the deferred lanes.
• conversation/folder tier → an un-plan'd next step; file mtimes for the live frontier; the folder name.

Every attested item/increment comes back with a re-runnable source:line/git-ref proof.

1. Build the roadmap slice — this skill is the forward-horizon authority (siblings read arc_current / paramount_ref, none recompute the horizons). The increment arc is a 3-node spine (@CFG id=node., kind=increment, one istatus=current — the hero). Hold it to ≤ 3 arc nodes and ≤ 3 runway stages (the ≤5-node budget per sub-graph, [orient-contract.md](references/orient-spec/orient-contract.md) §3.2): if a live emission exceeds that, decompose into an overview arc + a drill-down runway rather than cramming. Set arc_current, arc_idx/arc_count, now_count, next_count, runway_span, paramount_ref, cleanup_now_count, deferred_count.

1. Encode the two orthogonal axes without conflating them. The tier axis (provenance confidence) is ◆ attested · ◐ inferred · ◌ guessed — the a11y non-color glyphs on every field. The state/role axis (roadmap semantics) is the handler emoji in the markdown/ASCII face — ✅ built · ◉ current · 🔄 running · ★ paramount · ▢ next-gated · ◌ deferred · ⚠ promoted-cleanup. **★ is a paramount role marker on a next-item chip, never a tier glyph** (the handler-ratified ★ tier lives only in the trust trailer, a different render zone). The SVG widget face translates the emoji column to shape-glyphs + shape encoding (filled/hollow/dashed) — no emoji in the widget.

1. Tag every field with a provenance tier — ◆ git-attested · ◐ inferred · ◌ guessed — and fail closed: set gate_status (enum: ready | blocked | stalled | degraded | indeterminate) to degraded or indeterminate with a sentinel value — never a plausible verdict and never a bare 0/false — on barren evidence. A no-substrate subject draws a NO SUBSTRATE card, not a structural roadmap.

1. Emit the bundle to the consumer that asked — one record, three faces, never all three at one reader. The YON record is the AGENT face and goes to an agent consumer only; a human gets the plain-language read plus the visual (widget when available, ASCII twin otherwise) and never sees the record, a raw record field, a node-id, or a gate enum. See Record emission below for the YON face (agent-only); the markdown read follows the worked example; the visual face is rendered per the [render-face contract](references/orient-spec/family-behaviors.md) (Claude Code only): for a human on Claude Code with the visualize tool present on an explicit invocation, build the roadmap widget from the kit — call mcp__visualize__read_me once, then emit via mcp__visualize__show_widget a hand-SVG 8-band board (viewBox="0 0 780 …", each band an independent ` so coordinate math stays local), the current increment the dominant node, ◆◐◌ tier glyphs as redundant (non-color) encoding, deferred chips dashed + faded, **no emoji in the widget face**; an **agent** consumer gets the YON record only; any **other runtime / no tool / indeterminate handler_type** gets the ASCII twin (fail-closed). The **information-complete ASCII roadmap twin is always emitted** — it is the only render in a no-SVG channel and carries every increment, item, gate, stage, and lane the widget does (worked trio at [references/orient-spec/examples/orient-roadmap.{ascii.txt,widget.svg}](references/orient-spec/examples/)). The footer is one evidence-derived line — and **only ever suggests a skill that is actually installed** (fall back to a plain prose hint or /orient-status//plan-create otherwise). The footer's four faces, the **staleness short-circuit** (anchor unchanged → "no change" without a full sweep), the neutral re-look signal, and handoff-feeder routing follow the shared [references/orient-spec/family-behaviors.md`](references/orient-spec/family-behaviors.md).

Record emission (the YON face — AGENT consumers only; never printed to a human)

The structured face is the roadmap slice of [references/orient-spec/orient-record.yon](references/orient-spec/orient-record.yon) (schema_version = orient-record/1). Reserved tags only — custom tags like @ROADMAP/@RUNWAY are parser-rejected. Increment nodes are @CFG id=node. (kind=increment); every list field (built_items, gates, next_items, runway_stages, cleanup_now, deferred, edges) goes in a sidecar @MAP, never an in-set bracket-list (an in-set bracket-list corrupts the record silently and still validates). ★ (paramount) and ◌ (deferred) ride inside the item label as render hints, never as new tier glyphs. Never run yon format on an emitted instance — CANON mode is destructive on set-internal lists. Validate with --profile exec then the value gate references/tools/orient-validate.mjs. Minimal skeleton:

@CFG id=orient | set=[schema_version=orient-record/1,computed_at:ts=…,ephemeral:bool=true,tool=orient-roadmap,tier=orient,scope=…,evidence_mode=git-only,gate_status=ready,gate_confidence_floor=inferred,family_used=orient-roadmap,family_suggested_next=orient-status,family_reason_code=lost_thread,overall_trust=med,degraded:bool=false]
@CFG id=subject | set=[name=…,kind=monorepo,purpose=…,purpose_source=readme,intent_status=stated,parent_subject=…]
@CFG id=roadmap | set=[north_star=…,arc_current=…,arc_idx:int=2,arc_count:int=3,now_count:int=4,next_count:int=3,runway_span=…,paramount_ref=…,cleanup_now_count:int=1,deferred_count:int=2]
@CFG id=node.a1 | set=[kind=increment,label=…,istatus=built,lane=arc]
@CFG id=node.a2 | set=[kind=increment,label=…,istatus=current,lane=arc]
@CFG id=node.a3 | set=[kind=increment,label=…,istatus=next,lane=arc]
@MAP name=edges | pairs=["a1"->"a2","a2"->"a3"]
@MAP name=built_items | pairs=["b1"->"…","b2"->"…"]
@MAP name=gates | pairs=["g1"->"…","g2"->"…"]
@MAP name=next_items | pairs=["x1"->"★ …","x2"->"…"]
@MAP name=runway_stages | pairs=["r1"->"now: …","r2"->"gated-next: …","r3"->"future: …"]
@MAP name=cleanup_now | pairs=["u1"->"⚠ …"]
@MAP name=deferred | pairs=["d1"->"◌ …(deferred)"]
@MAP name=provenance | pairs=["roadmap.arc_current"->"artifact-stated:med:plan-md","roadmap.built_items"->"git-attested:high:git-log"]

On barren evidence the envelope degrades honestly and carries the reason: gate_status=indeterminate, degraded:bool=true, degrade_reason="no git, no plan" — and the visual is the NO SUBSTRATE card, never a structural roadmap. A full worked instance ships at [references/orient-spec/examples/orient-roadmap.example.yon](references/orient-spec/examples/orient-roadmap.example.yon).

Output — worked examples (markdown face)

The horizon board (the case orient-roadmap exists for):

🧭 open-skills — public skills pack, the roadmap.   ↳ in: open-source push   [identity: ◆ git]
North star: one orient- family, three faces, machine-checked.

THE ARC:   ✅ status ──▶ ◉ map+gaps (current) ──▶ ▢ roadmap (next)     ◆ plan spine
NOW SHIPPING:
  ✅ orient-status   ✅ orient-map   ✅ orient-gaps   ✅ value-gate     ◆ git log
GATES:   [ full validate green ]   [ cold-review pass ]               ◆ CI
NEXT INCREMENT:
  ★ roadmap slice   widget parity   ascii floor                       ◐ plan
THE RUNWAY:   now:author ──▶ gated-next:cold-review ──▶ future:publish ◐ plan
CLEANUP-NOW:   ⚠ stale STAMP dates
DEFERRED:      ◌ deterministic renderer(deferred)   ◌ ci wiring(deferred)   ◌ unchanged
**→ Next:** map+gaps is the current increment; the roadmap slice is paramount.
Trust: ◆◐◌ · ⚠️ lean here: the runway "future: publish" stage (inferred from the plan, not a gate) · next → /orient-status
legend: ◆ attested · ◐ inferred · ◌ guessed · ✅ built · ◉ current · 🔄 running · ★ paramount · ▢ next/gated · ◌ deferred · ⚠ promoted-cleanup

Barren / no-substrate (honest degradation is the success case):

🧭 ToDo — a folder (no git, no plan).                      [identity: ◌ guessed]
┌───────────────────────────────┐
│  NO SUBSTRATE                  │   no commits, no plan — no horizons to draw.
│  can't draw a roadmap.         │
└───────────────────────────────┘
**→ Next:** init git or name the north-star, and the horizons become visible.
Trust: ◌◌◌ · ⚠️ lean here: every line — no durable roadmap exists.  [gate: indeterminate · degrade_reason: no git, no plan]

The ASCII roadmap + the trust trailer with the ⚠️ lean your scrutiny here line (naming the single load-bearing guess) and the one-line legend is mandatory on every output; deferred items keep the (deferred) word so the widget's dashed chips have a text twin.

Boundaries

• Not /orient-status — that reports position + remaining + a banded ETA on the ONE node you stand on; orient-roadmap reports the forward horizons and the runway (the increment arc, the next clusters, the stage lanes). They share one sweep; orient-roadmap owns the horizon board, orient-status owns position + ETA on the current increment.
• Not /orient-map — that reports topology + the delta since your last look (done → here → next, a tree on a branch, capped at ≤5 nodes); orient-roadmap reports where the work is GOING (increments not yet reached, the runway of gated stages, the deferred lanes). orient-map is retrospective/delta; orient-roadmap is prospective/multi-horizon.
• Not /plan-create or /plan-deep-dive — those DESIGN or WALK a plan; orient-roadmap only SEES and reports the current roadmap NOW against whatever evidence exists (often no formal plan).
• Not /reflect, not insight-* — those THINK / DECIDE; orient-roadmap only SEES and reports the horizons NOW. After it, reach for /orient-status for the ETA on the current increment, or /plan-create to act on the next horizon.
• Read-only. It never mutates state; the north-star/intent and the anchor are caller-supplied or inferred, never written to disk by default.

Rules

• MUST be horizon-first — lead with the forward increments and the runway; the retrospective delta belongs to /orient-map, not here.
• MUST render the increment arc as a ≤3-node spine (one current, the hero) and the runway as ≤3 stage boxes (now → gated-next → future); if a live emission exceeds that, decompose into an overview arc + a drill-down runway rather than cram (the ≤5-node-per-sub-graph budget).
• MUST own and emit the horizon fields (arc_current, arc_idx/arc_count, paramount_ref, now_count, next_count, runway_span, cleanup_now_count, deferred_count) so sibling slices don't recompute the horizons.
• MUST keep the tier axis (◆◐◌, provenance) and the state/role axis (the handler emoji ✅◉🔄★▢◌⚠) separate — ★ is a paramount role marker on a next-item chip, NEVER a tier glyph; the handler-ratified ★ tier rides only the trust trailer.
• MUST take intent / the north-star as input and gate intent-dependent horizons when it's absent — never fabricate a north-star; below a grounding threshold draw a NO SUBSTRATE card, not a structural roadmap.
• MUST tag every field with a provenance tier and fail closed — gate_status = degraded/indeterminate with a sentinel, never a plausible verdict — on zero evidence.
• MUST, when the consumer is an agent (handler_type = agent), emit a record conformant to references/orient-spec/orient-record.yon (reserved tags; increment nodes as @CFG id=node. kind=increment; list fields as sidecar @MAP; ★/◌ as in-label render hints only; never yon format an instance). A human consumer gets the plain-language read plus the visual instead — never the record, a raw record field, a node-id, or a gate enum.
• MUST emit the ASCII roadmap + the trust trailer with the ⚠️ lean here load-bearing-guess line + the one-line legend; deferred items keep the (deferred) word so the widget's dashed chips have a text twin; the visual's ASCII twin is mandatory.
• MUST NOT print the YON record — or any raw record field, node-id, gate enum, @CFG line, or @MAP line — into a human-facing reply.

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: allemaar
• Source: allemaar/open-skills
• License: Apache-2.0
• Homepage: https://allemaar.com

Install and usage instructions live in the source repository linked above.