# Dart Next

> DART Next: choose the next bounded DART task from plans, issues, and CI, then route it

- Skill: `dartsim/dart-next` (Agent Skill)
- Install (CLI): `npx skillmds@latest add dartsim/dart-next`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dartsim/dart-next/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: dartsim (https://skillmd.com/u/dartsim)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dartsim/dart-next

---


<!-- AUTO-GENERATED FILE - DO NOT EDIT MANUALLY -->
<!-- Source: .claude/commands/dart-next.md -->
<!-- Sync script: scripts/sync_ai_commands.py -->
<!-- Run `pixi run sync-ai-commands` to update -->

# dart-next

Use this skill in Codex to run the DART `dart-next` workflow. The editable
workflow source lives in `.claude/commands/`; this file is its generated adapter
in the shared `.agents/skills/` catalog.

## Invocation

- Claude Code: `/dart-next <arguments>`
- Codex: `$dart-next <arguments>`

Treat the text after the skill name as `$ARGUMENTS`. When the workflow
references `$1`, `$2`, etc., map those to the positional values supplied by the
user.

## Command Body

Select and execute the next bounded DART task: $ARGUMENTS

## Required Reading

@AGENTS.md
@docs/ai/principles.md
@docs/ai/north-star.md
@docs/ai/workflows.md
@docs/ai/verification.md
@docs/plans/dashboard.md
@docs/dev_tasks/README.md

Load `docs/plans/README.md`, `docs/onboarding/contributing.md`,
`docs/onboarding/ci-cd.md`, and `docs/onboarding/ai-tools.md` only when the
selected mode or routed workflow needs them.

## Arguments

Interpret `$ARGUMENTS` as optional constraints:

- `mode=select`: choose one task and stop with evidence.
- `mode=execute`: choose one task, make local changes, and verify locally.
  This is the default when the user asks to do the work.
- `mode=pr`: execute locally and prepare PR text. Before an action requiring
  explicit maintainer/user approval under `docs/ai/principles.md` and the PR
  owner docs, verify existing authorization covers its action, target, and
  scope; ask only for missing authority. Ordinary authorized local branch
  creation is preparation; shared-state mutations, branch deletion, and
  destructive Git operations retain their approval requirements.
- `size=tiny|small|medium|large` or `days=N`: fit the chosen task to the
  requested scope. Default to `small`, meaning one focused local session.
- `focus=<topic>`: prefer a focus area without making it the only allowed
  candidate. Examples: `ai-native`, `easy-start`, `algorithm`, `compute`,
  `release`, `ci`, `docs`, `python`, `io`, `PLAN-122`, `world_split`,
  `dartpy`, or a file path.
- `area=<dimension>`: alias for `focus=<dimension>`.
- Any issue, PR, branch, milestone, failing check, file path, or user-stated
  priority overrides the default dashboard order.

If constraints conflict or make the task unsafe to select, stop and ask one
clarifying question.

## Workflow

1. Inspect local state before choosing work:
   ```bash
   git status --short --branch
   git diff --stat
   ```
2. Build the candidate set from tracked evidence:
   - explicit user instruction in `$ARGUMENTS`;
   - current branch, local diff, or active `docs/dev_tasks/<task>/` state;
   - `docs/plans/dashboard.md`, in priority order, especially `Horizon: Now`;
   - `docs/ai/north-star.md` gaps and readiness criteria;
   - issue, PR, or CI state named by the user or inferable from the branch.
3. Exclude candidates that are blocked, larger than the requested size, missing
   enough evidence to start, or only bootstrap/maintain the `dart-next` workflow
   itself unless explicitly focused. Missing approval excludes a candidate only
   when it has no useful bounded deliverable within the selected mode and
   current authorization. A later publication requirement does not disqualify
   local preparation. Preserve explicitly named targets; report their remaining
   approval boundary after completing authorized work.
4. Prefer the highest-value remaining candidate in this order:
   - user-specified issue, PR, failing check, or file path;
   - candidates matching `focus=<topic>` or `area=<dimension>`;
   - failing CI or review feedback on the current PR;
   - active dev task with a clear next local step;
   - first unblocked `Horizon: Now` dashboard item fitting the size;
   - issue triage or plan refinement when implementation evidence is missing.
5. State the selected task before editing:
   - candidate and source evidence;
   - rejected higher-priority candidates and why they were not selected;
   - whether the preferred focus matched the selected task, and why if it did
     not;
   - size assumption and expected stopping point;
   - workflow to follow next;
   - verification gate from `docs/ai/verification.md`.

## Execution Routing

After selection, follow the most specific DART workflow:

| Selected work              | Route through                                           |
| -------------------------- | ------------------------------------------------------- |
| New implementation task    | `$dart-new-task` in Codex or `/dart-new-task` elsewhere |
| Existing dev task          | `$dart-resume` in Codex or `/dart-resume` elsewhere     |
| Numbered-plan work packet  | `$dart-execute-packet` or `/dart-execute-packet`        |
| Plan-only change           | `$dart-plan-update` in Codex or `/dart-plan-update`     |
| Docs-only change           | `$dart-docs-update` in Codex or `/dart-docs-update`     |
| GitHub issue fix           | `$dart-fix-issue` in Codex or `/dart-fix-issue`         |
| Downstream bug             | `$dart-downstream-fix` or `/dart-downstream-fix`        |
| Failing CI                 | `$dart-fix-ci` in Codex or `/dart-fix-ci`               |
| PR review or PR management | `$dart-review-pr` / `$dart-manage-pr` or slash versions |

If the selected task is multi-session or needs design tracking, create or
update `docs/dev_tasks/<task>/` according to `docs/dev_tasks/README.md`.

## Local Work Cycle

1. Load task-specific docs from `AGENTS.md` and the routed workflow.
2. Make the smallest coherent local change that satisfies the selected task.
3. Run the strongest relevant local gate:
   - docs/AI work: gates from `docs/ai/verification.md`;
   - C++ or Python behavior: `pixi run lint`, build, and focused tests;
   - CI work: local reproduction when possible plus the fixed check.
4. Review the local diff before declaring completion:
   ```bash
   git diff --stat
   git diff --check
   ```
5. Optimize or benchmark only when the selected objective is performance
   sensitive or the plan gate explicitly requires performance evidence.
6. Update durable docs when the task changes project state, public workflow, or
   roadmap evidence.
7. Run the completion audit from `docs/ai/verification.md` before finalizing.

## PR And Review Management

Use `$dart-pr` or `/dart-pr` only after local verification is complete and the
user requested PR preparation. Verify existing explicit maintainer/user approval
for each approval-gated action under `docs/ai/principles.md` and the PR owner
docs; ask only for missing or changed authority. Local branch creation and
other authorized preparation need no extra approval. Shared-state mutations,
branch deletion, and destructive Git operations retain their approval boundaries.

After a PR exists and explicit approval covers PR management, use
`$dart-manage-pr` or `/dart-manage-pr` for CI, review, and cleanup; the Codex
review trigger and draft-ready criteria live in `docs/onboarding/ai-reviews.md`.

## Output

Report:

- selected task, size, evidence, and routed workflow;
- files changed and verification commands run;
- completion-audit result and any remaining blocker;
- PR readiness status, without performing external mutations unless explicit
  approval was given.