Files
skills/.agents/adr/0001-explicit-setup-pointer-only-for-hard-dependencies.md
Matt PocockandClaude Opus 4.8 386d4ff719 refactor: unify planning skills into /to-spec + /to-tickets
Executes the `unify-to-tickets` decision (personal-wiki #23), reworking
this PR from "add /to-plan" into the full planning-skills unification.

- Rename /to-prd → /to-spec. "spec" is now the single through-line term
  (the skill still opens with "you may know this document as a PRD" for
  discoverability).
- Merge /to-plan + /to-issues into one /to-tickets skill; delete
  /to-issues. /to-tickets emits a set of tickets, each declaring its
  blocking edges — one medium-agnostic artifact that reads as a
  sequential plan (local `tickets.md`, edges as text) or a parallelizable
  DAG (real tracker, native blocking links). The edges live in the ticket
  either way; the medium only decides whether anything acts on them in
  parallel.
- ask-matt now routes idea → /to-spec → /to-tickets → /implement.
- Sweep every cross-reference (docs pages, chain diagrams, CONTEXT.md,
  ADRs, .agents, setup templates) to the new names and vocabulary.
- Rewrite the changeset to describe the unification.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 14:18:36 +01:00

1.1 KiB

Explicit /setup-matt-pocock-skills pointer only for hard dependencies

Engineering skills depend on per-repo config (issue tracker, triage label vocabulary, domain doc layout) seeded by /setup-matt-pocock-skills. Some skills cannot meaningfully function without that config — they have to publish to a specific issue tracker or apply a specific label string. Others only use it to sharpen output (vocabulary, ADR awareness) and degrade gracefully without it.

We split these into hard-dependency and soft-dependency skills:

  • Hard dependency (to-tickets, to-spec, triage) — include an explicit one-liner: "… should have been provided to you — run /setup-matt-pocock-skills if not." Without the mapping, output is wrong, not just fuzzy.
  • Soft dependency (diagnose, tdd, improve-codebase-architecture) — reference "the project's domain glossary" and "ADRs in the area you're touching" in vague prose only. If the docs aren't there, the skill still works; output is just less sharp.

The split keeps soft-dependency skills token-light and avoids cargo-culting the setup pointer into places where it isn't load-bearing.