/next-steps

name: next-steps
description: >
  Have the Product Owner survey the project's current state — shipped
  features, in-flight work, open findings, standing goals — and propose one
  concrete next feature ready to hand to /story-time or /spark. Use when the
  user has no idea in hand and asks "what should we build next", when a loop
  just closed and the next cycle needs a starting point, or when the backlog
  feels stale and needs a grounded suggestion instead of a guess.

/next-steps — Propose the Next Feature (Product Owner)

You are running an **advisory** ceremony, not a gated one. The Product Owner looks at where the project actually stands and proposes what to build next — the user picks, tweaks, or discards it. Nothing here gets written to `.spark/` and nothing needs approval; the output is a recommendation to carry into `/story-time` or `/spark`.

Input

None required. Optionally the user may point at a theme or constraint (e.g. "something small", "focus on the API") — pass it through to the agent as a steer, not a fixed answer.

Steps

1. **Gather the loop state yourself — don't delegate this.** The `product-owner` agent cannot run `git` or walk `.spark/`. Collect a brief before invoking it:

• `git log --oneline -20` (and further back if the project is young) for

what actually shipped and when.

• Every `.spark/<feature-name>/` directory: for `spec.md`, `plan.md`,

`review.md`, `qa.md` where present, read each artifact's **Handoff** block first — a bounded read, not the whole file. Status, Summary/ Verdict and Open items are enough to classify the feature as **shipped** (released), **shipped-pending-approval** (`handed-off` — closed for this team, never resumed), **in-flight** (mid-loop, no open blocking findings), or **stalled** (open review/QA findings, or untouched for a while).

• Any *unresolved* findings sitting in the newest `review.md` or `qa.md` —

these are open points, not just status flags. The block's Open field already names the Blocker/Major IDs; read the specific finding's row in §3 Findings only for the ones you need described in the brief, not the whole report.

• `.spark/constitution.md` if it exists — its Product Principles and

Project Profile sections are the standing goals a proposal should serve.

• **If `.spark/constitution.md` doesn't exist**, recommend `/charter` first

— before proposing anything — and continue to step 2 only on the user's explicit skip; never invoke `/charter` yourself. This holds whether the repo is empty or already has shipped history: a codebase without a constitution has as much reason to start there as an empty one. On an empty `.spark/` with trivial git history and no constitution, still name `/charter` rather than only saying "there's nothing to propose from" — the honest move used to be asking the user for an idea outright; now it's pointing at the ceremony built for exactly that gap.

• If nothing exists yet in `.spark/` and git history is empty or trivial,

say so plainly — there is no "state" to read yet — and ask the user for the first idea rather than fabricate one. This is unrelated to whether `/charter` was offered or skipped — bullet 1 above already sends a skip straight to step 2, with whatever brief step 1 could gather; this bullet only covers the separate case where that brief would be empty regardless. **A repo where a constitution already exists is untouched by either bullet above and falls straight through to step 2**, exactly as it did before this feature — the Product Owner's own propose-mode rule already asks for missing context when the brief is too thin (see its `## Proposing the Next Feature` step 6), so nothing here needs to intercept that case.

• **Ticket system (best effort).** Try `gh issue list --state all --json

number,title,state,labels,milestone,body,closedAt --limit 200` (or `glab issue list`, or a ticket MCP) and `gh pr list --state all --json number,title,state,body,mergedAt,headRefName --limit 200`. Capture labels, "blocked by" / "depends on" / "#N" references, milestones and linked PRs. If no tool works, note once for the closing report: "Could not see the tickets" (one line by design, aSPARK issue #110: a deliberate exception to aSPARK's own silent-fallback rule, waived by its maintainer) — then **skip the maturity ticket count, triage and gap bullets below** (no issue list means every function would look like a gap) and behave as before this feature.

• **Project maturity.** Classify as **greenfield** (a constitution exists,

little or no code, few or no tickets), **building** or **mature**, from `git ls-files` size, `git log` depth, `.spark/` history and ticket count. State the class and the evidence for it in the brief.

• **Ticket triage.** From the open issues: drop any whose linked PR is

merged (report as "done, close it" — never recommend it, never close it yourself, AC-4). An open issue is *ready* when everything it is blocked by / depends on is closed. Among ready issues prefer the one that unblocks others and fits the current phase. A blocked issue is never the pick while its blocker is open: the blocker is (AC-2).

• **Ticket gaps.** Compare the constitution (Product Principles, §9,

quality bars, active lenses), `ROADMAP.md` and `.spark/` specs with the open *and closed* issues. A function described there that no issue covers is a gap; a function an open issue covers is not (AC-3). Each gap carries its source, e.g. `constitution.md §3`. 2. **Delegate to the Product Owner.** Pick the model first: if `.spark/constitution.md` §11 names a model for `product-owner`, pass exactly that as the agent call's `model`; if it names none, or there is no constitution or no §11, pass no m