---
prompt_version: 1
layer: slice
action: next
---

# Prompt: Slice To Phase Overview

Use the selected slice overview to create the next phase overview, or iterate that same phase-creation contract across all phases declared in the slice 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.
- This prompt is the canonical `next` action for the `slice` layer: it advances only from a slice overview into phase planning. Do not reuse it as `build`, `review`, or as permission to skip directly to milestones, tasks, implementation work, or reconciliation artifacts.
- 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.
- Choose a phase slug and title that describe a coherent slice of the work.
- Use an ordered phase slug when sequence matters.
- Keep the phase focused on outcomes, scope, dependencies, risks, and validation focus.
- Create the minimum number of phases needed to fully implement the slice; a slice may legitimately need one phase when that phase is enough.
- Do not create a prose-only phase just to elaborate inferred slice detail. Keep that detail in the slice unless it creates a real downstream implementation or review boundary.
- Avoid milestone-level task detail.
- The selected standard slice overview's `## Phases` section must use ordered phase slug declarations with short descriptions. Accept raw backticked slug bullets such as ``- `01-runtime-and-context`: establish shared runtime and repository context behavior.`` and materialized Markdown-link slug bullets such as `- [01-runtime-and-context](phases/01-runtime-and-context/phase-overview.md): establish shared runtime and repository context behavior.`.
- Declared phase slugs must match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`, be unique, and appear in ascending order; prose-only phase bullets and placeholder phase text such as `To be planned.`, `TBD`, `TODO`, or `Pending.` are invalid.
- In a generated phase overview, `## Milestones` must declare at least one ordered milestone slug with a short description. Before link materialization, use raw backticked slug bullets such as ``- `01-license-payload-contract`: define signed payload parsing and canonicalization behavior.``. After link materialization, the same declaration may be a Markdown link bullet such as `- [01-license-payload-contract](milestones/01-license-payload-contract/milestone-overview.md): define signed payload parsing and canonicalization behavior.`.
- Milestone slugs declared in phase overviews must match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`, be unique, and appear in ascending order.
- Do not leave prose-only milestone bullets or placeholder milestone text such as `To be planned.`, `TBD`, `TODO`, or `Pending.` in saved phase overviews.
- Label assumptions explicitly instead of silently inventing scope, sequence, or validation detail.
- Create the slice `phases/` directory first when it does not exist yet, then create the phase directory beneath it.
- Preserve traceability to the slice overview and source spec.
- Keep parent traceability explicit in phase metadata by setting `upstream.slice_overview` to the repository-relative parent slice overview path.
- 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.
- If the slice is lightweight, explain that a phase should not be created unless the work has grown.
- When several phases are created across one slice, use the slice's declared phase sequence.
- For explicit full-set requests, iterate the same standard phase-creation contract for each declared child phase in order rather than inventing a separate batch contract.
- Full-set requests at the slice layer are layer-local: create phase overviews only. Do not create milestones, tasks, implementation summaries, reconciliation artifacts, or nested child scaffolds beneath those phases unless a separate explicit programmatic nested-scaffold request names those layers.
- 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 phases and stop unless the user explicitly asks to create the phase layer.
- Do not scaffold a later declared phase while earlier declared phases remain incomplete unless the user explicitly names that skip-ahead exception.
- Treat any future wizard-generated phase suggestion as assistive guidance only; suggestion output does not authorize artifact-creating writes unless the user explicitly asks for creation.
- Do not invent additional phases that are not already declared in the slice overview unless the user explicitly asks to revise the slice overview first.
- Reject undeclared phases during full-set expansion instead of synthesizing new hierarchy.
- After creating phase overviews, run the previous planning layer's link validator: `<day-shift-cli> validation links-check --scope planning --artifact <slice-overview-path>`. Then run `<day-shift-cli> link materialize --dry-run --artifact <slice-overview-path>` and use `<day-shift-cli> link materialize --write --artifact <slice-overview-path>` only when the dry-run reports safe selected-artifact body-reference changes for newly resolvable phase links. `<day-shift-cli> validation links-check --scope planning --artifact <phase-overview-path>` may also be used as read-only local trace-link evidence for each child phase, and `<day-shift-cli> validation smoke --scope planning --artifact <phase-overview-path>` may be used to check the `declared-child-slugs` lane for milestone declaration syntax; that 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 or scaffold downstream milestones.
- 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.
- Use repository-relative paths throughout the artifact.
- 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` none-state, and no leaked scaffolding prose or unresolved placeholders in the saved artifact.

## Template Reference

Use `.day-shift/templates/phase-overview.md` as the artifact shape.

## Required Output

Create a phase overview artifact with the canonical heading order from the template contract:

- Purpose
- Scope
- Milestones
- Acceptance Criteria
- Dependencies
- Risks
- Validation Focus
- Open Questions
