dart-plan-update

name	dart-plan-update
description	DART Plan Update: discuss or update DART living plans

dart-plan-update

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

Discuss or update DART living plans: $ARGUMENTS

Required Reading

@AGENTS.md @docs/ai/principles.md @docs/ai/north-star.md @docs/plans/README.md @docs/plans/dashboard.md @docs/plans/north-star-roadmap.md @docs/ai/verification.md

Workflow

1. Classify the request:
   • discussion-only: compare options, priority, scope, or sequencing;
   • plan edit: revise docs/plans/** or related indexes;
   • task derivation: turn a plan item into a bounded implementation or docs task.
2. Inspect current evidence before changing plan state. Use repo docs, code, tests, CI evidence, issue/PR state, benchmark data, or explicit maintainer direction.
   • For new solver/paper implementation plans, preserve the full paper-complete bar in docs/ai/verification.md: all algorithms/features, CPU and GPU paths, paper/site/video demos, benchmark JSON that beats reference and paper numbers, and clean long-term API/pipeline work.
   • For active multi-session solver/paper work, update the plan or dev-task resume surface with both the completed slice and the next missing paper-parity gap; do not let focused tests narrow the recorded objective. If the user names source demos, videos, or project pages, keep the corpus matrix explicit: which scenes/experiments are represented by tests, py-demos, visual artifacts, benchmark JSON, CPU reference comparisons, and GPU parity, and which rows remain missing.
3. Keep the plan manageable:
   • revise an existing initiative before adding a duplicate;
   • use stable initiative IDs when renaming, splitting, consolidating, or parking work;
   • keep docs/plans/dashboard.md as the single source of truth for priority, status, horizon, dimension, next step, and gate.
   • when deriving packets or dev-task work, include the DART specification intake from docs/ai/orchestration.md: value, scope, non-goals, assumptions/open decisions, acceptance evidence, gates, and dependencies. Use owner-local Decision needed blocks for consequential ambiguity instead of silent defaults.
4. For discussion-only requests, present the tradeoff and proposed plan delta; do not edit unless the user asks for an edit or the request already implies one.
5. For plan edits, update docs/plans/dashboard.md for operating state, the detailed numbered initiative file or external owner document for rationale and workstreams, and docs/plans/north-star-roadmap.md only for strategic framing.
6. If the plan item becomes implementation work, route to /dart-new-task in Claude/OpenCode or $dart-new-task in Codex, and use docs/dev_tasks/README.md when it is multi-session or needs design tracking.
7. Verify with docs/ai/verification.md: use the docs-only gate for plan-only docs, and the AI docs/adapters gate set when AI docs, workflow sources, or generated adapters change.
8. Do not perform GitHub or remote mutations without explicit maintainer/user approval.

Output

• Request classification (discussion, plan edit, or task derivation)
• Plan files changed and the operating-state updates made
• Verification gate run
• Any routed follow-up task or Decision needed block recorded