Dart Next

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:

   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:

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:

   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.