---
description: Show the open issues relevant to the current repo's configured tracker, on demand. Pull-only — ONLY use when the user explicitly asks what's on the backlog / what's next; never inject issue state into a session unasked. Invoked by `/os-backlog:list`.
---

Show the current repo's tracker state when — and only when — the user asks for it.

## Pull-only rule (notification policy v2)

This skill is strictly pull-based. **Never volunteer issue state**: not at session start,
not after a capture, not "while you're here". The only trigger is an explicit user request
("what's on the backlog?", "/os-backlog:list", "what's next?").

## Procedure

1. List the open issues on the cwd repo's configured tracker:
   ```bash
   ${CLAUDE_PLUGIN_ROOT}/bin/os-backlog issues
   ```
   This returns open issues (number, title, labels, assignee) grouped by state: `next` /
   `waiting` / `review` / other open.
2. Relay the listing compactly, `next`-labeled issues first, then `waiting`, then `review`,
   then the rest. If the user asked a narrower question ("what's in review?"), answer only
   that.

## While discussing listed issues

Listing is read-only — this skill never changes issue state itself. If the user asks you to
start work from the list:
- `hitl`-labeled issues are off-limits — never picked up by the AI; flag them back to the
  human instead.
- Comment on the issue when work starts; if it blocks, add the `waiting` label plus a
  comment naming the blocker (see `/os-backlog:capture`'s home hook note for the full
  working-state contract).
- Never touch the `next` label — human-curated in both directions, always.

## No tracker configured

If `issues` fails because the project has no `tracker` key in `.cc-os/config`, suggest
`/os-backlog:route` once and stop — there's nothing to list.

## Failure behavior

Fail soft: if the CLI or the underlying tracker (`tea`/`gh`) is unreachable, it prints one
clear error and exits nonzero — relay it and stop. Never fabricate issue state.