agentleFS
Sign inStart free
bmdhodlbmdhodl/agent47/.agents/skills/next-ticket/SKILL.md

next-ticket

Skill4 starsChanged 40 days agoMITView on GitHub

Pull and ship the next AgentGuard weekly ticket when the owner says "next ticket", "work the next ticket", "pull the next ticket", or "you are my lead". Open a ready PR, get Bugbot and Copilot to QA it, use a different model if those two are out of usage, fix real review issues, merge, then explain what shipped and why in a few words with one scenario and a few lines of code.

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. Markuysa/vibe-coding-template★ 1same 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 repository5 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    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. Distinctive:

    If the next ticket's acceptance needs outside people (testers, posts, replies) that an agent cannot produce, ship only the repo-side slice …

    line 28
  2. Very specific:

    Follow the repo's existing proof rules: tests, showwork claims, and a short PR body with the command output.

    line 36
  3. Distinctive:

    Ask Bugbot and Copilot to review the open PR.

    line 40
  4. Distinctive:

    If both Bugbot and Copilot skipped, send the diff to a model other than the one that wrote the PR.

    line 44
  5. Distinctive:

    Do not push an empty change just to retrigger a comment that is already answered.

    line 51
  6. Distinctive:

    If GitHub still requires an approving review and this login cannot override it, stop and give the owner the PR link.

    line 57
  7. Distinctive:

    After the merge, use a few words.

    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

Next ticket

You are the lead senior engineer. Do this once, then stop. Do not start another ticket in the same turn.

The owner saying "next ticket" is the selection. The planning-only label does not block that.

1. Pull the next ticket

Planning authority is GitHub #729 and Project 4. ops/03-ROADMAP_NOW_NEXT_LATER.md is a view, not a second queue.

gh issue list --repo bmdhodl/agent47 --state open --label roadmap:2026-weekly --limit 50

Take the first open ticket in the newest ordered sequence table in #729 (for example "Adoption sequence updated September 24"). Only if #729 has no such table, take the lowest open AG- issue. Skip any ticket that #729, the ticket, or a linked issue marks held, conditional, or blocked on an unmet gate. Read that issue before coding.

If the next ticket's acceptance needs outside people (testers, posts, replies) that an agent cannot produce, ship only the repo-side slice the ticket names and tell the owner what is still theirs. Also read memory/, ops/00-NORTHSTAR.md, ops/03-ROADMAP_NOW_NEXT_LATER.md, ops/04-DEFINITION_OF_DONE.md, and ops/FOLLOWUP.md.

Stay inside the ticket. The SDK stays MIT and zero-dependency. No paid features, no dashboard work, no new public export, and no release tag unless the ticket says so.

2. Ship it

Work on a branch off main. Open the PR ready for review. Never open a draft.

Follow the repo's existing proof rules: tests, showwork claims, and a short PR body with the command output.

3. QA

Ask Bugbot and Copilot to review the open PR. Wait until each one has either a real review or an explicit skip.

A usage-limit, quota, or "couldn't run" comment is a skip, not a code defect. Do not reply to each repeat of that skip.

If both Bugbot and Copilot skipped, send the diff to a model other than the one that wrote the PR. Ask that model only for bugs, security problems, and broken behavior. Do not review your own diff with the same model.

For every real review comment:

  • Fix it when it is a real bug or a misleading contract.
  • Reply with the file and the reason when it is already handled.
  • Resolve GitHub review threads after the fix is on the branch.
  • Do not push an empty change just to retrigger a comment that is already answered.

4. Merge

Merge after the checks that ran are green and the review comments are answered.

If GitHub still requires an approving review and this login cannot override it, stop and give the owner the PR link. Say that the merge button is theirs. Do not claim the PR merged.

5. Tell the owner

After the merge, use a few words. Include all four:

  1. What it did.
  2. Why, as one scenario a person can picture.
  3. A few lines of the code that do the important part, with one sentence each.
  4. What it still does not do, if that would mislead someone.

Example shape:

What: Two workers that share one saved budget can no longer both spend the last OpenAI call.
Why: One call is left. Both workers look at the same moment. Both would have sent. Now the first claims the call, and the second stops.
Code: reserve_for_dispatch(...) writes the hold before the provider is called.
Still open: streaming, Anthropic, and in-memory budgets do not reserve.

Then stop.

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