mirror of
https://github.com/paperclipai/paperclip-docs.git
synced 2026-11-07 06:16:07 -10:00
Tags every docs release automatically, so the `docs/vX.Y.Z` tag stops depending on someone remembering to create it after the merge. So far, 11 of 16 releases were never tagged. ## What changes - **New workflow, `.github/workflows/tag-docs-release.yml`.** It runs on every push to `main`. For each new commit titled `Release docs for paperclip vYYYY.MDD.P`, it tags that commit `docs/vYYYY.MDD.P`. - Anything after a space in the title, such as `(#132)`, is ignored. - Pre-release versions like `-beta.1` are skipped. - Tags that already exist are left alone. - **`skills/sync-docs/SKILL.md` (Phase 9) and `maintenance/runbook.md`.** The after-merge step now checks that the tag exists instead of creating it by hand. It also tells you to keep the release PR title format, because the workflow reads the version from it. ## Tested I ran the version matching against all 16 release squash-commit titles on `main` and it matched every one, including `(content + screenshot overhaul) (#95)` and titles with no PR number. It rejects `-beta.1`. The workflow itself hasn't run on GitHub yet; the next release merge will be its first run. ## Needs The workflow needs permission to push tags: `permissions: contents: write`. If the repo's Actions permissions are read-only and that can't be changed per workflow, the first run will fail with a clear error. Fix it in Settings → Actions → Workflow permissions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 (1M context) <[email protected]>
skills/
Claude Code skills that ship with this repo. These are committed alongside the docs so the sync workflow stays reproducible across machines and contributors.
Available skills
| Skill | What it does | Invoke |
|---|---|---|
sync-docs |
Keeps these docs in lockstep with the parent paperclipai/paperclip codebase. Two modes: nightly (tracks parent main, preview deploy) and release (on parent tag, merges to main, ships live). |
/sync-docs |
Using a skill from this repo
Skills here are plain Markdown files with frontmatter. Claude Code discovers them by directory.
Option A — symlink into your user-level skills dir
mkdir -p ~/.claude/skills
ln -s "$PWD/skills/sync-docs" ~/.claude/skills/sync-docs
The /sync-docs slash command becomes available in any session.
Option B — project-level skills dir
If your Claude Code setup supports per-project skills (.claude/skills/), link from there:
mkdir -p .claude/skills
ln -s "../../skills/sync-docs" .claude/skills/sync-docs
Either way, the skill files themselves stay versioned in skills/, so updates flow with normal git operations.
Why skills live in the repo
The doc-sync workflow is repo-specific (it knows about our anchor-map.json, our branch model, our voice rules). Shipping it inside the repo means:
- Anyone cloning the repo gets the workflow.
- Changes to the workflow review like any other PR.
- The skill's prompts evolve alongside the docs they produce.