# Dart Execute Packet > DART Execute Packet: select and execute one orchestrator-authored work packet from a numbered plan - Skill: `dartsim/dart-execute-packet` (Agent Skill) - Install (CLI): `npx skillmds@latest add dartsim/dart-execute-packet` - Raw SKILL.md: https://api.skillmd.com/api/skills/dartsim/dart-execute-packet/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: dartsim (https://skillmd.com/u/dartsim) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/dartsim/dart-execute-packet --- # 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 ` - Codex: `$dart-execute-packet ` 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-.` (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---`. 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-.: ...`) 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