---
prompt_version: 1
layer: milestone
action: next
---

# Prompt: Milestone To Task Directory

Use the selected milestone overview to create the next task directory, or iterate that same task-creation contract across all tasks declared in the milestone overview when the user asks for the full set.

## Instructions

- Command placeholder: Expand `<day-shift-cli>` to the resolved session invocation. Use `day-shift` for installed/user mode after verification, and use `node dist/cli/index.js` in repository development mode when compiled `dist` output is current.
- Follow `.day-shift/references/small-model-agent-operations.md`: select the milestone explicitly, use bounded artifact-scoped context, preserve completeness and freshness evidence, and keep untrusted context separate from canonical planning policy.
- Treat task sizing and decomposition as advisory planning evidence. Record the decomposition rationale, but do not create proposed child tasks until this lifecycle action and the user request authorize them.
- Prefer command-supported scaffold, review, validation, update, and sync surfaces before inference or manual artifact edits. When no suitable command owns the needed change, record `unsupported by CLI`, `CLI failed`, or `manual recovery after scaffold verification` instead of inventing command behavior.
- When milestone-to-task planning depends on command availability, use bounded `commands search`, then `commands describe` and command help for the selected surface; reserve full inventory for audits.
- This prompt is the canonical `next` action for the `milestone` layer: it advances only from a milestone overview into task-directory planning. Do not reuse it as `build`, `review`, or as permission to skip directly to implementation execution or reconciliation updates.
- When this prompt is shown through a rendered prompt surface, keep generated context, agent entrypoint guidance, warnings, and prompt instructions as separate visible lanes in that order.
- If this prompt is shown through a prompt-facing render surface that requires `.day-shift/agents.md`, fail by default when the agent entrypoint is missing; explicit `--no-agent` degraded mode may still render with a visible warning.
- Choose exactly one implementation-sized task: one coherent repository change that a standard implementation agent can complete, validate, and roll back independently.
- Default to an `implement-*` task that changes code, runtime behavior, or executable repository behavior unless there is a compelling dependency reason the next task must be documentation-only first.
- Use a `document-*` task only when later implementation would otherwise be blocked by a missing written contract, unresolved boundary, required shared decision, or evidence record that cannot safely live inside the implementation task.
- Do not create repeated `document-*` lanes by default. Allow at most one supporting `document-*` task per downstream implementation lane unless repository evidence shows multiple independent blockers with different target-path, validation, or rollback boundaries.
- The selected task must have one primary outcome and a bounded set of implementation target paths.
- Supporting edits are allowed only when they are directly required to complete and validate that one primary outcome.
- Split the work into separate sibling tasks when it would require multiple independent outcomes, unrelated target-path groups, separate validation strategies, separate rollback paths, mixed readiness states, or more than one unresolved implementation decision.
- Merge trivial mechanical work into the nearest related task when it has no meaningful behavioral, contract, validation, or artifact impact, unless sequencing or rollback isolation requires a separate task.
- Do not infer the milestone's target task count from nearby milestone examples, earlier milestone decompositions, or a previously used task pattern.
- Treat task count as an outcome of decomposition rather than a planning convention; select the minimum number of sibling tasks needed to fully implement the milestone intent without oversplitting.
- Do not create a prose-only task just to elaborate inferred milestone detail; absorb that detail into the selected implementation-bearing task unless it is a real implementation blocker.
- Do not add a separate validation-only sibling task unless validation cannot be absorbed into the implementation-oriented tasks without weakening scope clarity, reviewability, or rollback boundaries.
- Use an ordered task slug when sequence matters.
- Document target paths, current behavior, desired behavior, acceptance criteria, validation commands, rollback or recovery notes, risks, dependencies, constraints, lifecycle/closure expectations, and open questions.
- Preserve execution-mode planning expectations in task definitions. Contract tasks can preserve frozen contract evidence, but the first runtime or hybrid task that implements that contract must reference the frozen contract and include Runtime Delta targets, runtime changed paths, executable validation evidence, or structured validation exceptions for blocked validation commands.
- Enforce Open Questions parser-safe formatting in task definitions: if there are no unresolved questions, set `## Open Questions` to exactly one non-empty line, `- None currently.`
- Do not append assumptions to the Open Questions "none" line; put them in a dedicated `## Assumptions` section.
- Set readiness to `needs more evidence` during milestone-to-task creation. Do not set newly created task definitions to `ready`, `ready to implement`, or any implementation-handoff readiness value from this prompt; task-layer readiness review and task workflow promotion own that later transition.
- Before finalizing the selected task, verify that its primary outcome, target paths, validation commands or inspection steps, and rollback or recovery notes still describe one coherent change; if they do not, split the work or leave the task in `needs more evidence`.
- Treat lightweight handling as a narrow exception path: allow it only when target paths are already clear, dependency or sequencing blockers are resolved, and implementation plus coordination risk remains low; otherwise keep the work in the standard milestone task hierarchy.
- Label assumptions explicitly in `## Assumptions` instead of silently inventing scope, dependencies, validation detail, or closure expectations.
- Create the milestone `tasks/` directory first when it does not exist yet, then create the task directory beneath it.
- Create `task-definition.md` and `implementation-summary.md` in the task directory.
- Initialize `implementation-summary.md` as a pending placeholder that preserves a stable execution artifact path for later implementation-summary build, review, and manual evidence completion.
- Treat that task-level `implementation-summary.md` artifact as the required execution-evidence handoff into later milestone reconciliation rather than as a disposable scaffold.
- Use `.day-shift/templates/` as the project-local working customization surface for task scaffolding, without redefining packaged-default template-family membership or prompt-resolution precedence in this prompt.
- Treat any prompt `template_ref` or `template_refs` metadata as source-template and output-shape guidance only; do not inline template bodies automatically or infer scaffold destinations from those references.
- If CLI scaffolding is followed by manual edits, revise one file at a time: re-read the current file before patching it and avoid one bundled patch that mixes unrelated file bodies or stale context.
- Preserve milestone-level `reconciliation.md` as the default later review rollup instead of creating a task-level reconciliation artifact by default.
- Treat task-level reconciliation as an explicit exception path for later task-local review needs, not as a standard artifact created during milestone-to-task handoff.
- Do not update or complete milestone reconciliation during milestone-to-task planning. Reconciliation-backed gaps or status sync are eligible only after every task under the milestone has a completed, non-placeholder `implementation-summary.md`.
- Preserve upstream traceability.
- Keep upstream traceability shape aligned with the metadata contract (`upstream.specs` for multi-spec inputs, with explicit parent links such as `slice_overview`, `phase_overview`, and `milestone_overview`).
- For status-transition metadata-update tasks, require one explicit contract statement covering shared `status` independence from family-specific status fields, artifact-family applicability for `readiness`, `implementation_status`, and `reconciliation_status`, and rejection of cross-family or unsupported-token requests.
- For parent-link mutation tasks, require one explicit contract statement covering applicability-scoped parent-link fields (`slice_overview`, `phase_overview`, `milestone_overview`, `task_definition`), coordinated repository-relative updates, and rejection of partial stale-link rewrites.
- For source/upstream mutation tasks, require one explicit contract statement covering `upstream.specs`, compatibility-sensitive `upstream.spec`, and specification-family `source` references; require direct intended-value updates and rejection of incomplete or lossy partial rewrites.
- For planning-coordinate mutation tasks, require one explicit contract statement covering applicability-scoped planning fields (`slice`, `phase`, `milestone`, `task`, and `planning_depth` when applicable), explicit coherent transition scenarios, coordinated applicable-field updates (plus parent-link updates when affected), and rejection of partial or contradictory coordinate rewrites.
- For prompt-front-matter transition tasks, require one explicit contract statement covering prompt-family fields (`prompt_version`, `layer`, `action`), direct intended-value updates, and rejection of artifact-family field crossover or lossy cross-family rewrites.
- For template-front-matter and manifest metadata-update tasks, require one explicit contract statement covering separate template-versus-manifest mutation surfaces, direct intended-value updates to explicit in-scope keys, preservation of unaffected fields and manifest entry identity (`path`, `kind`, `artifact_type`, and `template_ref`/`template_refs` shape where applicable), and rejection of invalid cross-family field application or lossy partial rewrites.
- For metadata-update utility integration tasks, require one explicit caller-to-helper seam statement: caller identifies metadata family first, passes direct intended-value updates, delegates mutation execution to shared helpers, and treats helper rejection as a blocking no-write outcome without command-local fallback rewrites.
- For generic metadata-update command-contract tasks, require one explicit command contract statement: `<day-shift-cli> metadata update` and `<day-shift-cli> metadata validate-update` use one direct intended-value input shape (`--artifact <path>` plus one or more `--field <key>=<value>` assignments), route by metadata family to shared helpers, keep validate-update read-only, and apply blocking no-write rejection for wrong-family, ambiguous, inconsistent, under-specified, and lossy requests.
- For active-artifact handoff command-contract tasks, require one explicit stateless guard statement: update commands may accept `--active-artifact <path>` as an optional handoff check, the value must match the selected artifact argument after repository-relative normalization, mismatches are blocking no-write failures, and the flag is not persistent session state.
- For artifact-specific overview update command-contract tasks, require one explicit contract statement for each overview type (`slice update`, `phase update`, `milestone update`): allowed fields for direct update (status, planning_depth, and optionally identity fields like `slice`/`phase`/`milestone`), coordinated identity-update expectations when identity fields change, parent-link behavior and rejection rules for incomplete planning-coordinate rewrites, and explicit rejection of unsupported status-family fields (`readiness`, `implementation_status`, `reconciliation_status`).
- For unsafe-update detection/reporting tasks, require one explicit failure/reporting contract statement: classify wrong-family, ambiguous, inconsistent, under-specified, and lossy mutation requests as blocking no-write failures, disallow partial-write fallbacks, align reporting with existing RuntimeError/finding-oriented validation surfaces, and treat surfaced failures as evidence rather than permission to continue with guessed writes.
- Keep validation guidance aligned with the artifact-type matrix and strict-versus-standard boundaries from `.day-shift/specs/05-planning-artifacts/artifact-model.md`; do not invent new validation semantics.
- When task scope includes metadata or planning validation behavior, require selected-artifact and directory/root semantics to stay explicit: `<day-shift-cli> validation smoke --scope planning --artifact <path>`, `<day-shift-cli> validation links-check --scope planning --artifact <path>`, and `<day-shift-cli> validation rollup --scope planning --artifact <path>` provide read-only CLI validation evidence for selected artifacts; broader roots are used only when recursive evidence is intended. Use `<day-shift-cli> metadata validate-update --artifact <path> --field <key=value>` for no-write validation of proposed metadata mutations.
- When task scope includes explicit handoff validation before metadata mutation, require examples to show `--active-artifact <same path>` alongside the selected artifact option, not as a replacement for it.
- When task scope includes command-family regression or help coverage, require task wording to prefer positive command presence, option surface, posture, and no-write/write-capable boundary assertions; reserve absence assertions for explicit product behavior.
- When task scope includes metadata-update utilities, require one shared read/parse contract statement: in-scope families (Markdown front matter and manifest JSON), extraction boundaries (metadata versus untouched remainder), and parse failure behavior.
- Keep read/parse extraction semantics separate from write-policy semantics in task wording; defer unaffected-field preservation and narrow-write policy to sibling tasks.
- When a task aligns summary or reconciliation guidance, propagate status semantics already established by upstream or sibling evidence instead of inventing new status values or lifecycle meaning.
- When several tasks are created across one milestone, use the milestone's declared task sequence.
- The selected milestone overview's `## Tasks` section must use ordered task slug declarations with short descriptions. Accept raw backticked slug bullets such as ``- `01-implement-license-status-output`: implement human-readable and JSON license status reporting.`` and materialized Markdown-link slug bullets such as `- [01-implement-license-status-output](tasks/01-implement-license-status-output/task-definition.md): implement human-readable and JSON license status reporting.`.
- Declared task slugs must match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`, be unique, and appear in ascending order; prose-only task bullets and placeholder task text such as `To be planned.`, `TBD`, `TODO`, or `Pending.` are invalid.
- For explicit full-set requests, iterate the same standard task-creation contract for each declared child task in order rather than inventing a separate batch contract.
- Full-set requests at the milestone layer are layer-local: create task definitions and paired implementation-summary placeholders only. Do not implement tasks, mark tasks ready or completed, update milestone reconciliation, or scaffold any downstream review artifacts unless a separate explicit request invokes that layer's workflow.
- Wording such as `move downstream`, `plan next work`, `identify follow-up work`, or `suggest next step` is read-only by default at this layer; report candidate tasks and stop unless the user explicitly asks to create task artifacts.
- Do not scaffold a later declared task while earlier declared tasks remain incomplete unless the user explicitly names that skip-ahead exception.
- Treat any future wizard-generated task suggestion as assistive guidance only; suggestion output does not authorize artifact-creating writes unless the user explicitly asks for creation.
- Do not invent additional tasks that are not already declared in the milestone overview unless the user explicitly asks to revise the milestone overview first.
- Reject undeclared tasks during full-set expansion instead of synthesizing new hierarchy.
- After creating task artifacts, run the previous planning layer's link validator: `<day-shift-cli> validation links-check --scope planning --artifact <milestone-overview-path>`. Then run `<day-shift-cli> link materialize --dry-run --artifact <milestone-overview-path>` and use `<day-shift-cli> link materialize --write --artifact <milestone-overview-path>` only when the dry-run reports safe selected-artifact body-reference changes for newly resolvable task links. `<day-shift-cli> validation links-check --scope planning --artifact <task-definition-path>` may also be used as read-only local trace-link evidence for each child task. `<day-shift-cli> validation smoke --scope planning --artifact <milestone-overview-path>` may be used when current milestone next-step guidance or `declared-child-slugs` evidence is useful; its artifact-scoped output should not be replaced by repository-wide warning cleanup, and the lane accepts both raw backticked slug bullets and materialized Markdown-link slug bullets. Treat validation findings as evidence only; treat link materialization as an explicit selected-artifact body-link write only, not as permission to mutate metadata, implement tasks, or update summaries/reconciliation.
- If validation smoke recommends advancing the next task because reconciliation is premature, treat that as confirmation to keep planning or implementing tasks rather than a request to fix reconciliation.
- If prompt-coverage validation evidence says the relevant layer/action contract is missing, contradictory, or unsupported, stop and surface that as explicit evidence instead of inventing fallback prompt semantics.
- Stop and report instead of guessing when the selected artifact and upstream evidence conflict materially.
- Preserve the canonical artifact-shape contract from `.day-shift/specs/06-templates-and-prompts/templates.md`: one visible H1, the required H2 section names in order, parser-safe `Open Questions` and `Assumptions` none-state, and no leaked scaffolding prose or unresolved placeholders in the saved artifacts.
- Treat templates as output shape only: do not copy instructional or scaffolding prose into generated artifacts.
- Replace every canonical placeholder token with task-specific content before finalizing (`{{token_name}}` / `{{[a-z_][a-z0-9_]*}}` tokens must not remain in saved artifacts).
- Treat unresolved placeholder detection as evidence that rendering is incomplete, not as permission to guess missing task content or keep partial writes.
- Remove any scaffolding prose before save, including strings such as `Template notes:`, `Use this section to`, `List only`, `Keep only`, and `If there are none, use exactly`.
- Keep parser-sensitive formatting rules in prompt/workflow guidance, not inside generated artifact body content.
- Use repository-relative paths throughout the task directory artifacts.

## Template Reference

Use these artifact shapes:

- `.day-shift/templates/task-definition.md`
- `.day-shift/templates/implementation-summary.md`

When creating the task definition, populate the lifecycle/closure expectations so completed tasks can be marked closed consistently after implementation.

## Required Output

Create a task directory with the canonical heading order from the template contract:

- `task-definition.md` with the configured template sections and valid front matter
- `implementation-summary.md` initialized as pending
