---
prompt_version: 1
layer: slice
action: review
---

# Prompt: Review Slice Overview

Review the selected slice overview for completeness and alignment with the upstream specification, or compare it against downstream evidence when phase, milestone, or task work already exists.

## 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.
- For readiness review, determine whether the slice is ready for the next planning instruction, not only whether its current metadata already says so.
- For readiness review, evaluate planning readiness rather than downstream completion. A slice should not be treated as blocked merely because phase, milestone, or task artifacts have not been produced yet.
- For readiness review, verify scope, non-goals, planning depth, validation strategy, risks, and open questions.
- For readiness review, verify that phase decomposition uses the minimum number of phases needed to fully implement the slice and is justified by real implementation, sequencing, validation, rollback, ownership, risk, or readiness boundaries.
- For standard slice overviews, verify that `## Phases` uses ordered phase slug declarations with short descriptions. Accept both 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.`. In either representation, each link label or raw slug must match `^\d{2}-[a-z0-9]+(?:-[a-z0-9]+)*$`, and declared phase slugs must be unique and ascending.
- For lightweight slice overviews with `planning_depth: lightweight`, do not require phase slug declarations; verify that `## Phases` explicitly states phase artifacts are skipped and direct lightweight tasks are the next planning layer.
- When child declaration syntax is in question, use `<day-shift-cli> validation smoke --scope planning --artifact <slice-overview-path>` and inspect the `declared-child-slugs` lane as read-only evidence; that lane accepts both raw backticked slug bullets and materialized Markdown-link slug bullets.
- Flag a warning when phase count appears over-split, prose-only, pattern-driven, or based on inferred detail that should remain in the slice overview.
- Flag a warning when `define` is used as an action verb without clearly naming a contract, boundary, schema, vocabulary, policy, rule, interface, or decision deliverable. If the intended work is initialization, implementation, documentation, evidence capture, review, or validation, recommend the more specific verb.
- For readiness review, check whether downstream phase, milestone, or task evidence has already resolved prior open questions, reduced uncertainty, or filled earlier planning gaps.
- When both are available, prefer direct source surfaces over prior summaries when resolving readiness questions: use the current specification, slice overview, workflow guidance, prompt contracts, templates, and downstream artifact files before relying on earlier `implementation-summary.md` or reconciliation artifacts.
- Use prior summaries and reconciliation artifacts as supporting evidence for what was previously changed or decided, not as the strongest proof of the current repository contract when the underlying source surfaces are already available locally.
- For readiness review, resolve recurring planning questions from existing repository evidence before escalating them: use the slice overview, upstream spec, downstream artifacts, workflow guidance, prompt contracts, and review findings to answer scope, planning-depth, validation-strategy, metadata-transition, and downstream-handoff questions whenever those surfaces already establish the default.
- For readiness review, prefer contract-based default answers over open-ended human prompts when the repo already defines the boundary. If the slice, spec, or workflow clearly establishes the expected planning lane, record that answer directly instead of asking the user to restate it.
- When more than one interpretation is possible, escalate only if the choice would materially change slice scope, child-phase planning, or produce conflicting writes. If one interpretation is clearly favored by declared scope plus repository contracts, state that assumption explicitly and treat it as resolved review guidance rather than a pending human decision.
- For evidence review, compare the slice overview against completed downstream phase, milestone, and task evidence.
- For evidence review, detect stale downstream planning metadata that no longer matches completed phase or milestone evidence.
- Check that slice-level content has not drifted into detailed task implementation.
- Confirm that upstream spec traceability is clear.
- Check that front matter matches the body, especially status, planning depth, and any upstream traceability changes.
- After downstream reconciliation exists, check whether reviewed phase or milestone overviews still carry stale metadata such as `status: draft` despite unambiguous completion evidence.
- If the body is ready for the next planning step but the front matter has not yet been updated to reflect the available evidence, treat that as a metadata-update recommendation rather than an automatic planning blocker.
- Treat stale metadata as a blocking issue only when it creates real ambiguity about whether downstream planning should proceed, or when the body still lacks enough evidence to justify advancing the metadata.
- List stale downstream metadata as a metadata-hygiene or administrative follow-up item when the evidence is clear, and recommend the exact explicit update or sync command when the next write is deterministic.
- Keep review output read-only unless the current user request separately and explicitly asks for a metadata update, sync, or administrative write action.
- Do not perform metadata-hygiene or administrative follow-up merely because it is mechanical; report it under `Metadata-Hygiene Follow-Ups`, `Administrative Follow-Ups`, or `Metadata Updates Needed`.
- For readiness review, distinguish between missing downstream evidence and missing slice-level planning clarity. Only missing planning clarity should block the next planning instruction.
- Identify whether phases can be created safely when planning has not started yet.
- Identify whether any phase candidates should be merged or split because the current count is not decomposition-driven.
- Identify any slice-level scope, non-goals, risks, validation strategy, or open questions that were not actually satisfied when downstream evidence exists.
- Review output is read-only guidance unless a separate explicit update, sync, or write request applies. It may recommend candidate phases, milestones, tasks, metadata commands, or follow-up planning, but it must not create or mutate artifacts.
- Do not treat `move downstream`, `plan next work`, `identify follow-up work`, or `suggest next step` as permission to scaffold child artifacts during review. Report the proposed next planning structure and stop unless the user separately invokes the matching `next` prompt or an explicit create/scaffold command.
- Do not recommend scaffolding later declared phases ahead of incomplete earlier siblings unless the review records an explicit user-requested skip-ahead exception.
- Treat `User Decisions Needed` as a narrow exception output. Use it only for genuine external choices such as product intent, priority tradeoffs, or materially conflicting evidence that cannot be resolved from repository context. Do not put ordinary contract interpretation, metadata advancement recommendations, next-step guidance, or purely mechanical metadata-hygiene or administrative cleanup there.

## Required Output

Return findings grouped as:

- Blocking Issues
- Missing Evidence
- Warnings
- Review Mode
- Next Planning Recommendation, if this is a readiness review
- Metadata Updates Needed, if this is a readiness review and the evidence supports advancing status or planning metadata
- Satisfaction Status, if this is an evidence review
- Metadata-Hygiene Follow-Ups
- Administrative Follow-Ups
- User Decisions Needed
- Suggested Next Step

For readiness review, explicitly state:

- whether open questions are now resolved by downstream evidence
- whether more slice-level planning is still needed before creating phases
- what metadata updates should be made before the next planning instruction
- whether any cited gap is a true pre-planning blocker or only expected downstream evidence
- whether any previously open planning question was answered from repository contracts or existing evidence without requiring new human input
