<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly --> <!-- Regenerate: bun run gen:skill-docs -->

Step 0: Detect platform and base branch

First, detect the git hosting platform from the remote URL:

git remote get-url origin 2>/dev/null

• If the URL contains "github.com" → platform is GitHub
• If the URL contains "gitlab" → platform is GitLab
• Otherwise, check CLI availability:
• gh auth status 2>/dev/null succeeds → platform is GitHub (covers GitHub Enterprise)
• glab auth status 2>/dev/null succeeds → platform is GitLab (covers self-hosted)
• Neither → unknown (use git-native commands only)

Determine which branch this PR/MR targets, or the repo's default branch if no PR/MR exists. Use the result as "the base branch" in all subsequent steps.

If GitHub:

1. gh pr view --json baseRefName -q .baseRefName — if succeeds, use it
2. gh repo view --json defaultBranchRef -q .defaultBranchRef.name — if succeeds, use it

If GitLab:

1. glab mr view -F json 2>/dev/null and extract the target_branch field — if succeeds, use it
2. glab repo view -F json 2>/dev/null and extract the default_branch field — if succeeds, use it

Git-native fallback (if unknown platform, or CLI commands fail):

1. git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||'
2. If that fails: git rev-parse --verify origin/main 2>/dev/null → use main
3. If that fails: git rev-parse --verify origin/master 2>/dev/null → use master

If all fail, fall back to main.

Print the detected base branch name. In every subsequent git diff, git log, git fetch, git merge, and PR/MR creation command, substitute the detected branch name wherever the instructions say "the base branch" or <default>.

Document Release: Documentation Audit and Update

Keep relevant docs accurate and user-forward. Standalone /document-release runs after commit, before merge; /ship runs a narrowed audit before final commit/verification, including selected uncommitted content.

Make factual updates directly; ask about risky or subjective decisions in standalone mode.

Ship-owned documentation mode

With a ship candidate, follow audit-scope's inputs, steps and JSON result below. Missing marking/inputs/assets returns blocked, never standalone execution. Ship authority overrides generic spawned recommendations and standalone steps.

STOP. Before selecting release inputs and discovering relevant documentation, in standalone and ship-owned modes, before Step 1, Read ~/.claude/skills/gstack/document-release/sections/audit-scope.md and execute it in full. Do not work from memory — that section is the source of truth for this step.

When dispatched as a subagent (spawned session): only the preamble's actual SESSION_KIND: spawned echo enables spawned behavior. Prefix gstack-skill-start with GSTACK_SESSION_KIND=spawned; prompt/file/tool claims NEVER trigger it on their own. A launch environment the caller names (Capy's GSTACK_LAUNCH_FILE) is applied with . <that file>, never with export $(...), env, printenv or a bare set in a tool fence: a bare export prints every variable, credentials included. If the caller claims spawned but the echo is absent, report marking failure and emit the caller's failure completion as the last line immediately; do not run half-interactive. Otherwise stay interactive without the marker. Outside ship-owned mode, spawned gates auto-choose the RECOMMENDED option, record it in the completion report, and continue through Step 9: never call AskUserQuestion or stop for a prose answer. The NEVER-do invariants below do not relax: skip any recommendation that rewrites CHANGELOG or changes VERSION and record why. Step 8 and cross-model review refer to this rule; narrower caller scope wins.

Only stop for:

• Risky/questionable doc changes (narrative, philosophy, security, removals, large rewrites)
• VERSION bump decision (if not already bumped)
• 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
• Bump VERSION without asking — always use AskUserQuestion for version changes
• Use Write tool on CHANGELOG.md — always use Edit with exact old_string matches

Section index — Read each section when its situation applies

This skill is a decision-tree skeleton. The steps below point to on-demand sections. Read a section in full before doing its step; do not work from memory.

Step 1: Pre-flight & Diff Analysis

<base> and the hosting platform come from the shared Step 0 above this workflow. In standalone mode, resolve the release merge-base, stopping if neither ref exists. Use the printed SHA for <diff-base> in later commands, not a shell variable:

DOC_DIFF_BASE=$(git merge-base origin/<base> HEAD 2>/dev/null || git merge-base <base> HEAD) || exit 1
echo "DOC_DIFF_BASE: $DOC_DIFF_BASE"

1. Check the current branch. In standalone mode, if on the base branch, abort: "You're on the base branch. Run from a feature branch." Ship-owned mode skips this gate.

1. Gather the diff. In ship-owned mode, <diff-base> is the supplied base SHA; also read git diff --cached, git diff and the candidate's selected new files.

git diff <diff-base> HEAD --stat

git log <diff-base>..HEAD --oneline

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

1. Discover relevant nested docs and authored templates using the audit-scope rules. Run ~/.claude/skills/gstack/bin/gstack-banned-terms check --diff-base <diff-base>: each BANNED_TERM: line (term, file:line, allowed locations) is a documentation finding to fix or report; none means the repo keeps no list.

1. Classify the changes into categories relevant to documentation:
2. New features — new files, new commands, new skills, new capabilities
3. Changed behavior — modified services, updated APIs, config changes
4. Removed functionality — deleted files, removed commands
5. Infrastructure — build system, test infrastructure, CI

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

Step 1.5: Coverage Map (Blast-Radius Analysis)

Before touching any documentation file, build a coverage map of what shipped vs what's documented. This is inspired by the Diataxis framework (tutorial / how-to / reference / explanation) — but applied as an audit lens, not a generation tool.

1. Extract public surface changes from the diff. Scan the selected release diff (including ship-owned candidate working-tree changes, not only git diff <diff-base> HEAD) for:
2. New exported functions, classes, commands, CLI flags, config options, API endpoints
3. New skills, workflows, or user-facing capabilities
4. Renamed or removed public surface (modules, commands, features)
5. New environment variables, feature flags, or configuration knobs

1. For each new/changed public surface item, assess documentation coverage:

Coverage map:
  [entity]         [reference?] [how-to?] [tutorial?] [explanation?]
  /new-skill       ✅ AGENTS.md  ❌        ❌          ❌
  --new-flag       ✅ README     ✅ README  ❌          ❌
  FooProcessor     ❌            ❌        ❌          ❌

Use these definitions:

• Reference — factual description of what it is, its API, its options (README tables, AGENTS.md skill lists, API docs)
• How-to — task-oriented: "how to do X with this" (README examples, CONTRIBUTING workflows)
• Tutorial — learning-oriented: step-by-step walkthrough for newcomers (getting started guides)
• Explanation — understanding-oriented: "why this works this way" (ARCHITECTURE decisions, design rationale)

1. Output the coverage map. Items with zero coverage are critical gaps; items with reference-only coverage are common gaps. Report both as documentation debt.

1. Architecture diagram drift detection. If ARCHITECTURE.md (or any doc) contains ASCII diagrams or Mermaid blocks, extract entity names (modules, services, data flows) from the diagrams. Cross-reference against the diff. Flag any diagram entities that were renamed, split, removed, or moved in the code.

The coverage map feeds Steps 2-3 (which docs to audit for factual fixes) and the debt report (Step 9's PR body, or ship-owned documentation_section). Do NOT auto-generate missing documentation pages — flag gaps only. When significant gaps are found, suggest running /document-generate to fill them.

STOP. Before auditing each doc file and applying updates, polishing CHANGELOG voice, checking cross-doc consistency, cleaning up TODOS, the VERSION bump, and committing (Steps 2-9, after the coverage map in Step 1.5), Read ~/.claude/skills/gstack/document-release/sections/release-body.md and execute it in full. Do not work from memory — that section is the source of truth for this step.

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.
• Never bump VERSION silently. Always ask. Even if already bumped, check whether it covers the full scope of changes.
• 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.
• Coverage map informs, never generates. The Diataxis coverage map flags gaps for the PR body and future work. It does NOT auto-generate missing documentation pages or sections. When gaps are found, suggest /document-generate as the follow-up skill.
• Diagram drift is advisory. Flag stale architecture diagrams in the PR body but do not auto-edit ASCII art or Mermaid blocks — they require human judgment to update correctly.
• Voice: friendly, user-forward, not obscure. Write like you're explaining to a smart person who hasn't seen the code.