Files
skills/skills/productivity/handoff/SKILL.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

879 B

name, description, argument-hint, disable-model-invocation
name description argument-hint disable-model-invocation
handoff Compact the current conversation into a handoff document for another agent to pick up. What will the next session be used for? true

Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.

Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.

Do not duplicate content already captured in other artifacts (specs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.

Redact any sensitive information, such as API keys, passwords, or personally identifiable information.

If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.