Files
paperclip-docs/skills
Aron PrinsandClaude Opus 5.5 478d24ce5d ci: tag docs releases automatically on merge to main (#133)
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]>
2026-09-26 13:37:31 +02:00
..

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.

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.