---
prompt_version: 2
layer: specification
action: review
---

# Prompt: Review Specification

Review the selected specification or specification slice for completeness, traceability, and either readiness for downstream planning or satisfaction against downstream evidence.

## 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.
- Support review of one selected specification or several related specifications treated as one planning slice.
- For readiness review, determine whether the specification 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 specification should not be treated as blocked merely because downstream planning or implementation artifacts have not been produced yet.
- For readiness review, check whether the specification has enough information for its declared depth and whether planning can proceed safely.
- Verify one visible H1 followed by exactly these H2 headings in order: `Purpose`, `Problem Statement`, `Desired Outcome`, `Non-Goals`, `Scope`, `Constraints`, `Success Criteria`, and `Open Questions`. Treat legacy `Summary`, `Problem`, `Goals`, or `Risks` H2 headings as contract drift.
- For readiness review, check whether downstream planning or implementation evidence has already resolved prior open questions, reduced uncertainty, or filled earlier planning gaps.
- For evidence review, compare the specification or specification slice against completed downstream planning and implementation evidence.
- If the source is a directory with multiple files for the same implementation slice, evaluate them together and preserve traceability to each source file.
- Identify missing or weak sections, unsatisfied success criteria, unresolved constraints, and open questions that remain unanswered.
- 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.
- Separate true blockers from useful follow-up questions.
- Check that front matter matches the body, especially status, planning depth, and source traceability.
- 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.
- For readiness review, distinguish between missing downstream evidence and missing specification-level planning clarity. Only missing planning clarity should block the next planning instruction.
- Do not silently absorb newly discovered work into the current specification; record it as follow-up planning, discovered work, or backlog work instead.
- Do not rewrite the whole specification unless asked.
- Recommend standard or lightweight planning based on risk, scope, and uncertainty when downstream planning has not started yet.
- Review output is read-only guidance unless a separate explicit update, sync, or write request applies. It may recommend a slice, phase candidates, follow-up planning, or metadata commands, but it must not create or mutate artifacts.
- Preserve the create-review-disposition boundary: `spec create` owns the draft specification and registry write, `spec review` remains read-only, and only a later explicit `spec disposition` command may record the revision-bound planning-readiness decision.
- Do not treat `move downstream`, `plan next work`, `identify follow-up work`, or `suggest next step` as permission to scaffold 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.
- If the review is a second pass, hardening pass, improvement pass, navigation pass, completeness review, or readiness discussion, edit only the selected source spec when edits are requested. Do not create downstream planning artifacts or mutate `linked_slice` unless the user explicitly asks to advance from spec to slice.
- Treat `create spec`, `capture spec`, `draft spec`, `revise spec`, and `update spec` as source-spec-only intent. Treat `plan from spec`, `create slice`, `start planning`, `create next planning layer`, and `scaffold slice` as planning-advancement intent.
- When planning advancement is intended after review, use `<day-shift-cli> slice new --spec-id <id>` through `.day-shift/workflows/02-plan-from-spec.md` as a separate lifecycle action.

## Required Output

Return findings grouped as:

- Blocking Issues
- Warnings
- Suggested Improvements
- Open Questions
- Review Mode
- Recommended Planning Depth, 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
- User Decisions Needed

For readiness review, explicitly state:

- whether open questions are now resolved by downstream evidence
- whether more specification work is still needed before planning proceeds
- what metadata updates should be made before the next planning instruction
