process: an orientation ask is session entry — answer it from the store queue

[jussi-modernpath]

A session was asked "what should I do next?" in a store-backed workspace with 140 items in its queue — 29 awaiting a decision, 19 ready to build, 92 built and awaiting acceptance — and answered from git status and the open-PR list instead. It recommended merging a green PR and repairing some broken check scripts: true, useful, and not one of the 140 things the loop was asking for.

The behaviour was already specified. rdd-start preflight lists the pending human decisions; taking the scope presents the routed queue. Nothing made a session reach any of it when the question arrived as a question.

Two commits, because the first one alone was circular

AGENTS.md — the entry condition (commit 2). Required reading gated on four verbs: planning, changing, reviewing, delivering. Being asked what to do next is none of them, so required reading never triggered and the queue went unread. This file is the one an agent has before it has decided anything; the skill is read only once something routes to it. Widening only the skill would have left the failure intact for exactly the session that never opened the skill — the session the change is for.

Now the gate names the orientation asks alongside the four verbs, and a closing paragraph states where the answer comes from: the store's pending human decisions and routed work, through rdd-start. Version control, change lists and the working tree describe the repository rather than the loop, and never answer the question.

skills/rdd-start/SKILL.md — the procedure (commit 1):

• description — triggers on the orientation forms, not just start/continue/pick up.
• Preflight — a host-delivered session-start brief is the store's own answer arriving early, not ambient background; date it against the store revision before relying on it, and report an undatable projection as unknown. Not hypothetical: in the session that prompted this, the cached queue answered happily while the live read refused with an expired token, so a stale projection presented itself as current with no marker.
• Take the scope — covers the request that is an orientation question rather than a scope, and repeats the version-control negative where the queue is actually presented.
• Take the scope — rank by what a single human answer releases (an OPEN gate holding built IN_REVIEW work outranks unstarted work; a gate holding many outranks one holding few), and state the awaiting-decision / ready / awaiting-acceptance distribution. A 92-vs-19 split says acceptance is the bottleneck — a finding, not a list.
• Report — process and tooling work carrying no requirement record is labelled as such and never substitutes for the queue. It was not wrong to surface it; it was wrong to surface it instead.

Host-agnostic boundary

The package must not name one CLI's commands, so it does not. Instead, naming the concrete read is now an obligation on the consuming project's root AGENTS.md, and an omission is reportable rather than silently absorbed — which is what let this gap sit unnoticed.

Verification

Both commits are installed and running in a real consuming workspace: snapshot synced to 32d1abe, CLI rebuilt, install --check clean, and the host re-read the skill mid-session with the new triggers live. The end-to-end test — a fresh session answering "what should I do next" from the store rather than from git status — needs a session that has not already read the diagnosis.

🤖 Generated with Claude Code

https://claude.ai/code/session_0115VUeQov83Qf7tipMR5S3V