From b4eef33e7ec9b127cd12308888ecff582bb0a3a0 Mon Sep 17 00:00:00 2001 From: Jeroen Schweitzer Date: Mon, 8 Jun 2026 10:53:51 +0200 Subject: [PATCH] chore(skills): whats-next recommends clearing open PRs before new work Add step 1a: check open PRs first and recommend /pr-review (review -> merge) before selecting a batch. Open PRs are in-flight WIP; starting new work on top piles up the board, and the cascade-correct next batch is often dependency-gated on an in-review PR (won't show as --unblocked, or must stack on an unmerged branch). Renumber the existing 1a-1d substeps to 1b-1e. Co-Authored-By: Claude Opus 4.8 (1M context) --- .claude/skills/whats-next/SKILL.md | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/.claude/skills/whats-next/SKILL.md b/.claude/skills/whats-next/SKILL.md index 6e24c6057..444fc224d 100644 --- a/.claude/skills/whats-next/SKILL.md +++ b/.claude/skills/whats-next/SKILL.md @@ -17,7 +17,24 @@ batch selection → refinement review → batch activation. ## Step 1: Batch Selection -### 1a. List the ready work in the current phase +### 1a. Process open PRs before picking new work + +Before selecting a batch, check for open PRs: + +```bash +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 @@ -40,7 +57,7 @@ pql ticket list --under --unblocked # e.g. T-750 for Phase If this is empty, the phase is either complete or fully in progress — tell the user and stop. -### 1b. Rank and group +### 1c. Rank and group Rank the unblocked tickets by: 1. **Priority** (critical > high > medium > low) @@ -53,7 +70,7 @@ Group into **epic-sized batches**: tickets sharing the same parent (epic), via `pql ticket show --with-children` or `pql ticket list --under `. If no natural grouping exists, batch by the readiest related cluster. -### 1c. Show WIP status +### 1d. Show WIP status ```bash pql ticket list --status in_progress @@ -62,7 +79,7 @@ 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. -### 1d. Present the recommended batch +### 1e. Present the recommended batch Show the user: - The recommended batch (tickets with IDs, titles, priorities, phase label) @@ -153,7 +170,7 @@ pql ticket status T- in_progress ``` For each ticket in the batch (batch with commas: `pql ticket status T-1,T-2 in_progress`). -pql does **not** enforce the WIP limit — check it yourself in step 1c and warn if the +pql does **not** enforce the WIP limit — check it yourself in step 1d and warn if the batch pushes in-progress past 5. ### 3b. Create topic branch