---
prompt_version: 1
layer: specification
action: recertify
---

# Prompt: Recertify Specification

Review the selected specification or related specification set against current repository evidence, implemented behavior, active workflow direction, and downstream planning state. Decide whether the specification should remain active as-is, be updated, be collapsed with related specs, be deferred, be marked superseded, or be removed from the active spec registry.

## 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.
- Use this prompt when a specification may have become stale because implementation has progressed, command behavior has diverged, related specs have been merged or split, or downstream planning has already satisfied part of the original scope.
- Treat recertification as specification lifecycle hygiene, not as implementation authorization.
- Support recertification of one selected specification or several related specifications that map to the same planning slice.
- Compare the specification against current repository evidence before deciding disposition:
  - implemented CLI commands and tests
  - existing planning slices, phases, milestones, tasks, implementation summaries, and reconciliation artifacts
  - current workflow and prompt guidance
  - `.day-shift/specs/index.json` registry entries
- Separate stale wording from stale direction. A specification can need an update even when the underlying goal remains valid.
- Do not carry forward already-implemented behavior as future scope.
- Do not preserve outdated command names, path conventions, validation profiles, or artifact requirements merely because they appear in older source material.
- If multiple specifications now describe one active concern, recommend collapsing them into one active specification and removing duplicate active index entries.
- If a specification is fully implemented or replaced by newer direction, recommend marking it superseded or removing it from active planning input rather than leaving it as active roadmap scope.
- If a specification remains valid but should not be planned soon, recommend deferral instead of deleting it.
- If removal or collapse is recommended, identify required `.day-shift/specs/index.json` changes and any dangling-reference checks that must be performed.
- Preserve historical traceability where useful, but keep the active registry focused on current planning inputs.
- Keep the review read-only unless the user explicitly asks you to apply the recertification changes.
- When applying changes, update the specification file and `.day-shift/specs/index.json` in the same pass, then check for dangling references to deleted or collapsed spec ids and paths.
- Recertification, second-pass review, hardening, and improvement requests do not authorize downstream planning artifacts. Stop after source-spec and registry cleanup unless the user explicitly asks to plan from the spec, create a slice, start planning, create the next planning layer, or scaffold the slice.
- Do not add or update `linked_slice` registry metadata during recertification unless the referenced slice overview already exists with valid scaffold provenance and required slice companion artifacts.

## Disposition Options

Use one of these dispositions for each reviewed specification:

- `keep-active`: the specification remains current, valid, and useful as active planning input.
- `update-active`: the goal remains valid, but wording, scope, commands, metadata, or traceability are stale.
- `collapse`: the specification should be merged with related active specifications into one current planning input.
- `defer`: the specification remains valid but should not be treated as near-term active planning scope.
- `superseded`: the specification has been implemented, replaced, or made obsolete, but should remain available for historical traceability.
- `remove-from-active-index`: the specification should no longer appear as an active registry entry because it is obsolete, duplicate, or no longer useful as planning input.

## Required Output

Return findings grouped as:

- Recertification Scope
- Current Evidence Reviewed
- Disposition By Specification
- Active Scope To Preserve
- Stale Or Implemented Scope To Remove
- Collapse Or Split Recommendations
- Registry Updates Needed
- Workflow Or Prompt Updates Needed
- Dangling Reference Checks
- User Decisions Needed

For each disposition, state:

- the spec id and path
- the recommended disposition
- why that disposition follows from current evidence
- whether file edits are needed
- whether `.day-shift/specs/index.json` must change
