---
prompt_version: 1
layer: specification
action: next
---

# Prompt: Specification To Slice Overview

Use the selected specification or specification slice and Day Shift agent entrypoint to create the next planning layer: a slice overview.

## 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 `specification` layer: it advances only from specification context into slice planning. Do not reuse it as `build`, `review`, or as permission to skip directly to phase, milestone, task, or reconciliation artifacts.
- Use this prompt only when the user explicitly asks to advance planning, such as `plan from spec`, `create slice`, `start planning`, `create next planning layer`, or `scaffold slice`, or when an existing workflow command selected spec-to-slice creation as the active write.
- Do not treat `create spec`, `capture spec`, `draft spec`, `revise spec`, or `update spec` as permission to create a slice overview or mutate `linked_slice` registry metadata.
- When the request is source-spec creation or revision, stop after the source spec and registry entry; do not create planning artifacts.
- When planning advancement is intended, the command recovery path is `<day-shift-cli> slice new --spec-id <id>` through `.day-shift/workflows/02-plan-from-spec.md`; this prompt does not convert source-spec review, hardening, second-pass, improvement, navigation, or completeness wording into downstream writes by itself.
- 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.
- Identify the ordered slice directory, stable slice slug, source spec reference, planning depth, and intended destination.
- Derive the destination planning root as `.day-shift/planning/<implementation-order>-<slice-slug>/slice-overview.md` from registered spec context, using `implementation_order` as the ordered prefix and the selected slice context as the stable source of `<slice-slug>`. Existing slice `overview.md` artifacts remain supported legacy inputs, not generated destinations for new scaffolds.
- Support planning from one selected specification or from several related specifications treated as one planning slice.
- Preserve traceability to the original specification or specification slice.
- Use list-based `upstream.specs` as the default traceability shape, preserving each contributing source spec for shared slices. For single-spec cases, prefer a one-entry `upstream.specs` list and keep `upstream.spec` only for compatibility-sensitive cases when needed.
- When the slice scope includes source/upstream traceability update work, treat `upstream.specs`, compatibility-sensitive `upstream.spec`, and specification-family `source` references as one contract surface: apply intended values directly and reject incomplete or lossy partial rewrites.
- When the slice scope includes planning-coordinate update work, require one explicit contract statement covering `slice`/`phase`/`milestone`/`task` plus `planning_depth` applicability, explicit coherent transition scenarios, coordinated applicable-field updates (including parent-link paths when affected), and rejection of partial or contradictory coordinate rewrites.
- Shared-slice example: the three specs under `.day-shift/specs/05-planning-artifacts/` map to one canonical slice overview destination at `.day-shift/planning/governed/05-planning-artifacts/slice-overview.md`; preserve all three sources in `upstream.specs`.
- Carry the upstream `source.ref` forward as a generic source-spec reference instead of assuming a repository-root spec filename.
- Keep strict-mode expectations artifact-specific: preserve shared schema discipline without inventing downstream planning-only metadata on the specification input.
- When slice scope includes metadata-update utility work, preserve one shared read/parse contract in the slice narrative: metadata-bearing family detection, metadata-region extraction boundaries, and parse failure behavior.
- Keep read/parse extraction guidance distinct from write-policy guidance so downstream tasks can document mutation semantics without rewriting read/parse rules.
- Summarize scope without turning the slice overview into a task list.
- Propose phases only when standard planning is appropriate.
- In a standard generated slice overview, `## Phases` must declare at least one ordered phase slug with a short description. Before link materialization, use raw backticked slug bullets such as ``- `01-runtime-and-context`: establish shared runtime and repository context behavior.``. After link materialization, the same declaration may be a Markdown link bullet such as `- [01-runtime-and-context](phases/01-runtime-and-context/phase-overview.md): establish shared runtime and repository context behavior.`.
- In the same `## Phases` section, state `Target phase count: N` with `N` exactly matching the number of declared phase slugs, followed by an authored `Decomposition rationale:` that names the concrete implementation, dependency, validation, rollback, or ownership boundaries that justify this phase set. Counts, names, numbering, and ordering alone are not a rationale.
- Phase slugs declared in standard slice overviews must match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`, be unique, and appear in ascending order.
- Do not leave prose-only phase bullets or placeholder phase text such as `To be planned.`, `TBD`, `TODO`, or `Pending.` in saved standard slice overviews.
- For lightweight work, explain why phase and milestone planning can be skipped.
- Use the spec `implementation_order` when naming planning slice directories created from registered specs.
- When creating a new slice overview, create the ordered slice directory as part of the same step, and initialize `decisions/` and `notes/` with `.gitkeep` so slice-level notes and decisions have stable homes from the start.
- Create or update `linked_slice` registry metadata only after the real slice overview exists with valid scaffold provenance and the required slice companion directories.
- If future tooling suggests additional child artifacts, treat that as non-mutating guidance only; suggestion output does not authorize artifact-creating writes or expansion beyond the requested slice-overview step without explicit user direction.
- If the user later asks for explicit full-set expansion from a parent overview, follow the canonical declared-child contract: iterate only already declared children in declared order, apply the standard next-layer creation contract per child, and reject undeclared children.
- Full-set expansion is layer-local. A later request to create all phases from the created slice authorizes phase overviews only; it does not authorize milestone, task, implementation-summary, or reconciliation scaffolding 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 after slice creation; report candidate next artifacts and stop unless the user explicitly asks to create the next layer.
- After creating the slice overview, run `<day-shift-cli> validation links-check --scope planning --artifact <slice-overview-path>` as read-only local trace-link evidence. Because spec-to-slice creation has no previous planning-layer parent artifact, run `<day-shift-cli> link materialize --dry-run --artifact <slice-overview-path>` on the created slice overview itself 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, using the exact `validationEvidence.evidenceId` returned by that dry run. `<day-shift-cli> validation smoke --scope planning --artifact <slice-overview-path>` may be used to check the `declared-child-slugs` lane for standard phase 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 create downstream artifacts.
- When template selection, template version, or template registration is unclear while preparing the next artifact shape, use `<day-shift-cli> templates list` as the read-only template-family inventory surface before inventing local template assumptions.
- 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.
- 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 in the saved artifact.
- Treat templates as output shape only: do not copy instructional or scaffolding prose into generated artifacts.
- Replace every canonical placeholder token with slice-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 invent or guess missing content.
- Remove 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 artifact.

## Template Reference

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

## Required Output

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

- YAML front matter for slice, status, and upstream traceability (default to list-based `upstream.specs`; use `upstream.spec` only for compatibility-sensitive single-spec cases)
- Purpose
- Source Specification
- Desired Outcome
- Scope
- Non-Goals
- Planning Depth
- Phases, including the matching `Target phase count: N`, authored boundary-based `Decomposition rationale:`, and ordered phase declarations
- Decisions
- Risks
- Validation Strategy
- Open Questions

Also create the destination slice directory when it does not exist yet, and initialize `decisions/.gitkeep` and `notes/.gitkeep` when the destination slice directory is new.
