feat(NO-TASK): Add wp-theme-baseline and wp-design-tokens skills

[aaronware]

Why

No skill in this library owned theme development. Every path routed it to upstream wp-block-themes, which knows generic block-theme mechanics but nothing about our lineage, our brand tokens, or the specificity traps in our own CSS. Walking a realistic scenario — build a theme for a new Linchpin property — the workflow rails held at both ends (classify → task → orient → abstraction choice, and QA → audit → ship) and the middle was unowned.

What's here

wp-theme-baseline (Tier B) — a decision skill, not a scaffold. Child theme first, fresh second, fork last. Its Preflight carries a preset-coverage check that decides between the routes, with numbers measured against both real candidate parents:

Parent	Presets used	Own tokens from presets	Hardcoded hex	Read
Ollie (255 lines)	21	0	1	uses presets directly — restylable
DocsPress (4,255 lines)	75	41	40	own token layer fed by presets — restylable

Both pass, for different reasons, so the skill teaches reading the ratio rather than a threshold. The command in the skill runs verbatim and reproduces those figures.

wp-design-tokens (Tier B) — theme.json as the source of truth. Promotes four rules out of linchpin.com's project layer, including the one that costs the most time: theme.json element styles are :where()-wrapped at zero specificity, so the SCSS $heading-size-map beats them and a correct-looking edit does nothing.

The correctness fix worth reviewing closely

wp-local-setup told agents to git clone base-wp-theme-2026 and said "Start from the baseline theme, don't build from scratch." That theme was never launched and its theme.json is a stale fork of the brand. It now points at wp-theme-baseline and carries an explicit earlier versions said to note.

Getting it back under the 250-line limit came from deleting two Gotchas that duplicated its own Guardrails verbatim — nothing load-bearing was cut.

Two research claims I had to correct

Both were in my first draft from reading the repos, and both were wrong. Flagging them because the corrected versions are what the reference file now asserts:

1. "Ollie's border-light #DADEE3 survives verbatim in base-wp-theme-2026" — false. Ollie's value is #E3E3F0; #DADEE3 is ours. The fork evidence is the slug vocabulary, plus the spacing/font-size slug sets and the regular: 425 weight map, which are verbatim.
2. "27 style variations collapsed to one" — wrong theme, and the real sequence is more useful. Counts are Ollie 27 → base-wp-theme-2026 23 → themes/linchpin 2. The palette went paint-named first, which is what made the variations unmaintainable later. That's a better argument for role-named slugs than the one I originally wrote.

Also corrected: "46 --dp-* tokens" → 32 distinct tokens with 41 preset-fed definitions driving 383 usages.

Everything else was verified against the files, including all five contrast ratios recomputed independently (2.15:1, 7.25:1, 9.86:1, 8.79:1, 3.06:1).

Verification

• node scripts/validate-skills.mjs --strict → 22 skills, 0 errors, 0 warnings. The library previously failed --strict on wp-local-setup's length.
• All relative cross-references resolve (only the intentional <sibling> placeholder in the authoring template does not).
• Installer smoke-tested in a throwaway dir: both skills auto-discovered, references/ copied along.
• Nothing release-please owns was touched — no CHANGELOG.md, package.json, manifest, or README version marker.

Follow-ups for other repos (not in this PR)

• linchpin.com/ONBOARDING.md still lists base-wp-theme-2026 as a required checkout.
• linchpin-theme-conventions Rule 1 needs the palette-definition carve-out, or the next agent flags themes/docspress-linchpin as a violation.
• The 2.15:1 button contrast question from PR #918 has no recorded decision.
• docspress-linchpin's role vocabulary is DocsPress's, not ours. Until Linchpin owns one, each new property child inherits its parent's names and the properties keep diverging.

🤖 Generated with Claude Code

[aaronware]

Follow-ups from this PR are now tracked in Linchpin → Coding Standards, alongside LINCHPIN-5164 (the task that created this library):

Task	Priority	Item
LINCHPIN-5250	High	Add palette-definition carve-out to linchpin-theme-conventions Rule 1 — without it, an agent flags themes/docspress-linchpin's literal hexes as a violation and breaks the theme
LINCHPIN-5251	High	Decide the primary button contrast contract — #3fc1d0 on #ffffff is 2.15:1, below AA, raised in linchpin.com PR #918 with no decision recorded
LINCHPIN-5252	Normal	Remove base-wp-theme-2026 from linchpin.com/ONBOARDING.md, where it's still a required day-one checkout
LINCHPIN-5253	Normal	Establish a Linchpin-owned role vocabulary — docspress-linchpin's slugs are DocsPress's, so each new property child inherits its parent's names
LINCHPIN-5254	Low	Fix the stale release-tooling paragraph in this repo's CLAUDE.md (see below)

On LINCHPIN-5254 — worth flagging here since it affects anyone working in this repo. CLAUDE.md says "this repo has no commitlint, husky, release-please, or Renovate — it's a plain npm package published by hand." All of that is wrong except husky: release-please.yml is live with npm Trusted Publishing (OIDC), release-please-config.json and the manifest both exist, validate-skills.yml enforces the conventional-commit header on PR titles, and Renovate branches are on origin. The same section's npm version patch && npm publish instruction would fight release-please and bypass Trusted Publishing.

Reading the actual config rather than the doc is how this PR knew NO-TASK was an accepted scope and that feat maps to "Features ✨" — but the next person may not.