TalkBox/.agents/skills/dcp/SKILL.md

name, description

name	description
dcp	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)