| name | next-task |
| description | Reads the tracker (GitHub Issues), picks the pinned/top open issue (or the issue the user names), and restates it as a concrete in-session work plan naming the files and crates involved. Use when the user asks "what's next" or "what should I work on".
|
| allowed-tools | ["Read","Grep","Glob","Bash"] |
| argument-hint | [issue number] (optional) |
/next-task
Turns an open tracker issue into an actionable plan — the planning step of
the issue workflow (CLAUDE.md). Does not do the work itself; that is a
separate step the caller takes after seeing the plan.
Steps
- Read the tracker:
gh issue list --state open (the SessionStart dump
annotates each issue with {k/n} sub-issue progress, child-of #parent,
and open BLOCKED-by/blocks edges) — take the pinned issue (current
focus) or the issue the user named. Respect relationships
(.claude/rules/issue-relationships.md): do NOT pick an issue shown
BLOCKED-by an open issue (surface its blocker as the real next task
instead); for a parent issue, point at its next open child rather than the
parent itself. Then gh issue view <n> --comments for the full contract
(## Contract + ## Exit criteria) and the running discussion, and
scripts/gh-rel.sh tree <n> for its parent/children/blockers. If the issue
links a plan file (docs/plans/*.md), read that too; its unchecked
(- [ ]) tasks are the queue.
- Turn the task into a plan, stating:
- What the task requires, in one or two sentences.
- Which files are involved — search for them (Grep/Glob under
crates/ and app/) rather than guessing paths; if the task names a
spec component, resolve it against docs/architecture.md (the crate map)
and docs/specs/openehr/README.md.
- Which mechanism applies:
openEHR spec/ITS layer (
openehr-base/openehr-rm/openehr-am/
openehr-its) → the code generator — change openehr-codegen's
emitter and regenerate (/regen-codegen).
Application (ehrbase/ehrbase-rest) → idiomatic
modern Rust of our own design on the generated crates, the openEHR
specs as the authority (EHRbase = prior art only). Build
compiling + tested. Note whether the task suits fanning out to an
implementer/ui-implementer subagent per the CLAUDE.md
Model-orchestration section (max 2 concurrent), or belongs in-session
(architecture, the AQL IR/codec core, spec-conformance judgement).
- Which spec sections govern it — for any spec-facing task, name the
docs/specs/openehr/... files (and CNF test-schedule chapters) the
implementation must be read against, per spec-adherence.md /
/spec-lookup. Doing the work starts by reading those.
- What "done" looks like for this task specifically — the issue's
## Exit criteria checklist, plus what proves it: the CNF pipeline's
zero-drift gate (docs/conformance/ehrbase-rs/results.json +
verdicts.json), the openehr-its fidelity gates, or corpus tests.
- Do not edit the issue or commit — recording progress happens after
the work is actually done, not as part of planning it.
