agentleFS
Sign inStart free
MarkuysaMarkuysa/vibe-coding-template/.claude/skills/next-ticket/SKILL.md

next-ticket

Skill1 starsChanged 4 months agoMITView on GitHub

Picks the next dispatchable ticket from docs/tickets/ and implements it, without anyone naming which one. Claims by pushing the ticket branch, so concurrent runs cannot take the same ticket.

  • Commits and pushes

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. bmdhodl/agent47★ 4same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository10 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If this run was started by a routine or asked for autopilot, and enabled is false, stop immediately.

    line 19
  2. Distinctive:

    Stop and say which of these it is — the distinction tells the human their next move:

    line 54
  3. Distinctive:

    Do not invent work, and do not take a blocked ticket because it looks ready to you.

    line 61

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Requested: $ARGUMENTS

The queue lives in docs/tickets/ — statuses are derived from git, never stored elsewhere. See docs/tickets/README.md for the model.

0. Read the kill switch

Read .claude/autopilot.json.

  • maxInFlight from that file is the limit for step 1, unless the request passed a number, which wins.
  • If this run was started by a routine or asked for autopilot, and enabled is false, stop immediately. Say autopilot is off and that /autopilot on turns it back on. Do not work the ticket anyway.

A human asking for one ticket directly in a session is not autopilot — serve that whatever the flag says. The switch governs unattended execution, not the skill.

1. Check whether there is room

In flight = tickets whose branch claude/NNN-* exists while the file in main still says todo. Count them (remote branches too, when a remote exists). At or above the limit — stop and report what is in flight. This check is what keeps two runs from claiming the same ticket.

2. Pick the next ticket

Ready = status: todo in main, every id in depends is done in main, and no claude/NNN-* branch exists. Take the lowest id — the planner numbers tickets in dependency order, so lowest-first is the intended sequence. Skip any ticket whose branch carries needs-attention: a human must look at those before a retry.

3. Claim it by pushing the branch

git checkout main && git pull
git checkout -b claude/NNN-<slug>
git push -u origin claude/NNN-<slug>    # skip the push when there is no remote

The push is the lock: if it fails because the branch already exists, another run got there first — say so and pick the next ready ticket (once). With no remote, creating the local branch is the claim.

4. If nothing is ready

Stop and say which of these it is — the distinction tells the human their next move:

  • Blocked work exists — name the blocked tickets and the unmerged tickets holding them.
  • Everything is in review — the queue advances on merges; that is the human's move.
  • Something needs attention — name it; it will never clear on its own.
  • Nothing left — every ticket is done. Say so plainly.

Do not invent work, and do not take a blocked ticket because it looks ready to you.

5. Run it

Invoke the execute-ticket skill for the chosen id. Everything about how the ticket is implemented lives there — do not restate or second-guess it here.

Handle exactly one ticket per run. The chain advances when a merge fires the next run, so review sits between tickets by construction.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free