---
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.
- Keep implementation procedures and task execution steps out of the phase. The canonical phase shape still carries readiness-only prospective task contracts under `## Scaffold Evidence`, because phase readiness and milestone scaffolding consume those bounded identities, criterion assignments, target paths, validation commands, and rollback boundaries without creating task artifacts.
- 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.`.
- Before creating one phase or the declared full set, the parent `## Phases` section must state `Target phase count: N` with `N` exactly matching the declared phase slugs and an authored `Decomposition rationale:` naming concrete implementation, dependency, validation, rollback, or ownership boundaries. Do not infer this evidence from counts, names, numbering, or ordering.
- 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.`.
- In the same `## Milestones` section, state `Target milestone count: N` with `N` exactly matching the declared milestone slugs, followed by an authored `Decomposition rationale:` that names the concrete implementation, dependency, validation, rollback, or ownership boundaries that justify the milestone set. Counts, names, numbering, and ordering alone are not a rationale.
- A decomposition rationale may wrap across consecutive physical lines. Keep the wrapped lines in the same paragraph before the milestone bullets; the parser joins those lines before evaluating boundary evidence.
- 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.
- Use the complete canonical phase H2 shape from the template, including `Implementation Target Paths`, `Validation Commands`, `Rollback / Recovery`, and `Scaffold Evidence`; these are current phase readiness inputs, not optional CLI-only additions.
- Give each phase acceptance criterion a stable ID. Readiness accepts raw (`EW-AC-01:`), backticked (`` `EW-AC-01`: ``), or bracketed (`[EW-AC-01]`) labels and normalizes the ID independently of its Markdown decoration.
- Under `## Scaffold Evidence`, add one block per declared milestone in phase order. Each block must declare its `criterion_ids`, ownership, positive `target_task_count`, decomposition rationale, and exactly that many ordered prospective task entries with child-specific criterion IDs, current and desired behavior, dependency, target, validation, rollback, and any command-facing adapter path. These entries authorize later milestone projection only; they do not create task artifacts or permit implementation.
- Prospective task targets may use repository-native `src/`, `lib/`, `app/`, `apps/`, `components/`, `packages/`, `fixtures/`, `tests/`, or `tests_v2/` roots. Keep actual implementation targets under `target` and reserve `adapter` for a distinct command-facing adapter surface.
- 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> --validation-evidence-id <evidence-id>` only when the dry-run reports safe selected-artifact body-reference changes for newly resolvable phase links, using the exact `validationEvidence.evidenceId` returned by that dry run. `<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
- Navigation
- Milestones
- Acceptance Criteria
- Dependencies
- Risks
- Validation Focus
- Implementation Target Paths
- Validation Commands
- Rollback / Recovery
- Scaffold Evidence
- Open Questions
