/next-ticket
Read the project''s ticket store and name the single best ticket to work on now, with the reason. Use when picking up work, asking what''s next, what should I work on, or pulling the next task or ticket from the backlog.
$ npx -y skills add doodledood/manifest-dev --skill next-ticket --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/next-ticket
Context preview
The summary Claude sees to decide when to auto-load this skill.
Read the project''s ticket store and name the single best ticket to work on now, with the reason. Use when picking up work, asking what''s next, what should I work on, or pulling the next task or ticket from the backlog.
SKILL.md
next-ticket.SKILL.mdname: next-ticket
description: 'Read the project''s ticket store and name the single best ticket to work on now, with the reason. Use when picking up work, asking what''s next, what should I work on, or pulling the next task or ticket from the backlog.'
next-ticket
Find the store, read it, name one ticket. The store follows the ticket convention (`../ticket-up/references/TICKET_CONVENTION.md` — read it if the convention isn't already in context).
**Finding the store.** Check for a store config first (`store-config.md` in the ticket-up skill directory, else at a store root like `tickets/store-config.md`) — it names the venue. Without one, look for `tickets/<effort>/` directories in the project. A GitHub-venue config means the store is that repo's issues under the effort's tracking issue; query instead of reading files. If no store exists anywhere, say so plainly and offer the two ways one appears: `ticket-up` on a finished manifest, or writing tickets by hand under the convention.
**The read.** Read only the open set — the effort's ticket directory (never its `done/` archive), or the tracker's open-issue query — plus the front file for the destination and any priority override; closed history costs nothing. Ready tickets only — open, unclaimed, all dependencies done. Order them by the store's stated priority rule, or the convention's default: urgent → unblocking → impact → cheap, with impact measured against the front file's destination when one exists. Name the single top ticket: its title, kind (shaped means build it; question means figure it out first), and a one-line why-this-one grounded in the rule that put it on top. Multiple efforts with stores → ask which, or read the one the conversation is about.
**Then offer, don't act.** Offer to claim it for the user (write `Claimed by:`, assign the issue), and — by kind — to start executing a shaped ticket or open a figure-out session for a question ticket. Picking is this skill's whole job; working it is the user's call.
**When nothing is ready**, say exactly why: every open ticket blocked (name the blocking edges), everything claimed (name by whom), or the store is empty. A blocked-only store usually means the thing to do is finish or tidy something in flight — say which ticket closing would free the most.
Gotchas
- Don't silently skip a claimed ticket that looks abandoned — surface it ("claimed by X, untouched; a tidy pass could release it") rather than reassigning on your own.
- Don't rank by what looks interesting or recent; the priority rule is the contract, and the why-line must cite it.
Read more
name: next-ticket description: 'Read the project''s ticket store and name the single best ticket to work on now, with the reason. Use when picking up work, asking what''s next, what should I work on, or pulling the next task or ticket from the backlog.'
next-ticket
Find the store, read it, name one ticket. The store follows the ticket convention (`../ticket-up/references/TICKET_CONVENTION.md` — read it if the convention isn't already in context).
**Finding the store.** Check for a store config first (`store-config.md` in the ticket-up skill directory, else at a store root like `tickets/store-config.md`) — it names the venue. Without one, look for `tickets/<effort>/` directories in the project. A GitHub-venue config means the store is that repo's issues under the effort's tracking issue; query instead of reading files. If no store exists anywhere, say so plainly and offer the two ways one appears: `ticket-up` on a finished manifest, or writing tickets by hand under the convention.
**The read.** Read only the open set — the effort's ticket directory (never its `done/` archive), or the tracker's open-issue query — plus the front file for the destination and any priority override; closed history costs nothing. Ready tickets only — open, unclaimed, all dependencies done. Order them by the store's stated priority rule, or the convention's default: urgent → unblocking → impact → cheap, with impact measured against the front file's destination when one exists. Name the single top ticket: its title, kind (shaped means build it; question means figure it out first), and a one-line why-this-one grounded in the rule that put it on top. Multiple efforts with stores → ask which, or read the one the conversation is about.
**Then offer, don't act.** Offer to claim it for the user (write `Claimed by:`, assign the issue), and — by kind — to start executing a shaped ticket or open a figure-out session for a question ticket. Picking is this skill's whole job; working it is the user's call.
**When nothing is ready**, say exactly why: every open ticket blocked (name the blocking edges), everything claimed (name by whom), or the store is empty. A blocked-only store usually means the thing to do is finish or tidy something in flight — say which ticket closing would free the most.
Gotchas
- Don't silently skip a claimed ticket that looks abandoned — surface it ("claimed by X, untouched; a tidy pass could release it") rather than reassigning on your own.
- Don't rank by what looks interesting or recent; the priority rule is the contract, and the why-line must cite it.
Loop engineering for Claude Code and other agent CLIs: figure the problem out first, define what done means, then execute and verify every criterion independently.
Other skills on manifest-dev.
- /auto-optimize-prompt
Iteratively auto-optimize a prompt until no issues remain. Uses review-prompt in a loop, asks user for ambiguities, applies fixes via prompt-engineering skill. Runs until converged.
Open skill - /compress-prompt
Compresses prompts/skills into minimal goal-focused instructions. Trusts the model, drops what it already knows, maximizes action space. Use when asked to compress, condense, or minimize a prompt.
Open skill - /harden-task-file
Harden a manifest-dev task guidance file for one-shot quality — either /define''s quality-gate/Default set or figure-out''s probe set. Iterates: orthogonality gap analysis, user-approved additions, prompt review, fix, converge. Use when a task file needs comprehensive coverage
Open skill - /learn-from-session
Analyze Claude Code sessions to learn what went right/wrong and suggest high-confidence improvements to skills. Use when asked to analyze a session, learn from a session, or review workflow effectiveness.
Open skill - /optimize-prompt-token-efficiency
Iteratively optimizes prompts for token efficiency by maximizing information density - reduces verbosity, removes redundancy, tightens phrasing while preserving semantic content. Use when asked to compress, shorten, reduce tokens, tighten, maximize density, increase information
Open skill - /sync-claude-code-plugins
Sync the prompt-engineering plugin from a local clone of claude-code-plugins into .claude/ so the repo is self-contained for isolated/web environments. Copies agents/skills, removes only previously-synced items that disappeared upstream. Other content in .claude/ is left alone.
Open skill

