# Spar Retain

> Use after implementation when the user approves closeout. Reconcile the active spec and plan with what shipped, propose broader documentation updates for approval, then move the whole change folder from specs/active to specs/completed.

- Skill: `jed-tech/spar-retain` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jed-tech/spar-retain`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jed-tech/spar-retain/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Jed-Tech (https://skillmd.com/u/jed-tech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jed-tech/spar-retain

---


# Retain

Turn completed implementation into durable project knowledge.

Retain is closeout, not a retrospective by default. Make the active spec and
plan accurate, preserve useful context, update broader docs only with approval,
then archive the whole change folder.

## Inputs

- `specs/active/<change-name>/<change-name>_spec.md`
- `specs/active/<change-name>/plan.md`
- Completed implementation in the repository
- Optional notes or artifacts in the same change folder
- Relevant repo documentation, such as README, setup, architecture, or product docs

If implementation appears incomplete, stop and ask whether to return to
`spar-act`.

## Retention Context

Before editing, review the spec, plan, implementation changes, validation
results, and optional notes. Preserve optional artifacts unless the user asked to
remove them or they are clearly obsolete.

The retained folder should explain what shipped and why it matters without
becoming a noisy build log.

## Reconcile the Spec

Update `<change-name>_spec.md` so it describes final behavior and durable intent.

- Keep `Summary`, `Problem`, `Scope`, and `Out of Scope` accurate.
- Update `Constraints` if implementation revealed durable requirements.
- Update `Success Criteria` so they reflect the outcomes that shipped and were
  validated.
- Update `Decisions` with important product or technical choices discovered
  during implementation.
- Resolve or remove stale `Open Questions`; keep only questions that materially
  affect future implementation or validation.

Do not add step-by-step implementation narrative to the spec.

## Reconcile the Plan

Update `plan.md` so it remains a useful execution record.

- Ensure `Tasks` are checked or explicitly explained.
- Ensure `Validation Strategy` reflects what actually ran or what could not be
  validated.
- Ensure `Risks / Follow-ups` captures unresolved risks, deferred work, or
  follow-up decisions.
- Ensure `Approach` and `Execution Constraints` do not contradict what shipped.
- Remove only scratch notes or duplicate lines that would confuse future readers.

## Documentation Updates

Identify broader documentation impact from the final spec, plan, implementation
changes, and repo docs.

If broader docs should change, propose concrete edits and ask for approval before
applying them. Do not silently edit repo-wide documentation.

If no broader documentation updates are warranted, say so briefly in the final
summary so the user knows it was considered.

## Archive the Change

Move the entire folder:

`specs/active/<change-name>/` -> `specs/completed/<change-name>/`

Create `specs/completed/` and `specs/completed/<change-name>/` if needed. Do
not leave a copy under `specs/active/`. If a destination file already exists,
stop and ask how to resolve it; do not overwrite or merge file contents silently.

## Stop Conditions

Stop and ask if:

- Implementation appears incomplete.
- Validation is missing and cannot be explained honestly.
- Final behavior contradicts the spec in a way the user has not approved.
- Broader documentation changes are needed but not yet approved.
- A destination file already exists in `specs/completed/<change-name>/`.

## Completion

Retention is complete when:

- The spec matches the implementation.
- The plan reflects completed or explained work.
- Approved documentation updates are applied, or none were needed.
- The change folder exists only under `specs/completed/<change-name>/`.

Then summarize concisely with genuine enthusiasm for the completed change: final
archived path, spec and plan reconciliation, documentation updates made or
skipped, and any retained follow-ups. Emphasize that the completed folder is the
durable source of truth for what shipped.

## Artifact Recap

| Artifact | In this phase |
| --- | --- |
| `<change-name>_spec.md` | Final behavior, durable intent, constraints, success criteria, decisions, and material open questions |
| `plan.md` | Final task state, validation record, risks, and follow-ups |
| `specs/completed/<change-name>/` | Archived source of truth for the shipped change |