dart-next

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/plans/north-star-roadmap.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, then ask for explicit maintainer/user approval before any GitHub, PR, CI, branch, or review-thread mutation, including pushes, PR creation, PR comments, reviewer requests, review re-triggers, thread resolution, ready-for-review transitions, merges, CI reruns, or branch deletion.
• 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, likely to require unapproved GitHub mutations, or only bootstrap/maintain the dart-next workflow itself unless explicitly focused.
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.