docs(skills): description-quality pass across 13 collision-prone skills

[5uck1ess]

Summary

Rewrites the description: frontmatter on 13 skills that previously collided with each other, with native Claude behavior, or with other plugins. Bodies, workflow YAMLs, and the engine are untouched — this is a pure documentation/triggering pass.

Four themed commits, each addressing a distinct collision cluster:

• bf0abe5 — tri-* family (tri-review, tri-debug, tri-security, tri-dispatch). The four tri-* skills previously shared synonym soup ("triple/three-way/multi-agent/parallel/consensus"), leaving the description layer with zero differentiation. Now each opens with its unique function, names specific triggers, gives worth-it conditions, and hands off to siblings by function. tri-dispatch repositioned as the general-purpose exploratory tri-* for greenfield work — it was the most dangerous previously because "triple dispatch" is vague enough to swallow anything.
• 32b78f1 — research / deep-research. Replaced brittle negative-keyword routing (the old research description said "NOT for 'deep research' or 'validate' — those go to deep-research", which breaks the moment a user rephrases) with stakes-based positioning: research is the default/exploratory tier, deep-research is the high-stakes ACH/disconfirmation tier justified by concrete consequence categories (architecture commitment, vendor choice, compliance claim, etc.).
• bab79a9 — audit / self-audit. Both descriptions used the word "audit" with no functional differentiation; names alone didn't hint at the real distinction. Now explicitly: audit = scanner-driven (npm audit, eslint, govulncheck, semgrep) reporting what tools say; self-audit = evidence-ranked introspection (karpathy-style) reporting what a human should prioritize.
• c25822c — dispatcher skills (bugfix, feature, refactor, pr-ready, mega-pr). Five workflow triggers whose descriptions collided with native Claude behavior ("fix this bug", "refactor this") or with other plugins (feature-dev:feature-dev, commit-commands:commit-push-pr, pr-review-toolkit:review-pr). Each now includes worth-it conditions, trivial-task exclusions, and explicit plugin carve-outs. mega-pr repositioned as a fan-out that delegates to both tri-review and pr-review-toolkit, so it no longer competes with its own sub-skills.

Shared pattern applied to all 13

1. Open with the unique function (not a generic "deterministic X" stamp)
2. List specific trigger phrases tied to the function
3. State a worth-it signal — when the ceremony (or cost) is justified
4. Carve out negatives by function so rephrasing doesn't break routing
5. Where relevant, carve out other plugins by name to prevent cross-plugin collisions

Bonus finding

Verified src/engine/engine.go:111 correctly handles the parallel: [ids] pattern — steps listed in a parallel directive are skipped during the sequential walk and dispatched via runParallel. The tri-* workflow YAMLs genuinely fan out to all 3 model tiers in parallel. No engine changes needed.

Not in this PR

• Body bloat in browser (161 lines), scrape (156), screenshot (105) — different kind of work, risks breaking behavior, needs a separate PR with test runs.
• Principle/doctrine skills (clean-code, dry, yagni, dont-reinvent) — their triggering nature is different, descriptions are fine.
• Remaining dispatcher skills (doc-gen, onboard, test-gen, self-* except the two above, setup-rules) — less collision-prone; descriptions are acceptable, diminishing returns.

Test plan

• Manually invoke each of the 13 skills in a fresh Claude Code session and confirm they still activate on their primary triggers
• Cross-collision smoke test: send a tri-security query, verify tri-review does NOT fire (and vice versa across the family)
• Stakes smoke test: ask research for a low-stakes exploratory question and confirm deep-research does NOT fire; ask deep-research with explicit "correctness is critical" phrasing and confirm it DOES
• Plugin collision smoke test: invoke /feature-dev:feature-dev explicitly and confirm devkit's feature skill respects that boundary
• Verify all existing workflow YAML tests still pass (no workflow files were touched)