Matt PocockandClaude Opus 4.8
386d4ff719
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>
1.5 KiB
Issue tracker integrations are limited to mainstream tools
setup-matt-pocock-skills only offers first-class support for mainstream issue trackers. Requests to add support for niche, new, or single-vendor experimental trackers are out of scope.
Why this is out of scope
Every issue-tracker backend hard-codes a CLI shape into the skills (commands, flags, output parsing). Each new backend is permanent maintenance surface — it has to keep working as the tool's CLI evolves, and it has to keep being tested against /to-spec, /to-tickets, /triage, and friends. That cost is only worth paying for trackers a meaningful fraction of users actually have.
"Mainstream" is a judgment call, not a numeric bar:
- GitHub, GitLab, and Backlog.md are the kind of tools we'd consider mainstream — broadly known, widely used, well past the experimental phase.
- A brand-new agent-focused tool with a few hundred GitHub stars is not, no matter how interesting the design.
Stars, age, and download counts are useful signals when making the call but none of them is the rule. The rule is: would a typical engineer recognise this tool and have plausibly chosen it for their team?
The escape hatches for non-mainstream trackers already exist:
local markdownfor lightweight in-repo tracking.other/customfor users who want to wire something up themselves.
Neither requires the core skills to know about the specific tool.
Prior requests
- #99 — "Add dex as an issue tracker backend" (dex was ~3 months old and ~300 stars at the time of the request)