---
name: dcp
description: >
  Triggered by the user command ".DCP". Updates in-repo documentation and
  .labyricorn devlog records to reflect recent work, then commits and pushes
  all changes to origin/main (production). Run this skill whenever the user
  issues ".DCP".
---

# DCP — Document, Commit, Push

The user command `.DCP` means: bring documentation and Labyricorn publishing
records up to date with the current state of the codebase, then commit
everything and push to production (`origin/main`).

Read this file fully before starting. Also read:
- `AGENTS.md` (root) — communication and authorization rules
- `.labyricorn/AGENTS.md` — publishing boundaries and content contract
- `.labyricorn/devlog/AGENTS.md` — devlog entry format and safety rules
- `.labyricorn/project/AGENTS.md` — project record rules

---

## Phase 1 — Orient

1. Run `git log --oneline -10` to see the most recent commits since the last
   `.DCP` run (look for the previous "docs:" or "devlog:" commit to find the
   boundary).
2. Run `git diff --stat HEAD` (or `git status`) to see any uncommitted changes.
3. Identify what changed: new features, bug fixes, refactors, renamed
   files, config changes, dependency updates, etc.
4. Note today's date (`YYYY-MM-DD`) and the **full 40-character commit SHA**
   of the most recent relevant commit (`git rev-parse HEAD`).

---

## Phase 2 — Update In-Repo Documentation

Update any documentation files that are stale relative to the current
implementation. This includes:

- `README.md` — feature lists, setup steps, API examples, port numbers,
  binary names, MCP config snippets, environment variable names
- `CHANGELOG.md` — add an `[Unreleased]` entry or append to the current one
  summarizing what changed (use the draft-release-notes skill format if
  already in use)
- `docs/` content — any `.mdx` / `.md` files whose prose contradicts or
  omits the current implementation
- `backend/README.md` — if API or server behavior changed
- Any other doc whose claims are now incorrect

**Rules:**
- Only update what is actually stale. Do not rewrite correct documentation.
- Do not alter application source code as part of a `.DCP` run.
- After edits, run `git diff --check` to confirm no whitespace errors.

---

## Phase 3 — Update .labyricorn Devlog

Create or update devlog entries for the milestones reached since the last
`.DCP`. Follow `.labyricorn/devlog/AGENTS.md` strictly.

### Entry location
`devlog/<stable-slug>/contents.lr` — one entry per meaningful milestone.
If multiple milestones occurred since the last `.DCP`, create multiple entries.

### Required fields (all mandatory)
```
_model: devlog-entry
schema_version: 1
title: <Human-readable title>
date: <YYYY-MM-DD of source_commit>
author: Labyricorn
summary: <One-sentence summary suitable for a chronological listing>
tags: <Comma-separated display labels, e.g. tts, ui, backend, mcp, release>
source_commit: <Full 40-character lowercase commit SHA>
---
body:

<Markdown prose — explain the milestone, why it mattered, what changed.
Do NOT merely expand a commit message. Do NOT invent results, user feedback,
or completion claims. Distinguish design from shipping behavior.
Link to the commit using the repo HTTPS URL.>
```

### Update the devlog index
Ensure `.labyricorn/devlog/contents.lr` lists any new entry slug in its
`entries` field (if the schema uses an index).

### Update project record if needed
If the project status, summary, or description at
`.labyricorn/project/contents.lr` is stale, update it. Ask before changing
`project_id`, `repository_url`, `default_branch`, or `author`.

### Validate
Run:
```
python devlog_editor.py --validate
```
Fix any validation errors before proceeding. If the script is unavailable,
manually verify all required fields are present in every touched record.

---

## Phase 4 — Commit

Stage only the documentation and `.labyricorn/` changes:

```
git add README.md CHANGELOG.md docs/ .labyricorn/
# Add any other doc files that were updated
git add <any other updated doc files>
```

Do **not** stage unrelated application source changes unless the user
explicitly included them in the current session's work.

Run `git diff --check --cached` to confirm no whitespace errors in staged
files.

Commit with a message in this format:

```
docs: update documentation and devlog for <brief description>

- Updated README.md: <what changed>
- Updated CHANGELOG.md: <what changed>
- Added devlog entry '<slug>': <one-line summary>
- Updated project record: <what changed> (if applicable)
```

---

## Phase 5 — Push

```
git push
```

This pushes to `origin/main` (production). Confirm the push succeeded and
report the final commit SHA and push status to the user.

---

## Handoff report

After completing all phases, tell the user:
1. Which documentation files were updated and what changed
2. Which devlog entries were created or updated (with their slugs and dates)
3. The commit SHA and message
4. Push status (succeeded / failed + error)
5. Any items that need follow-up (e.g. validation warnings, stale docs
   that need more information from the user before they can be updated)