git:20260924.e9e9cf4 to git:20260925.6dde440

- **READ-ONLY.** This skill answers; it never starts work, edits an issue, or "helpfully" begins the top item, and `qa` mode never closes one: the owner confirms a check in chat and the manager acts on it there. After answering, stop.

-

- A mode reply carries only the sections it names. The tally opens the full digest alone. Every rule below holds in all three.

- One query does it: `gh issue list --state open --json number,title,labels,assignees,blockedBy --limit 1000`.

- Answer in this shape, plain language, every item in the cold-reader line (`docs/project-state.md` § Restating an issue):

-

- 0. **The tally**: the digest OPENS with one count line: total open issues, then the count per `status:` label and per `type:` label (e.g. "12 open, status: 1 complete, 2 qa, 3 blocked, 4 specced, 2 backlog · type: 5 bugs, 6 enhancements, 1 idea").

- 1. **Ready to ship**: `status:complete` issues: checked, passed, waiting on nothing but the word "ship". One bullet each, and one closing line saying they all go in the next ship. They lead because they are the shortest path to an empty tree.

- 2. **Waiting on your check**: `status:qa` issues: built, verified, and parked in the working tree until your check passes them to `status:complete`. Report them as a WALKTHROUGH, not a list, and carry EVERY one of them. The check on a qa item is yours in whatever form it takes, so none is filtered out of the walk. The section OPENS with the literal command(s) in code spans (`npm run tower`, `npm start`, a URL. They come from each issue's check comment: `gh issue view <N> --comments`), then walks the items in the order that costs the fewest app switches: issues sharing one surface go together under the one boot command that covers the group, and the items no boot covers come last. Each item also names HOW to check it: SEE it (the screen or flow to open and what to look for), READ the evidence (the diff or the verification comment, named), or RUN it (the literal command in a code span). This is the section that asks the most of you: the tree holds their work, and nothing else finishes until they are checked.

- 3. **Waiting on you**: `status:blocked` issues. Name the actual question for each (it is in a comment: `gh issue view <N> --comments`).

- 5. **Up next**: `status:specced` issues, grouped into themed BATCHES of roughly 3–8 so the owner can authorize a batch at once. Group by dependency chains first, then by a shared seam or surface, then by the otherwise-alike; each batch carries one line of why-together, and an item that groups with nothing stands alone.

- Order the batches, and the items inside each: `priority:high` first, then unlabeled (= normal), then `priority:low`; within one priority, by dependency, risk, and reviewability: blockers first (work other issues wait on: the native relationship where it exists, which the `blockedBy` field above carries, with a parent's open siblings, an inline `Depends on:` line and anything another issue names in prose as the fallback signal; an edge onto a CLOSED issue is satisfied and orders nothing), then bugs, then shared seams (the file or module several queued items all touch), and only then dependent feature work. Say WHY the top batch is top in its why-together line ("first because #12 unblocks the other two"). This is the order the autonomy loop uses; the rule's home is `docs/project-state.md` § Queue semantics.

- 6. **Inbox**: the `status:inbox` count → offer the `workkit:triage` skill.

- 7. **The recommendation**: the digest ENDS with one explicit recommendation: the FIRST BATCH from section 5, or the single next item when nothing groups ("Start with #12, the auth bug, because #14 and #15 wait on it."). A batch is NEVER crammed into one sentence: each of its issues gets its own bullet carrying its outcome brief, and the why-together is its own closing line ("Why together: all three touch the auth flow, and #12 unblocks the other two."). One recommendation either way, never a second ranked list. Then stop.

-

- Also mention `.workkit/` if a lease/notes file says this session or developer is mid-work on an issue (`.workkit/` is per-developer session state, not shared truth).

- Omit empty sections. No jargon without a plain-words gloss. Note `agent:ok` where it exists. That item can be worked autonomously.

- 1. Read the roster: the `repos` map in `~/.workkit/.repos.json`, every entry whose value is not `"declined"`. Its keys are absolute PATHS, not slugs: resolve each to `owner/name` through its git remote (`git -C <path> remote get-url origin`) before any `gh issue list --repo <owner/name> ...`. (A machine missing these files: say so and answer from the cwd repo alone; the retired published-data recipe lives in git history: the state skill, since removed.) It is this machine's index; a repo it has never opened is not on it.

- 4. Flag unreachable repos (`(no remote)` / `(path missing)`) instead of skipping silently.

- - Generated on demand, never stored: no digest files.

- - Every issue is RESTATED wherever it appears, as an OUTCOME brief written in the cold-reader line; its shape, its cap and its example pair have one home, `docs/project-state.md` § Restating an issue, and this skill carries none of its own.

- - The reply IS the deliverable: end with the last section the mode carries (the recommendation, in the full digest and `build`) and STOP, never the AskUserQuestion tool (the frontmatter removes it). The owner picks in chat, and the manager acts on that word; this skill never edits an issue or writes a file.

- - Offline or no `gh`: say so plainly, then report from `.workkit/` alone, never guess at the queue.

- - If nothing is in flight and nothing is blocked, say what is top of the queue and that it needs a go-ahead.