---
prompt_version: 2
layer: specification
action: build
---

# Prompt: Build Specification

Use the provided request, notes, source material, and repository context to draft or refine a Day Shift specification.

## 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.
- Creating or revising a source spec does not create planning artifacts. Stop after the source spec and registry entry unless the user explicitly asks to create the next planning layer.
- Treat `create spec`, `capture spec`, `draft spec`, `revise spec`, and `update spec` as source-spec-only intent. Do not create a slice overview, planning directory, or `linked_slice` registry metadata from those requests.
- Treat `plan from spec`, `create slice`, `start planning`, `create next planning layer`, and `scaffold slice` as planning-advancement intent that belongs to `.day-shift/prompts/user/specification.next.md` and the command-supported workflow.
- Verify the configured CLI when command-supported discovery or validation is needed, and keep this prompt responsible for authored specification content that the CLI cannot infer deterministically.
- Preserve user intent and call out assumptions clearly.
- Prefer repository-relative references.
- Use repository-relative paths throughout the artifact.
- Carry forward a generic source-spec reference in `source.ref` instead of assuming a file named `root-spec.md`.
- If the specification is an emergent intake item, preserve that explicitly through origin details such as user-testing, environment failure, production incident, or operator-reported blocker.
- Keep the specification at the right depth for the risk and scope.
- If the work is narrow and low risk, note whether lightweight planning may be enough.
- Do not invent acceptance criteria, constraints, or source details without labeling them as assumptions.
- Stop and report instead of guessing when the selected source material and upstream evidence conflict materially.
- 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.
- Preserve the exact ordered H2 contract: `Purpose`, `Problem Statement`, `Desired Outcome`, `Non-Goals`, `Scope`, `Constraints`, `Success Criteria`, and `Open Questions`. Do not emit the legacy `Summary`, `Problem`, `Goals`, or `Risks` headings.
- Keep lifecycle authority explicit: `spec create` writes only the draft specification and registry entry, `spec review` is the separate read-only readiness assessment, and `spec disposition` is the later revision-bound planning-readiness write. Building or revising specification content performs neither review nor disposition.

## Template Reference

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

## Required Output

Create or update a Markdown specification with these sections:

- Purpose
- Problem Statement
- Desired Outcome
- Non-Goals
- Scope
- Constraints
- Success Criteria
- Open Questions
