---
prompt_version: 1
layer: task
action: review
---

# Prompt: Review Task Definition

Review the selected task definition for implementation readiness, or compare it against completed implementation evidence when implementation 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.
- Before relying on the rendered body, verify generated context identifies the requested prompt path, resolved layer and repository-relative path, source family, fallback trace, and user-layer destination; another source copy's presence is not active-prompt delivery evidence.
- Determine review mode first: readiness review (pre-implementation) or evidence review (post-implementation).
- For readiness review, run the Day Shift CLI readiness check before final findings:

```sh
<day-shift-cli> task readiness-review --task-definition [Relative Path To Task Definition]
```

- On any repeated or follow-up review request, assume repository state may have changed and rerun the readiness-review command plus any directly relevant artifact checks unless the orchestrator explicitly provides a verified unchanged-state guarantee for the same task path and workspace snapshot.
- Do not infer that a repeated request has the same answer merely because the prompt wording is unchanged; treat prior review output as stale unless unchanged-state evidence is explicit.
- Treat the CLI output as required review evidence: capture reviewed readiness, readiness status, missing evidence, dependency blockers, sequencing issues, handoff blockers, and review boundary warnings.
- If the CLI command cannot run, record that as a blocking issue and explain what prevented execution.
- If CLI findings and artifact evidence disagree, call out the mismatch explicitly and recommend the metadata or dependency-path update needed before implementation starts.
- For evidence review, do not use readiness-review CLI output as a completion gate; compare task definition claims directly against implementation evidence.
- For attributed runtime or hybrid evidence review, require the post-readiness, pre-write task-cycle baseline, fresh declared runtime paths, executable validation, empty ineligible-path evidence, and exact inherited acceptance IDs. Existing dirty files or mere file presence cannot satisfy current-cycle freshness.
- After a completed task, report the milestone's structured mode-balance result. When runtime acceptance remains pending after the configured contract streak, return the deterministic detect, execute-authorized-breakout, verify-freshness, rebuild-reconciliation, rerun-milestone-review, and rerun-phase-review sequence without writing or inventing work.
- For readiness review, determine whether the task is ready for the next implementation instruction, not only whether its current metadata already says so.
- For readiness review, evaluate implementation readiness rather than execution completion. A task that has not been run yet should not be penalized merely because its implementation summary is still pending or its closure criteria are not yet satisfied.
- Treat `<day-shift-cli> task review` as a read-only findings surface over the selected task definition plus its paired `implementation-summary.md` and any task-level `reconciliation.md` exception artifact that exists.
- Treat `<day-shift-cli> task review` as the evidence-evaluation step. When readiness review concludes `ready to implement` with no blockers and the only remaining action is advancing stale task-definition readiness metadata, recommend the explicit `<day-shift-cli> task update` command instead of writing during review.
- For readiness review, check readiness evidence: objective, upstream references, implementation target paths, current behavior, desired behavior, acceptance criteria, validation commands, rollback or recovery notes, risks, dependencies, constraints, assumptions, and open questions.
- For readiness review on traceability-shape tasks, verify the task defines allowed normalization cases, explicit rejection cases for incomplete/ambiguous/lossy updates, and preservation expectations for single-spec versus multi-spec distinctions.
- For readiness review on narrow metadata-update tasks, verify the contract preserves unaffected metadata keys, identity-bearing coordinates, repository-relative traceability paths, and unaffected body content unless broader rewrite behavior is explicitly in scope.
- For readiness and evidence review, 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.
- Verify that section boundaries are still clear: reference-only upstream artifacts should stay in `Upstream Context` or `Dependencies`, while `Implementation Target Paths` should identify the expected edit/create surface.
- For readiness review, do not expect implementation evidence from the current task unless the task has already been partially executed.
- For readiness review, check only whether already-existing upstream or sibling implementation evidence has resolved prior open questions, reduced uncertainty, or filled earlier evidence gaps that matter before implementation begins.
- When both are available, prefer direct source surfaces over prior summaries when resolving readiness questions: use the current spec, workflow, prompt, template, source, and test files named in the task before relying on earlier `implementation-summary.md` or reconciliation artifacts.
- Use prior summaries 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 implementation questions from existing repository evidence before escalating them: use the task definition, upstream planning artifacts, sibling summaries, workflow guidance, prompt contracts, and CLI findings to answer target-path, validation-shape, metadata-transition, and review-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 task, workflow, or spec clearly establishes the expected implementation 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 implementation scope or produce conflicting writes. If one interpretation is clearly favored by declared task 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 task definition against completed implementation evidence, including changed paths, validation results, deviations, and follow-up work.
- For evidence review, emphasize closeout consistency across the task definition, paired implementation summary, and any task-level reconciliation exception artifact.
- For evidence review on narrow metadata-update tasks, verify implementation evidence distinguishes targeted changes from untouched metadata surfaces and avoids lossy normalization or broad rewrites outside declared scope.
- For evidence review, inspect the task-scoped changed files and verify the intended code changes landed without obvious errors, missing edits, or unintended drift from the task definition.
- Verify that readiness or completion status matches the evidence.
- Check that front matter matches the body, especially readiness, status, and any upstream or target-path changes.
- If the body is implementation-ready 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 implementation blocker.
- If readiness review concludes `ready to implement`, no blockers remain, and the task-definition front matter still carries stale readiness metadata, recommend the exact explicit update command instead of writing during review:

```sh
<day-shift-cli> task update --task-definition [Relative Path To Task Definition] --active-artifact [Relative Path To Task Definition] --field "readiness=ready to implement"
```

  Keep review output read-only unless the current user request separately and explicitly asks for that metadata update/write action. Use `--active-artifact` only as a stateless handoff guard that must match the selected task-definition path; it does not authorize review to write. Do not change shared `status` or any other metadata during review.
- Treat stale metadata as a blocking issue only when it creates real ambiguity about whether implementation should proceed, or when the body still lacks enough evidence to justify advancing the metadata.
- For readiness review, do not report a pending implementation summary, unrun validation commands, or an unwritten final validation record as a blocking issue unless the task definition depends on a missing artifact that must already exist before implementation can begin.
- For readiness review, distinguish clearly between "this task is not finished yet" and "this task is not ready to start." Only the second case should produce a readiness blocker.
- Treat leaked template scaffolding and unresolved placeholders as readiness blockers because they indicate unfinished artifact rendering.
- In readiness/evidence review findings, flag and block on known leaked instruction strings: `Template notes:`, `Use this section to`, `List only`, `Keep only`, `If there are none, use exactly`.
- In readiness/evidence review findings, flag and block on unresolved placeholders matching the canonical Day Shift token pattern `{{[a-z_][a-z0-9_]*}}` when they appear as rendered artifact content; do not treat tokens inside Markdown inline code spans or fenced code blocks as incomplete rendering evidence when they are clearly documentary examples.
- Treat unresolved placeholder findings as evidence that rendering is incomplete, not as permission to infer or rewrite missing values during review.
- Identify missing pre-implementation evidence, implementation blockers, or acceptance criteria that are underspecified enough to prevent a safe start.
- Treat `User Decisions Needed` as a narrow exception output. Use it only for genuine external choices such as product intent, priority tradeoffs, reviewer-policy decisions, or materially conflicting evidence that cannot be resolved from repository context. Do not put ordinary contract interpretation, metadata advancement recommendations, or next-step guidance there.
- Confirm the task does not contain implementation summary or reconciliation content.
- Keep findings separated between blockers, warnings, and metadata-hygiene follow-ups; do not collapse the review into automatic acceptance or metadata mutation.

## Required Output

Return findings grouped as:

- CLI Check Result (readiness review only)
- Blocking Issues
- Missing Evidence
- Warnings
- Review Mode
- Readiness Recommendation, if this is a readiness review
- Metadata Updates Needed, if this is a readiness review and the evidence supports advancing readiness or status
- Satisfaction Status, if this is an evidence review
- Metadata-Hygiene Follow-Ups
- User Decisions Needed
- Suggested Next Step

For readiness review, explicitly state:

- whether the Day Shift CLI readiness-review command was run and the command outcome
- whether any already-existing upstream or sibling implementation evidence resolves open questions that should be recorded before implementation starts
- whether more task-level planning or decomposition is still needed
- what metadata updates should be made before the next implementation instruction
- whether readiness metadata needs an explicit follow-up update before implementation
- whether any cited gap is a true pre-implementation blocker or only expected post-implementation evidence
- whether any previously open implementation question was answered from repository contracts or existing evidence without requiring new human input
