settled-reach/.claude/skills/whats-next/SKILL.md

name, description, user-invocable, allowed-tools

name	description	user-invocable	allowed-tools
whats-next	Analyze the ticket dependency graph and surface the best batch of tickets to pick up next. Refines ticket context via parallel Si agents before activation. Use when the user says "what's next", "next batch", "pick up work", or invokes /whats-next. NOT triggered by "what should we work on" in a design context — that's a discussion, not a batch selection.	true	Bash, Read, Grep, Glob, Agent, AskUserQuestion

What's Next

Dependency-driven batch selection with ticket refinement. Three steps: batch selection → refinement review → batch activation.

Step 1: Batch Selection

1a. Process open PRs before picking new work

Before selecting a batch, check for open PRs:

tea pr list --login schweitz --repo jpmschweitzer/settled-reach --state open --output simple

Open PRs are in-flight WIP. Starting a new batch on top of them piles up the board, and — worse — if the cascade-correct next batch depends on a PR still in review, its downstream work is dependency-gated: it won't appear as --unblocked (blockers aren't done), or it has to stack on an unmerged branch. If any PRs are open, recommend clearing them first with /pr-review (review → merge) before selecting new work. List the open PRs and your recommendation, then let the user decide whether to clear them first or proceed in parallel with independent work that doesn't depend on the in-review branches.

1b. List the ready work in the current phase

Phase gating is the cascade hierarchy, not a label or milestone entity. The initiative T-745 (Development Cascade) holds the six phases as epics under it; a ticket belongs to a phase by being parented under that phase epic (self-maintaining — no label to apply or forget). Find the active phase epic (status in_progress under T-745; the cascade is strictly sequential per D-166, so equivalently the lowest-numbered non-done phase epic):

pql ticket list --under T-745 --status in_progress --fields id,type,status,title

--status takes a SINGLE value (not a comma list — backlog,in_progress matches nothing and silently returns []). Most tickets here sit in backlog or done; if you need multiple statuses at once (e.g. both backlog and in_progress), run the query once per status.

The phase epic is the "type": "epic" row. Use pql natively — no ad-hoc python/jq projections over its output: since pql 1.11.0, ticket list omits description by default and supports --fields id,type,parent_id,priority,status,title (the batch- selection projection) and --oneline; --full opts back into whole rows when you genuinely need bodies.

Then list its ready subtree — --under gathers the whole phase, --unblocked does the dependency walk (only tickets whose blockers are all done/cancelled):

pql ticket list --under <active-phase-epic> --unblocked \
  --fields id,type,parent_id,priority,status,title   # e.g. T-750 for Phase 4

If this is empty, the phase is either complete or fully in progress — tell the user and stop.

1c. Rank and group

Rank the unblocked tickets by:

1. Priority (critical > high > medium > low)
2. Fan-out — tickets that unblock the most downstream work rank higher. pql has no fan-out field yet; when it matters, gauge it from the dependency graph (pql ticket list --under <epic>, or scan candidates' blockers), or judge by epic membership.

Group into epic-sized batches: tickets sharing the same parent (epic), via pql ticket show <epic> --with-children or pql ticket list --under <epic>. If no natural grouping exists, batch by the readiest related cluster.

1d. Show WIP status

pql ticket list --status in_progress

The kanban WIP soft-limit is 5; pql does not enforce it — warn if activating the batch would push in-progress past 5.

1e. Present the recommended batch

Show the user:

• The recommended batch (tickets with IDs, titles, priorities, phase label)
• Why this batch (what it advances, what downstream tickets it unblocks)
• Current WIP status
• Any alternative batches worth considering

Wait for user confirmation before proceeding to Step 2.

---

Step 2: Ticket Refinement Review

Spawn one Si agent per ticket in the confirmed batch, running in parallel. Use general-purpose subagent_type with Si's personality baked into the prompt. (The si subagent_type now works directly too — all agent definitions carry the team coordination tools, SendMessage + Task, as of the agent-teams tooling fix; they load at lead startup.)

For each ticket, spawn:

Agent({
  subagent_type: "general-purpose",
  model: "sonnet",
  prompt: "You are SI, the Refinement Manager. <include si.md personality>

  Review ticket #<id>: <title>
  Description: <description>
  Decision ref: <decision_ref>

  Your job:
  1. Read the ticket's decision_ref D/Q-record in governance/**/*.md
  2. Grep for related Q-records in governance/questions/*.md
  3. Read workshop outcomes if referenced (check docs/workshops/)
  4. Check whether referenced code, tables, or files actually exist

  Assess: does this ticket have enough context for an agent to implement
  without guessing? Report exactly one of:
  - READY: <one-paragraph summary of what the implementer needs to know>
  - GAPS: <list of specific ambiguities with options for each>"
})

2a. Collect reports

Wait for all Si agents to complete. Collect their reports.

2b. Resolve gaps

For any ticket that came back GAPS, surface each ambiguity to the user via AskUserQuestion:

Ticket #NNN: