Expédier une spécification Curaye

---

name: curaye-ship description: Graduate a completed Curaye spec from planned/ to shipped/, update the current/ layer, and optionally sync stack.md and CLAUDE.md. Use after /curaye-build when the implementation is done. The CLI handles mechanical file operations; this skill writes the current/ update with LLM comprehension, then proposes targeted edits to stack.md and CLAUDE.md when what shipped affects the tech stack or agent conventions. Pass the spec id as an argument. compatibility: Designed for Claude Code. Requires a Curaye-managed project and the curaye CLI installed. metadata: version: "0.1"

You are graduating a completed spec through the Curaye protocol ship flow. The CLI handles all mechanical file operations. Your job is the intelligent part: writing the current/ update that reflects what now exists.

The spec to ship: $ARGUMENTS

If no spec id was provided, scan .curaye/planned/ for files with status: building or status: done. If exactly one exists, use it and confirm with the user. If multiple exist, list them and ask which to ship.

Step 1 — Read the planned spec

Read the full planned spec from .curaye/planned/. Confirm you understand:

• The spec id, title, and tags
• What was built (from the goal and feature sections)
• Which domains are affected (use tags and the non-goals as guides)
• The acceptance criteria — these define what actually shipped

If status is draft or ready, stop: "This spec has not been built. Run /curaye-build $SPEC_ID first."

Step 2 — Call the CLI for mechanical graduation

Run the CLI ship command. It handles: creating the shipped/ document skeleton, deleting the planned spec, and updating the registry.

curaye ship <spec-id>

If the spec has a release field set, pass it:

curaye ship <spec-id> --release <release-value>

When the CLI prompts "Update current/ now?", answer n — you will handle this in the next step with full LLM comprehension rather than opening an editor.

Confirm the planned spec file is gone and shipped/<id>.md exists before continuing.

Step 3 — Write the shipped/ document body

The CLI creates the shipped/ document with frontmatter only. Open it and write the body:

> Shipped on <today's date>.

## What shipped

<2–4 specific sentences describing what was actually built. Reference concrete things: interfaces exported, commands added, files created, behaviour that now exists. This is the permanent historical record — be precise.>

## Changes to current/

<List each current/ document you are about to update, with one sentence per document describing the change. If a current/ document needs to be created, note it here too.>

## Notes

<Deviations from the spec, judgment calls, or items for follow-up specs. Omit section entirely if nothing to note.>

Save the shipped document.

Step 4 — Update current/

This is the core intelligent step. Read the existing current/ documents for the affected domains. For each:

1. Read it in full.
2. Determine what this shipped spec adds, changes, or removes in that domain.
3. Edit the document so it accurately describes the system as it exists now — present tense, no references to plans or intentions.
4. Update its updated frontmatter field to today's date.

If no current/ document exists for an affected domain, create one:

---
id: <domain-kebab>
title: <Domain Title>
domain: <domain>
updated: <today YYYY-MM-DD>
---

# <Domain Title>

## Overview

<What this domain is and what it does, as of today.>

Do not leave current/ unchanged unless the spec was a pure internal refactor with zero observable behaviour change — and even then, note this explicitly.

Step 5 — Sync stack.md and CLAUDE.md (optional, user-confirmed)

Reason about whether what just shipped has implications for the two meta-documents. These are not updated on every ship — only when something structurally changed.

stack.md is affected when the spec introduced:

• A new package or app in the monorepo
• A new runtime dependency (library, tool, runtime version)
• A removed or replaced dependency
• A new version pin or constraint

CLAUDE.md is affected when the spec established:

• A new package boundary rule or dependency constraint
• A new error-handling pattern or convention
• A new commit scope or type
• A new "what not to build" invariant
• A new per-package convention agents must follow

If neither document is affected, skip this step silently — do not mention it to the user.

If one or both are affected, present your proposed changes before writing anything:

stack.md needs updating:
  + js-yaml ^4.3.0 added as a runtime dependency of @curaye/core
  + @types/js-yaml added as a dev dependency

CLAUDE.md needs updating:
  + Note that js-yaml must be imported as named exports ({ load, dump }),
    not a default import, due to its CJS export shape

Apply these changes? [y/n/edit]
  y     — write both files as proposed
  n     — skip, no changes
  edit  — show me the diff first, I'll tell you what to adjust

Wait for the user's response before writing. If they say edit, show the exact lines you intend to add or change and wait for approval.

When approved, write the changes. Update the updated frontmatter field in stack.md if it has one.

Step 6 — Commit

Stage only .curaye/ changes. Derive the commit scope from the spec's first tag that maps to a CLAUDE.md scope (cli, desktop, web, core, protocol, ai, sync, ui, shared). Fall back to spec.

git add .curaye/ stack.md CLAUDE.md
git commit -m "$(cat <<'HEREDOC'
feat(<scope>): ship <spec-title>

Graduated planned/<id> → shipped/<id>. Updated current/<domains>.
<If stack.md or CLAUDE.md were updated, add a line: Updated stack.md / CLAUDE.md.>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
HEREDOC
)"

Step 6 — Report

• Spec shipped: id and title
• Shipped document: path
• current/ documents updated or created: list
• Commit: hash

"Ship complete. The living truth layer has been updated."