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/OpenCode: /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-091.13) — execute exactly that packet.
• PLAN-NNN (for example PLAN-091) — 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, 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

Run the full check from docs/ai/orchestration.md before claiming. A packet
is available only when ALL of these hold:

1. Dependencies — its Dependencies line is satisfied in full: every named
   packet is marked [done — ...], and every non-packet precondition (for
   example "maintainer direction on ..." or an accepted design note) has
   recorded evidence in the plan or the named owner doc. Treat any
   precondition you cannot verify as unmet and skip the packet.
2. Local markers — its heading carries neither [done — ...] nor
   [claimed] in the local plan file.
3. Remote markers — git fetch origin (a read-only sync), then check the
   plan file as it exists on the default branch
   (git show origin/main:docs/plans/<plan-file>.md) for a marker the local
   checkout does not have yet.
4. Branch/PR signals — no one else is already working it:
   git ls-remote --heads origin shows no branch embedding the packet ID in
   the documented form (wp-<plan>-<n>-<slug>, for example
   wp-091-13-contact-assembly), and gh pr list --state open --search "WP-<plan>.<n>" returns no open PR carrying the ID in its title. These are
   read-only queries that mutate nothing; any push, PR creation, or other
   GitHub mutation still requires explicit maintainer/user approval.

If any signal says the packet is taken: in auto/plan mode skip to the next
available packet; for an explicit packet ID, report the conflicting signal
and stop.

Readiness check

Before claiming, inspect the packet text and named owner docs for the
specification intake required by docs/ai/orchestration.md:

• objective;
• value or rationale;
• scope;
• non-goals;
• assumptions and open decisions;
• acceptance evidence;
• gates; and
• dependencies.

If objective, scope, non-goals, acceptance evidence, gates, or dependencies are
missing or too vague to verify, report that the packet is not executable and
stop. For older packets that lack an explicit value or assumptions field,
proceed only when the owner docs make the value and assumptions unambiguous,
and state those 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