Automated summary
Lands an approved documentation branch on main, either by opening a squash PR or by squash-merging locally, with a mandatory confirmation before the production deploy.
Strengths
- Checks the review verdict in TECH.md and stops publishing unless it is approved
- Builds a rich PR body linking artifacts (GOAL, PLAN, research, REVIEW) through SHA-pinned permalinks
- Enforces a human confirmation gate via AskUserQuestion before the irreversible step
- Supports both PR (default) and local merge modes and refuses to target the dev branch
Limitations
- Assumes a repo-specific documentation factory layout (spec/{slug}/, TECH.md, GOAL.md, .agents/factory)
- Allowed Bash tool paths are hardcoded to this environment
- Merging to main deploys to production with no staging gate, which remains risky
Use it as the final step once a documentation branch has passed review and needs to ship to main.
Avoid it on repositories that lack the spec/ structure and TECH.md/GOAL.md files, or when you must not trigger the automatic production deploy.
Security analysis
CautionThe skill is a documentation-publishing workflow that uses git/gh to push branches, open squash PRs, and optionally merge or squash-merge to main. Its highest-risk action is triggering a production deploy on merge, but this is clearly flagged and gated behind a mandatory human confirmation and an 'approved' review-verdict check. Tool grants are powerful (push/merge) yet legitimate and scoped to git/gh plus one local script; there is no exfiltration, destructive command, or safety-disabling behavior, so it warrants caution rather than risky.
- •Merging to main auto-deploys to production (~5 min); irreversible outward action, but gated by a mandatory AskUserQuestion confirmation and an explicit approved-verdict requirement
- •Broad git write scopes granted: push, merge, switch/checkout, add, commit, plus gh pr/gh repo — powerful but appropriate for a publish workflow
- •Bash(.venv/bin/python .agents/factory/bin/meta_status.py *) executes a repository-local Python script; trust depends on that script, though the path is narrowly scoped
- •No network fetches via curl/wget, no secret handling, no destructive filesystem operations, no obfuscated payloads
Examples
/docs-publish and open the squash PR to main for my current documentation branch./docs-publish status — show the review verdict, commits ahead of main, and any existing PR./docs-publish local — squash-merge my approved docs branch into main locally without pushing.name: docs-publish description: >- Land an approved documentation branch on main. Default: push the branch and open a squash PR to main with a rich, artifact-linked body (Summary/Goal/Design/Research/Phases/Verification). Alternative (local): squash-merge into main locally. Confirms before any irreversible/outward step; never targets dev. NOTE: merging to main auto-deploys to production (Geddes) within ~5 minutes — this is the one irreversible, outward step. Final step of the documentation factory. disable-model-invocation: true argument-hint: "[pr (default) | local] [merge]" allowed-tools: Read, Grep, Glob, AskUserQuestion, Bash(git status *), Bash(git branch *), Bash(git log *), Bash(git diff *), Bash(git rev-parse *), Bash(git fetch *), Bash(git push *), Bash(git switch *), Bash(git checkout *), Bash(git merge *), Bash(git add *), Bash(git commit *), Bash(gh pr *), Bash(gh repo *), Bash(.venv/bin/python .agents/factory/bin/meta_status.py *)
docs-publish — ship the branch to main
Open a squash PR to main (default) or squash-merge locally. Merging to main deploys to
production within ~5 minutes — there is no staging gate. Always confirm before the irreversible step,
and never target dev (CI blocks dev → main anyway; dev is the a11y branch).
Step 0 — status (when requested)
Report the review verdict, commits vs main, and any existing PR (gh pr status). No action.
Step 1 — Pre-flight
- On the
feature/|fix/|refactor/branch, clean tree; resolve{slug}. - Read
kindandreview.verdictfromTECH.md— STOP if the verdict is notapproved(unless the human explicitly overrides). If review flagged a human gate, confirm sign-off happened. git fetch origin; flag if the branch is behindmain.
Step 2 — Compose PR title + body
- Title:
[{kind}] {imperative summary}synthesized fromGOAL.md(never Conventional Commits likefeat:/docs:). - Body (link artifacts via SHA-pinned permalinks using
git rev-parse HEAD; link, don't quote):- Summary — what changed and why (from GOAL).
- Goal →
spec/{slug}/GOAL.md - Design →
spec/{slug}/PLAN.md - Research →
spec/{slug}/research/*.md(if present) - Phases completed → from the
TECH.mdFSM (id · name · satisfies R-IDs) - Verification → from
spec/{slug}/REVIEW.md(build/render/link/nav/a11y results, verdict) - 🔧 Harness feedback (only if
.venv/bin/python .agents/factory/bin/meta_status.py spec/{slug}/META.md --status openreportsopen > 0) → a short, collapsed section listing each open finding (id · severity · title), then label the PR:gh pr edit --add-label harness-feedback. Keep it terse (link toMETA.mdfor detail) so it doesn't dominate the PR; route them later with/docs-harness. Do not write or resolve findings here. Closes #NN(this auto-closes the issue —mainis the default branch)- trailing line:
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Step 3 — Confirm with the human (mandatory)
AskUserQuestion: mode (PR vs local), title, and body. This is the last gate before production.
Step 4a — PR (default)
git push -u origin {branch} → gh pr create --base main --head {branch} --title "…" --body-file ….
If merge is confirmed: gh pr merge {N} --squash --subject "{title}" --body "…" --delete-branch.
Step 4b — local
git switch main && git pull --ff-only → git merge --squash {branch} →
git commit -m "{title}" → git branch -D {branch}. Do not push main unless explicitly asked
(a push to main triggers the production deploy).
Step 5 — Report
PR URL / merge result, the squash subject, and the retained spec/{slug}/ artifacts. Remind the
human that a merge to main rolls out to docs.rcac.purdue.edu within ~5 minutes.
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/publish-documentation-ms71b3cz/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/publish-documentation-ms71b3cz' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/publish-documentation-ms71b3cz/download' --output '.skill-downloads/publish-documentation-ms71b3cz/SKILL.md.part' && mv '.skill-downloads/publish-documentation-ms71b3cz/SKILL.md.part' '.skill-downloads/publish-documentation-ms71b3cz/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
Tools declared by the author (check availability in your agent): Read, Grep, Glob, AskUserQuestion, Bash(git status *), Bash(git branch *), Bash(git log *), Bash(git diff *), Bash(git rev-parse *), Bash(git fetch *), Bash(git push *), Bash(git switch *), Bash(git checkout *), Bash(git merge *), Bash(git add *), Bash(git commit *), Bash(gh pr *), Bash(gh repo *), Bash(.venv/bin/python .agents/factory/bin/meta_status.py *)
No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.
Claude Code
test -f '.skill-downloads/publish-documentation-ms71b3cz/SKILL.md' && test -s '.skill-downloads/publish-documentation-ms71b3cz/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/docs-publish' && cp -R '.skill-downloads/publish-documentation-ms71b3cz' '.claude/skills/docs-publish'OpenSkills
OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.
Official OpenSkills installationopenskills install './.skill-downloads/publish-documentation-ms71b3cz'openskills read 'publish-documentation-ms71b3cz'Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.
For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.
openskills syncManual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/publish-documentation-ms71b3cz/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
Configure a Chat Channel with SecretRefs
DevOps
Set up chat channels using non-interactive commands, with secrets only as SecretRefs. Covers gather, mutate, repair, and prove steps for reliable delivery.
Investigate ClickHouse CI Failures
DevOps
Investigate a ClickHouse CI failure end-to-end from a PR or S3 report URL. Fetches failed tests, classifies flaky vs real regression, and checks for existing issues/fixes.
Ansible PR Review
DevOps
Reviews an Ansible PR following the project's standardized process, including changelog checks, test coverage validation, and feedback tracking.