dart-execute-packet

name	dart-execute-packet
description	DART Execute Packet: select and execute one orchestrator-authored work packet from a numbered plan

dart-execute-packet

Use this skill in Codex to run the DART dart-execute-packet 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-execute-packet <arguments>
• Codex: $dart-execute-packet <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

Execute a work packet in DART: $ARGUMENTS

Required Reading

Read these files first: @AGENTS.md @docs/ai/orchestration.md @docs/ai/principles.md @docs/ai/verification.md @docs/plans/dashboard.md

Inputs

$ARGUMENTS is optional and takes one of three forms:

• WP-<plan>.<n> (for example WP-122.1) — execute exactly that packet.
• PLAN-NNN (for example PLAN-122) — select the first available packet in that plan.
• empty — auto-select: walk docs/plans/dashboard.md top to bottom (document order is priority); for each Active entry whose owner doc is a numbered plan file containing ### WP- packet headings (the discovery rule in docs/ai/orchestration.md), take the first available packet by the availability rules below. State which packet was selected and why before starting.

If nothing resolves to an available packet, report what was checked (plans walked, packets skipped and the blocking signal for each) and stop; do not invent work.

Availability and conflict check

Apply docs/ai/orchestration.md's "Packet discovery and claim signals": verify all dependencies, local and default-branch markers, remote branches, and open PRs before claiming. Fetch/list operations are read-only; an unverifiable precondition is unmet. Never remove another session's claim or reuse its branch. Pushes and PR mutations require explicit maintainer/user approval.

In auto/plan mode, skip unavailable packets. For an explicit packet ID, report the conflicting or unmet signal and stop.

Readiness check

Inspect the packet and named owners against the work-packet contract in docs/ai/orchestration.md.

If objective, scope, acceptance evidence, gates, or dependencies are missing or too vague to verify, report that the packet is not executable and stop (dependencies gate availability and are never inferred). When value, non-goals, or assumptions are absent, infer them from the owner docs and state the inferred fields before editing. If an unresolved decision would materially change public API, release compatibility, numerical correctness, benchmark claims, or roadmap scope, stop and ask the orchestrator to record an owner-local Decision needed block.

Workflow

1. Locate the packet — open the owning numbered plan file linked from docs/plans/dashboard.md and read the packet's objective, scope, value/rationale, assumptions/open decisions, non-goals, acceptance evidence, gates, and dependencies.
2. Claim — append [claimed] to the packet heading in the plan file and create the topic branch named wp-<plan>-<n>-<slug>. The branch name is the cross-machine claim signal once pushed; pushing it (like any GitHub mutation) requires explicit maintainer/user approval, so until then the marker and branch are local and the strongest remote signal stays the merged plan file.
3. Load packet context — read the owner docs the plan names for that workstream plus the files in the packet's scope. Do not load the whole plan corpus; the packet defines the working set.
4. Implement exactly the packet — stay inside scope and non-goals. If the real scope differs materially from the packet's stated scope, stop and report back with what was found; do not widen the packet. One packet, one branch, one verification story.
5. Verify — run the packet's gates plus pixi run lint before any commit. Record each piece of acceptance evidence named by the packet (test names, command output, doc updates). Missing evidence means the packet is not complete — say so explicitly.
6. Hand back — append an Evidence: bullet to the packet in the plan file listing the recorded evidence (or update the dev-task RESUME.md for multi-session packets), leave the [claimed] marker for the orchestrator to replace with [done — ...] on acceptance, then report completion with the evidence list for orchestrator review. Local commits are part of execution; pushes and PR creation require explicit maintainer/user approval first, and the PR title starts with the packet ID (WP-<plan>.<n>: ...) so the claim is searchable.

Rules

• The packet's owner docs win over the packet text on any conflict; report the conflict rather than improvising.
• Do not chain into adjacent packets, refactor outside scope, or "fix while here" — file findings back to the orchestrator instead.
• Never remove another session's [claimed] marker or reuse its branch; stale-claim release is the orchestrator's call (see docs/ai/orchestration.md).
• Behavior-preserving packets must prove preservation (golden trajectories or the tests the packet names), not assert it.
• Solver-family work additionally honors the intake checklist in docs/plans/solver-family-intake.md.
• The author of a packet's implementation does not approve it; acceptance is the orchestrator's or an independent reviewer's call.

Output

• Selected packet ID and owning plan
• Scope implemented and acceptance evidence recorded
• Gates run and their results
• Hand-back state (the [claimed] marker left for the orchestrator) and any blocker
• Any external mutation that was explicitly approved