feat(skills): import core skills from .agents catalog

- Add junior-to-senior with research playbook and review rubric
- Add fuck-slop with tell catalog and multi-register voice profiles
- Add interface-kit with design engineering, motion, and a11y references
- Add app-security with 4-pillar upload defense and hardening playbooks
- Add debugging-workflow with systematic root cause isolation
- Standardize all skills to 5-phase Skill Architect protocol
- Sync symlinks to OpenCode, Codex, and Claude Code

skills/junior-to-senior/references/research-playbook.md

@@ -0,0 +1,59 @@
+# Senior Research Playbook
+
+Reference for Phase 1 of the `junior-to-senior` skill: how the senior earns expertise the junior doesn't have. Two tracks, run in this order — code research grounds the review in this repo; web research grounds it in the present.
+
+## Track 1: Code research
+
+Goal: know what is *true here* before judging the plan against it. Prefer a context-isolated explore subagent for broad sweeps; bring back conclusions, not file dumps.
+
+Checklist per plan:
+
+1. **Versions.** Read the lockfile/manifest (`package-lock.json`, `poetry.lock`, `go.mod`, `Cargo.lock`, ...) for every dependency the plan touches. Record exact pinned versions. Any plan step that assumes an API must be checked against the pinned version's docs, not the latest.
+2. **Conventions.** Find 2-3 existing implementations of the closest analogous feature. How does this repo do routing, errors, config, tests, migrations? The plan either matches or justifies the break.
+3. **Prior decisions.** Search for ADRs, `docs/`, design notes, and revealing commit messages on the touched paths. A plan that re-litigates a settled decision without knowing it was settled is a blocker.
+4. **Real constraints.** Deploy target, build system, CI time budget, supported platforms, existing data volume and shape. These kill more plans than design taste does.
+5. **Blast radius.** What actually imports/calls the things the plan changes? The junior plan's scope estimate is a guess; the dependency graph is a fact.
+
+## Track 2: Web research
+
+Goal: find where the world moved after the training cutoff. Research the plan's *load-bearing decisions* (from Phase 1a), not every line — typically 3-7 searches total, not 30.
+
+### Query patterns
+
+For each load-bearing decision, run the subset that applies:
+
+- `<library> changelog` / `<library> release notes <current year>` — catch deprecations and new APIs since cutoff.
+- `<approach> vs <alternative> <current year>` — check whether the tradeoff has flipped.
+- `<pattern> deprecated` / `<pattern> considered harmful` — find published reversals.
+- `<technology> best practices <current year>` — only useful when followed to a primary source; the query itself attracts SEO spam, so treat listicle results as pointers, not evidence.
+- `<library> security advisory` / check the project's GitHub security tab — non-negotiable for auth, crypto, parsing, and anything touching user input.
+- `site:github.com <library> issues <feature>` — maintainer-stated direction and known footguns.
+
+Always pin the current year or "latest" into queries — undated queries return the same era the model was trained on, which defeats the point.
+
+### Source quality ranking
+
+1. Official documentation, changelogs, release notes, RFCs — cite freely.
+2. Maintainer blog posts, GitHub issues/discussions where maintainers state direction.
+3. Engineering postmortems and benchmarks from teams that ran the thing in production (with dates and numbers).
+4. Conference talks, well-known practitioner blogs — corroborate before citing for a blocker.
+5. SEO listicles, AI-generated tutorials, undated content — never evidence, at most a pointer to a real source.
+
+Every cited source gets a date check. A "best practices" article from before the relevant major version is training-data-era knowledge wearing a URL.
+
+### What you are looking for
+
+- **Deprecations** — the plan's approach is discouraged or removed in current versions.
+- **Supersessions** — a newer pattern/API has clearly won (look for the old way's own docs pointing at the new way — that's the strongest signal).
+- **Hard-won lessons** — advisories, postmortems, benchmarks that change the tradeoff the junior made on priors.
+- **Confirmations** — the junior's choice still holds. Record these too; they go in "What the junior got right".
+
+### When to stop
+
+- Each load-bearing decision has either one primary source confirming/refuting it, or two independent secondary sources agreeing.
+- Two consecutive searches on a decision return nothing newer than what you knew — the world likely didn't move; mark it confirmed-by-absence and move on.
+- Diminishing returns: research budget belongs on blockers and majors, not minors. If a finding would be minor either way, don't research it.
+
+### No web access
+
+Run Track 1 fully, skip Track 2, and tag every best-practice claim in the review `[training-data, unverified]`. Tell the user the review is grounded in the codebase but not refreshed against current SOTA, and name the decisions most likely to have shifted so they can spot-check.

skills/junior-to-senior/references/review-rubric.md

@@ -0,0 +1,67 @@
+# Senior Review Rubric
+
+Reference for Phase 2 (altitude diagnosis) and Phase 3 (adversarial review) of the `junior-to-senior` skill.
+
+## Altitude diagnostics
+
+Classify each section of the artifact independently. A plan is usually **mixed**: fogged on the hard parts, tunneled on the easy ones — because the junior wrote detail where it was comfortable and abstraction where it was not. That inversion (detail on easy parts, fog on hard parts) is itself a finding.
+
+### Fog tests (too vague)
+
+Run these against every component, step, or workstream the plan names. Each "no" is a finding.
+
+1. **Start-tomorrow test** — could a competent engineer begin this item tomorrow without making an architecture or product decision themselves? If they'd have to choose a library, design a schema, or define an API first, the plan didn't plan it.
+2. **Interface test** — does anything that crosses a boundary (function, service, queue, file, network) have its shape written down? Names of fields, not "the relevant data".
+3. **Failure test** — for each external interaction (network, disk, user input, third-party API), does the plan say what happens when it fails? "Handle errors" is not an answer.
+4. **Quantity test** — are load-bearing quantities stated? Expected row counts, payload sizes, request rates, latency budgets. "Should be fast" is fog.
+5. **Named-technology test** — is every "a cache / a queue / some auth layer" either named (with version) or explicitly listed as an open decision with the candidates?
+
+### Tunnel tests (too granular / missing vision)
+
+Run these against the artifact as a whole. Each "no" is a finding.
+
+1. **Audience test** — does the plan say who this is for and what they can do afterward that they couldn't before?
+2. **Success test** — is there an observable definition of success? A metric, a demo, a passing test suite, a user behavior — something checkable.
+3. **Non-goals test** — is anything explicitly out of scope? A plan with no non-goals has not been scoped, only described.
+4. **Alternative test** — does the plan say why this approach beat the obvious boring alternative? If no alternative was considered, the choice was a default, not a decision.
+5. **Sequencing test** — is there an ordering with a smallest useful version first, or is it a flat list of equally-weighted tasks?
+6. **Proportionality test** — does the detail land where the risk is? Twenty lines on a helper function and one line on the data migration means the plan is upside down.
+
+## Vague-word blacklist
+
+When these appear without immediate quantification or specification, challenge them with the concrete question they are hiding from:
+
+| Word | Hidden question |
+|---|---|
+| simple / straightforward | Simple compared to what? What did you not have to handle? |
+| scalable | To what number, on what axis, measured how? |
+| robust / resilient | Against which specific failures? What is the recovery path? |
+| handle gracefully | What exactly happens? Retry, drop, queue, surface to user? |
+| performant / fast | What latency/throughput budget, at what percentile? |
+| secure | Against which threat model? Who is the attacker? |
+| flexible / extensible | For which anticipated change? Flexibility has a cost — who pays it? |
+| later / eventually / for now | Is this a sequencing decision or an unowned risk? Who reopens it, triggered by what? |
+| etc. / and so on | The list was the work. Finish it. |
+| appropriate / as needed | By whose judgment, applied when? |
+| leverage / utilize | Usually decorating an undecided choice. Name the thing. |
+
+## Severity definitions
+
+- **Blocker** — the plan fails as written. Examples: targets an API the pinned dependency version doesn't have; contradicts an existing architectural decision in the repo without acknowledging it; omits a data migration that the change requires; relies on a pattern that has a published security advisory against it; an entire hard component is fog (fails the start-tomorrow test).
+- **Major** — the plan works but is meaningfully worse than the current state of the art or misfit to this repo. Examples: hand-rolls something a maintained, already-installed dependency provides; uses a pattern superseded since the training cutoff (with source); detail is inverted (proportionality failure); no rollback story for a hard-to-reverse step; success criteria exist but aren't observable.
+- **Minor** — polish. Naming, doc gaps, small idiom mismatches with the surrounding codebase, ordering tweaks that reduce risk but don't change the outcome.
+
+Calibration rules:
+
+- Severity reflects consequence, not effort-to-fix. A one-line version bump can be a blocker.
+- Every finding carries evidence (file:line, or source + date) and a concrete fix. A finding without a fix is a question — put it in "Open questions" instead.
+- Do not inflate. Three real blockers reads as a serious review; ten padded ones reads as noise and gets ignored.
+- Track "what the junior got right" with the same care as faults. The rewrite must preserve it, and the user needs to see the review is calibrated, not performatively hostile.
+
+## Adversarial discipline
+
+- **Steelman first.** Before attacking a choice, state the strongest case for it in one or two sentences. If you cannot, you do not understand it well enough to reject it.
+- **Attack the artifact, not the author.** Findings name the text's failure, not the agent's.
+- **Concede when beaten.** If research validates the junior's choice, say so and move on. An adversarial review that cannot return "this holds" is a ritual, not a review.
+- **One altitude per finding.** Do not bundle "this is vague" with "this library is outdated" — they have different fixes.
+- **No invented requirements.** If the review wants a constraint the user never stated (e.g., "must support 1M users"), that is an open question for the human, not a finding.