---
prompt_version: 1
layer: implementation
action: build
---

# Prompt: Build Implementation Summary

Use the completed or partial implementation and task definition to create or update an implementation summary.

## 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.
- Create missing canonical artifacts only for the selected layer. When revising an existing artifact, update it in place and do not create sibling, child, paired, or alternate artifacts unless the current user request explicitly asks for that creation step.
- Record what changed without overstating completion.
- Inspect the task-scoped changed files and confirm the intended code changes landed without obvious errors, missing edits, or unintended drift from the task definition before marking implementation evidence complete.
- Preserve existing user-authored content when updating an existing implementation summary.
- When revising an existing implementation summary, refresh implementation status, task traceability, and other front matter metadata so it reflects the current implementation state rather than the original draft state. Use `<day-shift-cli> implementation-summary update` for CLI-supported implementation-summary metadata transitions when available; direct front matter edits require an explicit manual exception.
- Map results back to acceptance criteria.
- Record validation commands and outcomes.
- Preserve the originating task `execution_mode` in the implementation summary. Runtime and hybrid summaries must include Runtime Delta targets, runtime changed paths, executable validation evidence, or a structured validation exception for a blocked validation command; contract summaries must not claim runtime implementation.
- Record validation exceptions with the planned command, blocker, substitute evidence, residual risk, and follow-up validation path. Validation exceptions cannot substitute for missing runtime code changes.
- Classify scope as planned work, discovered work, or backlog work.
- Call out deviations, risks, and follow-ups.
- Stop and report instead of guessing when the selected artifact and observed implementation evidence conflict materially.
- Use `implementation_status`: `pending` or `completed`.
- If implementation is only partial, keep `implementation_status: pending` and describe partial progress in summary sections such as deviations or risks/follow-ups.
- When the paired task is complete, align the originating task definition separately with `<day-shift-cli> metadata sync-status-from-review --task-definition <path> --active-artifact <path>` or `<day-shift-cli> task update --task-definition <path> --active-artifact <path> --field readiness=completed --field status=completed` when supported; do not leave completed work in the `ready to implement` handoff state.
- 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/implementation-summary.md` as the artifact shape.

## Required Output

Create or update an implementation summary artifact with the configured template sections and valid front matter.
