Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add aethrox/doctrine --skill spec-to-ticketsgit clone --depth 1 https://github.com/aethrox/doctrineWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/aethrox/doctrine/spec-to-tickets)<a href="https://agentmods.dev/skills/aethrox/doctrine/spec-to-tickets"><img src="https://agentmods.dev/badge/skills/aethrox/doctrine/spec-to-tickets/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/aethrox/doctrine/spec-to-tickets"><img src="https://agentmods.dev/badge/skills/aethrox/doctrine/spec-to-tickets.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00095 | $0.01198 |
| Opus 5 | $0.00048 | $0.00599 |
| Sonnet 5 | $0.00019 | $0.00240 |
| Haiku 4.5 | $0.00010 | $0.00120 |
Grade A, and why
spec-to-tickets scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec to Tickets
A spec synthesizes what's already been decided; it does not re-interview the user from scratch. And a ticket is not "ready to start" or "done" by feel; both are gated by a written, agreed checklist, so two people (or two sessions) apply the same bar instead of a different one each time.
Phase 1: Synthesize the spec
Pull together what the conversation, plan, or existing notes have already established (problem statement, scope, explicit non-goals, and any real constraints (technical, timeline, dependency)) into one written document. This is a synthesis step, not a fresh discovery interview: if a genuine open question surfaces that nothing already discussed has answered, ask it once, narrowly, rather than re-covering ground already settled. Write the spec and its tickets without em dashes, using a comma, colon, period, or a reworded sentence instead.
A spec worth ticketing states:
- The problem, in one or two sentences: what's wrong or missing, for whom.
- Scope, concretely enough that a reader can tell what's in and what's out.
- Non-goals: explicitly named, not left to be inferred. An unstated non-goal is the most common source of scope creep once tickets are underway.
- Constraints that shape the solution (a deadline, a system that can't change, a dependency on another team).
Phase 2: Slice into tracer-bullet tickets
A tracer bullet ticket is a thin, complete slice through the whole system (enough to prove the path works end-to-end) rather than a horizontal layer (all the backend work, then all the frontend work). Slice work the same way tdd builds it: one vertical slice, working and demonstrable, before the next.
For each ticket:
- State what it delivers as a testable outcome, not a task description; "a user can submit the form and see a confirmation" instead of "build the form."
- Declare its blocking edges explicitly: which other tickets must land first, and why. A dependency left implicit is a dependency someone starts working around instead of respecting.
- Keep it small enough to land in one focused work session; a ticket that can't be described in a sentence or two is usually two tickets wearing one number.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 71 lines · 95 tokens per session scan A 011bfee13f9c
spec-to-tickets is a skill published in the GitHub repository aethrox/doctrine (18 stars, last pushed yesterday), licensed MIT. It adds 95 tokens to every session and 1,198 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
daily-briefing
Start your day with a prioritized CRM briefing — works for any monday CRM setup: pipeline, contacts, accounts, leads, or no board at all. Use when someone says 'morning briefing', 'daily brief', 'what's on my plate today', 'catch me up on my deals', 'what needs attention', 'what needs my attention', 'anything urgent…
meeting-to-deal
Turn meeting transcripts into deal updates — key points, commitments, and next steps posted to matching CRM deals automatically. Auto-creates contacts for new attendees. Use when someone says "log my meetings to deals", "update CRM from calls", "what did I commit to in meetings", "sync notetaker", "log this meeting"…
Technical Debt Tracking with PMAT
Tracks and manages technical debt using PMAT (Pragmatic AI Labs MCP Agent Toolkit). Use this skill when: User asks about technical debt, TODO comments, or code quality issues Planning sprint work and need to prioritize debt repayment Conducting code audits or technical debt assessments Tracking debt accumulation…
backlog
EXPERIMENTAL. Use when working the project-wide out-of-scope backlog at paad/code-reviews/backlog.md — cleaning it of entries that are already fixed or gone, or picking the next entry and fixing it end-to-end. Not for producing backlog entries — that is /agentic-review — and not for reviewing a branch diff.
pipefy-process-design
Use this skill ONLY when the user explicitly asks for help designing or architecting a process ("help me design", "what's the best structure", "how do I organize this flow?"). For direct execution requests ("create a pipe for X", "build a reimbursement process", or any message with a detailed spec), skip this skill…
pipefy-members-email-webhooks
Use this skill when the user wants to manage pipe membership, send or read card inbox emails, use email templates, or manage webhooks. Covers 12 MCP tools.