dv-tasks

name	dv-tasks
description	Da Vinci tasks direct route skill for Codex.

Da Vinci Tasks

Use this direct $dv-tasks skill for the request.

Action: tasks

Shared hook and lifecycle boundary:

• treat da-vinci workflow-status --project <path> [--change <id>] --json and da-vinci next-step --project <path> [--change <id>] as the single routing brain; do not invent a separate routing or readiness engine
• treat .da-vinci/state/change-state.json, .da-vinci/state/change-seq.json, and .da-vinci/state/change-lifecycle.lock as command-owned lifecycle surfaces, not prompt-owned heuristics
• after those route checks confirm $dv-tasks, run da-vinci hook-bridge --project <path> [--change <id>] --trigger-kind stage:start --stage tasks --json
• hook-bridge is bounded to stage:start preflight only; it must not replace manual promotion, route selection, or lifecycle commands
• treat hook requires as same-trigger dependencies only; required consumers block when a dependency is missing, disabled, stale, failed, returns WARN, or is ordered after the consumer, and optional consumers warn and skip execution
• preserve policy order as execution order; do not topologically sort or auto-reorder hook bindings
• treat da-vinci hook-status and workflow-status as read-only hook diagnostics for local binding identity, project declaration/default provenance, snapshot status, role metadata, latest-versus-effective run interpretation, and hookRecovery; they must never become route authority or a second workflow engine
• if .da-vinci/changes/<change-id>/hook-policy.system.json is missing, keep the story hook-local: surface hookRecovery.status = recovery_required with hookRecovery.reason = system_snapshot_missing instead of inventing an empty-policy fallback or lifecycle repair
• treat .da-vinci/changes/<change-id>/project-profile.system.json as a separate frozen change-local platform/locale/app-technology contract; hook or route diagnostics may reference it, but active changes must not live-read .da-vinci/project-profile.json
• treat system.project-profile.ensure as a check-only stage:start:breakdown validation seam: it may refresh .da-vinci/changes/<change-id>/project-profile.system.json only after canonical .da-vinci/project-profile.json is confirmed; profile collection remains owned by da-vinci dv-change-new [change title] / $dv-change-new before lifecycle creation
• treat .da-vinci/design-source-profile.json as the canonical project-level design-source selector; repo-owned .da-vinci/design-sources/awesome-design-md/*/DESIGN.md snapshots stay bounded advisory reference input and sibling tokens.system.json stays derived import evidence rather than route truth
• treat .da-vinci/changes/<change-id>/candidates/product-prototype.md and .da-vinci/changes/<change-id>/candidates/copy-catalog.json as generated promotion inputs; the requirement export hook may refresh them, but candidates alone never satisfy design entry
• treat .da-vinci/changes/<change-id>/requirement-truth-promotion.system.json as read-only paired-promotion evidence for accepted breakdown_to_design
• treat .da-vinci/changes/<change-id>/product-prototype.md and .da-vinci/changes/<change-id>/copy-catalog.json as promoted canonical change-local requirement-side design-entry companions; hook or route diagnostics may reference them, but only paired promotion may update them
• treat .da-vinci/changes/<change-id>/page-design-contracts.json and .da-vinci/changes/<change-id>/icon-map.json as canonical change-local design-entry contracts; hook or route diagnostics may reference them, but they are not hook-owned artifacts
• keep one canonical consumer chain for design-entry consumers: promoted product/copy truth -> page design contracts -> icon map
• when .da-vinci/design-source-profile.json is missing, treat confirmed .da-vinci/DESIGN.md as the project-local design-source baseline only when it stays rich and complete
• during breakdown, .da-vinci/DESIGN.md is read-only advisory if it already exists; do not create .da-vinci/DESIGN.md during breakdown, and leave .da-vinci/DESIGN.md missing until the design route materializes it through design-confirm --confirm
• treat .da-vinci/changes/<change-id>/source-digests.system.json as design-entry source freshness evidence; stale canonical artifacts block design entry instead of being auto-regenerated as recovery
• treat .da-vinci/changes/<change-id>/icon-supply.system.json as derived change-local icon-catalog readiness evidence; hook or route diagnostics may reference it, but it is not editable route truth
• when the shared design_to_tasks gate is rendered, keep design-entry readiness plus parallel Design Review, Icon Verification, and Copy Verification on the same fail-closed seam; WARN remains pending until explicit dv-handoff acceptance
• keep structured UI quality checks on that same seam: uiQualityScore, first-screen structured .dvp metadata, the density linter, anti-AI-look issue ids, visible text copyKey / locale, and icon iconId / qualifiedName bindings must not create a new route or workflow stage
• keep the task/build/conformance spine on existing seams: build-packet.system.json artifactSpine, derived tasks.index.json contractRefs, and implementation-conformance.system.json are replay evidence for task, build, and verify promotion, not new workflow stages or canonical source truth
• when build_to_verify replay sees missing, stale, or BLOCK implementation conformance, keep verification promotion blocked instead of treating the gap as advisory guidance
• treat .da-vinci/changes/<change-id>/quality-profile.system.json as a separate frozen change-local quality contract; hook or route diagnostics may reference it, but active changes must not live-read .da-vinci/quality-profile.json or .da-vinci/quality-profiles/*.json
• treat .da-vinci/changes/<change-id>/prd.md as a read-only derived summary owned by system stage:start:design; do not promote it to requirement truth or regenerate it from requirement handoff
• if hook-status --json is missing or invalid, keep recovery bounded to hook_status_payload_invalid or hook_status_payload_missing; hook policy mutation must wait until payload trust returns
• keep lifecycle commands explicit: da-vinci dv-change-new [change title], da-vinci dv-change-close, and da-vinci dv-change-recover <change-id> [--confirm]
• if lifecycle repair is required, do not invent a switch-change route; point the operator to $dv-repair as the maintained repair surface for abnormal lifecycle recovery

Reply contract:

• after route work, rerun da-vinci workflow-status --project <path> [--change <id>] --json and da-vinci next-step --project <path> [--change <id>] --json so the final report reflects current truth
• keep the reply in the standard Da Vinci operator format instead of a plain work log
• summarize current truth first: active change id, title, lifecycle status, derived stage, pending handoff, and blocker or repair status
• when blocked, surface Root cause: ... before any maintained next command
• include Execution detail: ... only when the underlying CLI result or gate clarifies the blocker without replacing the maintained route
• keep Evidence refs: ... high-signal on terminal-style output; richer JSON payloads may keep fuller ref lists
• preserve Failures:, Warnings:, and Notes: when present
• if exactly one legal next action exists, emit Next command: ...
• if pendingHandoff.command or the top recommended legal next command is $dv-handoff because review is still missing or WARN needs explicit acceptance, emit Next command: $dv-handoff instead of skipping directly to the downstream stage route
• if multiple legal next actions exist, group them as Recommended, Also valid, Mandatory rollback, and Rollback
• when the legal next action is another maintained Da Vinci surface, restate it using this platform's wrapper names: $dv-continue, $dv-code-context, $dv-change-new, $dv-change-close, $dv-change-recover, $dv-breakdown, $dv-handoff, $dv-design, $dv-tasks, $dv-build, $dv-verify, $dv-repair, $dv-illustration-list, $dv-illustration-prompt, $dv-illustration-add
• do not recommend raw CLI or /prompts:* actions as the next command; mention raw CLI only as execution detail inside the current maintained surface
• do not auto-invoke the next command from inside $dv-tasks

Output should move the work toward:

• .da-vinci/changes/<change-id>/tasks.md

Before broad task planning when shell access is available:

• if the primary recommended route is not $dv-tasks, stop and continue from that route instead of forcing task planning

Tasks must cover:

• spec-backed behavior
• da-vinci-pencli-backed UI work
• verification work

Task-plan discipline:

• each top-level task group should include exact file or code-area ownership targets
• include explicit verification commands, not only abstract verification wording
• include execution intent hints (serial, bounded_parallel, or review_required) and review intent
• include parseable discipline markers for design approval, plan self-review, and operator review acknowledgment

Before claiming implementation-ready task planning:

• re-check that the workflow is still in the $dv-tasks lane when route context is stale or unclear
• run the task checkpoint
• when shell access is available, run da-vinci lint-tasks --project <path> [--change <id>]
• if both .da-vinci/changes/<change-id>/ui-design.md and .da-vinci/changes/<change-id>/ui-bindings.json exist, run da-vinci lint-bindings --project <path> [--change <id>]
• treat command output as the gate; do not downgrade BLOCK or non-zero results into soft guidance
• do not hand off to build while task coverage or bindings readiness are still blocking
• once task planning is ready, stop this route and tell the user to run $dv-handoff manually; do not invoke $dv-handoff automatically from inside $dv-tasks