Sync Prostdev Skills

What it does

sync-prostdev-skills is a Claude Code skill for a specific maintenance chore: keeping a project’s shared skills in sync with the public skill set published at prostdev.com/skills.

When several projects share a common lineage of skills — say handoff, save-session, and claude-md-and-folder-standards — the copies drift. Upstream gains a refinement worth adopting; a local fork gains a general improvement worth giving back. This skill runs the recurring two-way check so neither side quietly falls behind the other.

When to use it

• On an occasional maintenance cadence, when you suspect the shared skills have drifted.
• When you want to “check prostdev for skills” — pull in new or improved ones.
• After you’ve refined a forked skill and want to know whether the improvement is worth upstreaming.

How it works

The skill is a plain Markdown file — frontmatter plus a short procedure. There’s no code to run; Claude fetches the public index, diffs the name-matches against the local copies, and reports a verdict per skill. A few ideas here generalize to any “reconcile a fork against upstream” task:

• Diff both directions, not just downstream. For every shared skill it asks two questions — what does upstream have that we lack, and what do we have that upstream lacks? — so improvements flow both ways instead of only trickling down.
• Three explicit buckets force a decision. Every skill lands in Pull in, Nothing (ours is already a superset — don’t regress to the ancestor), or Give back. No skill is left in limbo.
• Judge new skills against the actual project. A new upstream skill is adopted only if it fits a real workflow there. The public set is mixed — some skills are content/SEO, some are coding — so each one is judged on whether it applies, and the catalog doesn’t fill with irrelevant tooling.
• Surface the diff before changing anything. It presents findings and lets the human pick; nothing is edited silently.
• Carry a dated baseline. A “last full pass” snapshot records the prior verdict per skill, so each run re-verifies against a known state instead of starting cold.

The skill definition

Here’s the actual SKILL.md, verbatim — adapt the upstream URL, the shared-skill names, and the project-scope judgment to your own setup, then drop it in your skills directory.

---
name: sync-prostdev-skills
description: Periodically reconcile our shared Claude skills with the public prostdev.com skill set — pull in worthwhile upstream changes/new skills, and identify our own improvements worth contributing back. Use on an occasional maintenance cadence, or when asked to "check prostdev for skills".
---

# Reconcile with prostdev.com skills

`prostdev.com` publishes a public Claude Code skill set at `https://prostdev.com/llms.txt`. Three of
our shared skills — `handoff`, `save-session`, `claude-md-and-folder-standards` — share that lineage,
so upstream sometimes gains a refinement worth adopting, and our forks sometimes gain general
improvements worth giving back. This skill is the recurring two-way check.

## Steps

1. **Fetch the index.** `WebFetch https://prostdev.com/llms.txt` — list every skill (name + one-line
   description + URL).
2. **Diff the name-matches.** For each skill whose name matches one of ours, `WebFetch` its page
   (`https://prostdev.com/skill/<name>`) and compare its body against our version in `skills/<name>/`.
   Note anything upstream has that ours lacks, and vice-versa.
3. **Judge the new names.** For skills we don't have, decide relevance to **this project**. The
   public set is mixed — some are coding skills, some are content/SEO (e.g. `add-faqs`,
   `blog-seo-standards`, `technical-content-structure`, `tutorial-writing`) — so judge each one on
   its own merits: a code repo with no public content surface won't want the content/SEO skills,
   while a content-heavy repo will. Adopt one only if it fits an actual workflow here.
4. **Report a verdict per skill**, in three buckets:
   - *Pull in* — a genuine upstream improvement or a relevant new skill → adopt it (see Constraints).
   - *Nothing* — ours is already equal or a superset (don't regress to the ancestor).
   - *Give back* — general, project-agnostic knowledge in our version that upstream lacks; draft a
     generalized snippet the user can send them (we can't edit their site).
5. **Don't change anything without surfacing the diff first.** Present findings; let the user pick.

## Findings baseline (last full pass: 2026-07)

Re-verify each pass — this is a snapshot, upstream moves.

- `handoff` — byte-for-byte identical.
- `save-session` — **ours is a superset** (multi-repo routing; delegates constraints to
  `claude-md-and-folder-standards` instead of inlining them). Nothing to pull.
- `claude-md-and-folder-standards` — **ours is a superset** (adds `settings.json` hygiene, richer
  model-override rule with the fork/cache-bust rationale, an Anti-Patterns list). Nothing to pull.
- The other four listed skills were all content/SEO — judge them against your project's scope
  (out of scope for a pure code repo, in scope for a content-heavy one).
- **Worth upstreaming from us:** the three superset chunks above, generalized. Caveat: our
  `save-session` says *never write to MEMORY.md* (our setup bans file-based memory); on a stock
  install MEMORY.md **is** the memory system, so strip that line before contributing.

## Constraints

- Any edit to a shared skill / `CLAUDE.md` / `.claude/` file follows the
  `claude-md-and-folder-standards` skill.
- Shared skills are edited in the **standalone shared-config clone**, then propagated —
  see the `shared-claude-config` skill. Never edit a consumer's detached `.claude/` checkout.