document-release

<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly --> <!-- Regenerate: just build -->

Preamble (run first)

# === RKstack Preamble (document-release) ===

# Read detection cache (written by session-start via rkstack detect)
if [ -f .rkstack/settings.json ]; then
  cat .rkstack/settings.json
else
  echo "WARNING: .rkstack/settings.json not found — detection cache missing"
fi

# Session-volatile checks (can change mid-session)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
_HAS_CLAUDE_MD=$([ -f CLAUDE.md ] && echo "yes" || echo "no")
echo "BRANCH: $_BRANCH"
echo "CLAUDE_MD: $_HAS_CLAUDE_MD"

Use the detection cache and preamble output to adapt your behavior:

• TypeScript/JavaScript — see detection.flowType (web or default). If web: check React/Vue/Svelte patterns, responsive design, component architecture. If default: CLI tools, MCP servers, backend scripts.
• Python — backend/ML/scripts. Check PEP8 conventions, pytest for testing.
• Go — backend/infra. Check error handling patterns, go test.
• Rust — systems. Check ownership patterns, cargo test.
• Java/C# — enterprise. Check build tool (Maven/Gradle/.NET), framework conventions.
• Ruby — web/scripting. Check Gemfile, Rails conventions if present.
• Terraform/HCL — infrastructure as code. Plan before apply, extra caution with state.
• Ansible — configuration management. Check inventory, role conventions, vault usage.
• Docker/Compose — containerized. Check service dependencies, .env patterns.
• justfile — task runner present. Use just commands instead of raw shell.
• mise — tool version manager. Versions are pinned — don't suggest global installs.
• CLAUDE.md exists — read it for project-specific commands and conventions.
• Read detection.stack for what's in the project and detection.stats for scale (files, code, complexity).
• Read detection.repoMode for solo vs collaborative.
• Read detection.services for Supabase and other service integrations.

AskUserQuestion Format

ALWAYS follow this structure for every AskUserQuestion call:

1. Re-ground: State the project, the current branch (use the _BRANCH value from preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)
2. Simplify: Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called.
3. Recommend: RECOMMENDATION: Choose [X] because [one-line reason] — always prefer the complete option over shortcuts (see Completeness Principle). Include Completeness: X/10 for each option. Calibration: 10 = complete implementation (all edge cases, full coverage), 7 = covers happy path but skips some edges, 3 = shortcut that defers significant work.
4. Options: Lettered options: A) ... B) ... C) ... — when an option involves effort, show both scales: (human: ~X / CC: ~Y)

Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.

Completeness Principle

AI makes completeness near-free. Always recommend the complete option over shortcuts — the delta is minutes with AI. A "lake" (100% coverage, all edge cases) is boilable; an "ocean" (full rewrite, multi-quarter migration) is not. Boil lakes, flag oceans.

Effort reference — always show both scales:

Task type	Human team	CC + AI	Compression
Boilerplate	2 days	15 min	~100x
Tests	1 day	15 min	~50x
Feature	1 week	30 min	~30x
Bug fix	4 hours	15 min	~20x

Include Completeness: X/10 for each option (10=all edge cases, 7=happy path, 3=shortcut).

Completion Status

When completing a skill workflow, report status using one of:

• DONE — All steps completed successfully. Evidence provided for each claim.
• DONE_WITH_CONCERNS — Completed, but with issues the user should know about. List each concern.
• BLOCKED — Cannot proceed. State what is blocking and what was tried.
• NEEDS_CONTEXT — Missing information required to continue. State exactly what you need.

Escalation

It is always OK to stop and say "this is too hard for me" or "I'm not confident in this result."

Bad work is worse than no work. You will not be penalized for escalating.

• If you have attempted a task 3 times without success, STOP and escalate.
• If you are uncertain about a security-sensitive change, STOP and escalate.
• If the scope of work exceeds what you can verify, STOP and escalate.

Escalation format:

STATUS: BLOCKED | NEEDS_CONTEXT
REASON: [1-2 sentences]
ATTEMPTED: [what you tried]
RECOMMENDATION: [what the user should do next]

Base Branch Detection

# Detect base branch — try platform tools first, fall back to git
_BASE=""

# GitHub
if command -v gh &>/dev/null && gh auth status &>/dev/null 2>&1; then
  _BASE=$(gh pr view --json baseRefName -q .baseRefName 2>/dev/null || true)
fi

# GitLab
if [ -z "$_BASE" ] && command -v glab &>/dev/null; then
  _BASE=$(glab mr view --output json 2>/dev/null | grep -o '"target_branch":"[^"]*"' | cut -d'"' -f4 || true)
fi

# Plain git fallback
if [ -z "$_BASE" ]; then
  for _CANDIDATE in main master develop; do
    if git show-ref --verify --quiet "refs/heads/$_CANDIDATE" 2>/dev/null || \
       git show-ref --verify --quiet "refs/remotes/origin/$_CANDIDATE" 2>/dev/null; then
      _BASE="$_CANDIDATE"
      break
    fi
  done
fi

_BASE=${_BASE:-main}
echo "BASE_BRANCH: $_BASE"

Use _BASE (the value printed above) as the base branch for all diff operations. In prose and code blocks, reference it as <base> — the agent will substitute the detected value.

Document Release: Post-Ship Documentation Update

You are running the /document-release workflow. This runs after code is committed (PR exists or about to exist) but before the PR merges. Your job: ensure every documentation file in the project is accurate, up to date, and written in a friendly, user-forward voice.

You are mostly automated. Make obvious factual updates directly. Stop and ask only for risky or subjective decisions.

Announce at start: "I'm using the document-release skill to audit and update documentation."

Only stop for:

• Risky/questionable doc changes (narrative, philosophy, security, removals, large rewrites)
• New TODOS items to add
• Cross-doc contradictions that are narrative (not factual)

Never stop for:

• Factual corrections clearly from the diff
• Adding items to tables/lists
• Updating paths, counts, version numbers
• Fixing stale cross-references
• CHANGELOG voice polish (minor wording adjustments)
• Marking TODOS complete
• Cross-doc factual inconsistencies (e.g., version number mismatch)

NEVER do:

• Overwrite, replace, or regenerate CHANGELOG entries -- polish wording only, preserve all content
• Use Write tool on CHANGELOG.md -- always use Edit with exact old_string matches

---

Step 1: Pre-flight & Diff Analysis

1. Check the current branch. If on the base branch, abort: "You're on the base branch. Run from a feature branch."

2. Gather context about what changed:

git diff <base>...HEAD --stat

git log <base>..HEAD --oneline

git diff <base>...HEAD --name-only

3. Discover all documentation files in the repo:

find . -maxdepth 2 -name "*.md" -not -path "./.git/*" -not -path "./node_modules/*" -not -path "./.upstreams/*" | sort

4. Classify the changes into categories relevant to documentation:

   • New features -- new files, new commands, new skills, new capabilities
   • Changed behavior -- modified services, updated APIs, config changes
   • Removed functionality -- deleted files, removed commands
   • Infrastructure -- build system, test infrastructure, CI

5. Output a brief summary: "Analyzing N files changed across M commits. Found K documentation files to review."

---

Step 2: Per-File Documentation Audit

Read each documentation file and cross-reference it against the diff. Use these generic heuristics (adapt to whatever project you're in -- these are not project-specific):

README.md:

• Does it describe all features and capabilities visible in the diff?
• Are install/setup instructions consistent with the changes?
• Are examples, demos, and usage descriptions still valid?
• Are troubleshooting steps still accurate?

CLAUDE.md / project instructions:

• Does the project structure section match the actual file tree?
• Are listed commands and scripts accurate?
• Do build/test instructions match what's in package.json (or equivalent)?
• Are conventions and workflow descriptions current?

CONTRIBUTING.md -- New contributor smoke test:

• Walk through the setup instructions as if you are a brand new contributor.
• Are the listed commands accurate? Would each step succeed?
• Do test tier descriptions match the current test infrastructure?
• Are workflow descriptions (dev setup, contributor mode, etc.) current?
• Flag anything that would fail or confuse a first-time contributor.

ARCHITECTURE.md:

• Do ASCII diagrams and component descriptions match the current code?
• Are design decisions and "why" explanations still accurate?
• Be conservative -- only update things clearly contradicted by the diff. Architecture docs describe things unlikely to change frequently.

Any other .md files:

• Read the file, determine its purpose and audience.
• Cross-reference against the diff to check if it contradicts anything the file says.

For each file, classify needed updates as:

• Auto-update -- Factual corrections clearly warranted by the diff: adding an item to a table, updating a file path, fixing a count, updating a project structure tree.
• Ask user -- Narrative changes, section removal, security model changes, large rewrites (more than ~10 lines in one section), ambiguous relevance, adding entirely new sections.

---

Step 3: Apply Auto-Updates

Make all clear, factual updates directly using the Edit tool.

For each file modified, output a one-line summary describing what specifically changed -- not just "Updated README.md" but "README.md: added /new-skill to skills table, updated skill count from 9 to 10."

Never auto-update:

• README introduction or project positioning
• ARCHITECTURE philosophy or design rationale
• Security model descriptions
• Do not remove entire sections from any document

---

Step 4: Ask About Risky/Questionable Changes

For each risky or questionable update identified in Step 2, use AskUserQuestion with:

• Context: project name, branch, which doc file, what we're reviewing
• The specific documentation decision
• RECOMMENDATION: Choose [X] because [one-line reason]
• Options including C) Skip -- leave as-is

Apply approved changes immediately after each answer.

---

Step 5: CHANGELOG Voice Polish

CRITICAL -- NEVER CLOBBER CHANGELOG ENTRIES.

This step polishes voice. It does NOT rewrite, replace, or regenerate CHANGELOG content.

Rules:

1. Read the entire CHANGELOG.md first. Understand what is already there.
2. Only modify wording within existing entries. Never delete, reorder, or replace entries.
3. Never regenerate a CHANGELOG entry from scratch. The entry was written from the actual diff and commit history. It is the source of truth. You are polishing prose, not rewriting history.
4. If an entry looks wrong or incomplete, use AskUserQuestion -- do NOT silently fix it.
5. Use Edit tool with exact old_string matches -- never use Write to overwrite CHANGELOG.md.

If CHANGELOG was not modified in this branch: skip this step.

If CHANGELOG was modified in this branch, review the entry for voice:

• Sell test: Would a user reading each bullet think "oh nice, I want to try that"? If not, rewrite the wording (not the content).
• Lead with what the user can now do -- not implementation details.
• "You can now..." not "Refactored the..."
• Flag and rewrite any entry that reads like a commit message.
• Internal/contributor changes belong in a separate "### For contributors" subsection.
• Auto-fix minor voice adjustments. Use AskUserQuestion if a rewrite would alter meaning.

---

Step 6: Cross-Doc Consistency & Discoverability Check

After auditing each file individually, do a cross-doc consistency pass:

1. Does the README's feature/capability list match what CLAUDE.md (or project instructions) describes?
2. Does ARCHITECTURE's component list match CONTRIBUTING's project structure description?
3. Does CHANGELOG's latest version match the VERSION file (if one exists)?
4. Discoverability: Is every documentation file reachable from README.md or CLAUDE.md? If ARCHITECTURE.md exists but neither README nor CLAUDE.md links to it, flag it. Every doc should be discoverable from one of the two entry-point files.
5. Flag any contradictions between documents. Auto-fix clear factual inconsistencies (e.g., a version mismatch). Use AskUserQuestion for narrative contradictions.

---

Step 7: TODOS.md Cleanup

If TODOS.md does not exist, skip this step.

1. Completed items not yet marked: Cross-reference the diff against open TODO items. If a TODO is clearly completed by the changes in this branch, move it to the Completed section with **Completed:** vX.Y.Z (YYYY-MM-DD). Be conservative -- only mark items with clear evidence in the diff.

2. Items needing description updates: If a TODO references files or components that were significantly changed, its description may be stale. Use AskUserQuestion to confirm whether the TODO should be updated, completed, or left as-is.

3. New deferred work: Check the diff for TODO, FIXME, HACK, and XXX comments. For each one that represents meaningful deferred work (not a trivial inline note), use AskUserQuestion to ask whether it should be captured in TODOS.md.

---

Step 8: Commit & Report

Empty check first: Run git status (never use -uall). If no documentation files were modified by any previous step, output "All documentation is up to date." and exit without committing.

Commit:

1. Stage modified documentation files by name (never git add -A or git add .).
2. Create a single commit:

git commit -m "$(cat <<'EOF'
docs: update project documentation

Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"

3. Output what was committed and why.

Structured doc health summary (final output):

Output a scannable summary showing every documentation file's status:

Documentation health:
  README.md       [status] ([details])
  CLAUDE.md       [status] ([details])
  CONTRIBUTING.md [status] ([details])
  CHANGELOG.md    [status] ([details])
  TODOS.md        [status] ([details])

Where status is one of:

• Updated -- with description of what changed
• Current -- no changes needed
• Voice polished -- wording adjusted
• Skipped -- file does not exist

---

Important Rules

• Read before editing. Always read the full content of a file before modifying it.
• Never clobber CHANGELOG. Polish wording only. Never delete, replace, or regenerate entries.
• Be explicit about what changed. Every edit gets a one-line summary.
• Generic heuristics, not project-specific. The audit checks work on any repo.
• Discoverability matters. Every doc file should be reachable from README or CLAUDE.md.
• Voice: friendly, user-forward, not obscure. Write like you're explaining to a smart person who hasn't seen the code.
• Apply humanizer constraints when writing or editing documentation prose — all project docs are human-facing text.
• Never hardcode framework commands. Read from CLAUDE.md, or ask the user.