Skip to content
Agent Orchestration
Skill

/next

Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project. Triggers — "/engineer.next", "what's next", "what should I work on", "what should I do next", "where do I pick up".

BOOST
From plugin
atdd
15928 skills8 agents4 commands2 hooks
Install
$ npx -y skills add swingerman/engineer --skill next --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/next

Context preview

The summary Claude sees to decide when to auto-load this skill.

Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project. Triggers — "/engineer.next", "what's next", "what should I work on", "what should I do next", "where do I pick up".

SKILL.md

next.SKILL.md
name: next
description: Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project. Triggers — "/engineer.next", "what's next", "what should I work on", "what should I do next", "where do I pick up".

next

The session-start skill — the human's re-entry point. Surveys every source of DAE state and answers one question: **what should I pick up now?**

Read-only and advisory. It changes nothing, produces no artifact, and emits **no handoff** (the recommendation is the whole output; a handoff would just restate it). This is a deliberate exception to the agentic-summary contract — `next` is a query, not a task that changes state.

`next` is the read-side bookend to `session-summary`: `session-summary` writes "here's where I left off, next tasks" at session end; `next` consumes that — and everything else — at session start.

When to use

Start of a session, or any "what now?" moment. Project-scope; surveys the whole project — there is no narrower scope.

**Not for:** loading context on a feature you've already chosen (`prime-context`); checking artifact consistency (`consistency-check`); a per-feature next-step (each skill's handoff already carries `recommended_next`).

Workflow

Step 1 — Resolve and survey

Resolve the methodology root + manifest via `${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py` (see `references/resolving.md`). Then read, read-only:

  • **In-flight features** — every `features/*/feature.md` (status) + `progress.md` (current checkpoint; whether it's blocked or ready to advance). For each in-flight feature, run `${CLAUDE_PLUGIN_ROOT}/scripts/dae_reconcile.py <feature-dir>` (read-only): if it reports `needs_reconcile: true`, the feature's PR is merged but its local state hasn't caught up — this is the authoritative merged-detection (via `gh`, so it catches **squash-merge and `git.manual`**, which the current-branch git-ancestry check below misses). Surface these under NEEDS YOUR DECISION and, at autonomy `medium`/`high`, offer `/engineer.post-merge` to reconcile (which flips the status and propagates). A `flag: merged-unverified` means it shipped without CP7 — call that out.
  • **Consolidation backlog** — `.engineer/consolidation.md` if present (coverage backlog + triage order)
  • **Roadmap (strategic feature list)** — the next *unstarted* roadmap item(s) via the driver (`local` = `${CLAUDE_PLUGIN_ROOT}/scripts/dae_roadmap.py next-unstarted`; MCP/CLI/API-backed = the connected channel — see `references/roadmap.md`). This is the **"what's next in the roadmap"** altitude — candidate features not yet promoted to a feature folder, the forward-looking complement to the consolidation backlog. If `manifest.roadmap.type` is `none`, or its host is unreachable (MCP disconnected / CLI gone), **skip it with a one-line note** — degrade gracefully, never error.
  • **Parked ideas** — `features/*/` with `status: parked`; `.engineer/discussions.log`
  • **Tracker captures (triage queue)** — tasks a human added *directly to the onboarded tracker*: rows with no `Slug` yet (the `reconcile()` orphan-as-intake case, see `references/tracker.md`), or `.engineer/inbox.md` lines in local mode. These are quick-captured bugs/ideas/tasks awaiting triage — not yet a feature or fix.
  • **Pending human actions** — recent `handoffs/*.md` (per-feature and `.engineer/handoffs/`) flagged `human_action_needed: yes`
  • **Session-log next-tasks** — the latest `session-log.md` entry per active feature ("Next tasks")
  • **Dispatched to cloud** — features whose latest handoff carries `cloud_session_url` (running on a cloud agent; PR pending). Surface as DISPATCHED — not actionable until the PR lands.
  • **CHARTER.md + manifest** — autonomy levels and path overrides, for execution-mode advice
  • **Open fixes** — `.engineer/fixes/*.md` via `${CLAUDE_PLUGIN_ROOT}/scripts/dae_fix.py list_open_fixes` (status != closed)
  • **Stale merged branch** — if the current branch is not `main`/`master`, run `git fetch origin --quiet` then check `git merge-base --is-ancestor HEAD origin/HEAD` (fallback `origin/main`). If true, the branch is merged and lingering — surface it as a STALE BRANCH item. (This git check only catches the *current* branch and only non-squash merges; the per-feature `dae_reconcile.py` probe above is the broader, `gh`-based merged-detection.)

Step 1.5 — Offer branch cleanup (if stale)

If a stale merged branch was detected, defer to the `post-merge` skill — it owns the full cleanup flow (checkout, pull, branch -d, prune, tracker update). At autonomy `high`/`medium`, auto-invoke `/engineer.post-merge` before continuing to Step 2. At `low`, surface the finding and stop until the user invokes it themselves. Do not inline the cleanup commands here — keep `next` advisory and let the dedicated skill do the work, so the post-merge handoff lands in the audit trail.

Step 2 — Triage into eight buckets

NEEDS YOUR DECISION   — blocked features; handoffs flagged human_action_needed.
                        These stall progress — surface them first.
OPEN FIXES            — bug-fix artifacts not yet closed. Sub-priority within the bucket:
                         1. blocks_user: true AND workaround: none      ← top (user is hit right now)
                         2. blocks_user: true AND workaround: <text>    ← middle (user has a workaround)
                         3. blocks_user: false                          ← bottom
                         Within each tier, order by severity (critical, high, medium, low).
READY TO ADVANCE      — in-flight features sitting at a checkpoint that can proceed.
READY TO DISPATCH     — features / consolidation tasks that can go to a cloud agent
                        right now (bounded, automatable verification, no mid-stream
                        human input needed). At medium/high autonomy the dispatch
                        router auto-sends these (gated by dae_delegable.py).
DISPATCHED            — already
Read more
Ships withatdd

A methodology kit for engineering-led AI development — spec-driven, test-driven, charter-bound. ATDD + mutation testing + deterministic guardrails. AI agents do the typing. Engineers stay in charge of architecture, behavior contracts, and verification.

Get the whole plugin

Other skills on atdd.