agentleFS
lgtm-hqlgtm-hq/ai-skills/skills/backlog/SKILL.md

backlog

Skill1 starsChanged 10 days agoMITView on GitHub

Interactive dispatcher for backlog work. Asks one routing question — drive PRs to merge, or implement issues to open-PR state — then follow-ups based on the answer, and hands off to implement-issues / babysit-pr with standing policy applied. Use when asked to work the backlog or run /backlog.

36 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use worktree, retro and 8 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MicrosoftSkill

    worktree

    Create, reuse or clean up a dedicated git worktree for working on a pull request or a private branch. Use from any PR-scoped workflow that needs an isolated checkout to keep current code and build output untouched.

    Also in 3 projects that use this

  • AWSSkill

    retro

    Conduct a retrospective on a coding session.

    Also in 4 projects that use this

  • HashiCorpSkill

    changelog

    Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 4 projects that use this

  • VercelSkill

    deploy

    Deploy applications to Vercel. Use when the user says "deploy", "deploy to Vercel", "push to production", "deploy my app", or "go live".

    Also in 3 projects that use this

  • Hugging FaceSkill

    implement

    Make tests pass. Invoke after /write-tests produces failing tests.

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 35 edited versions we read keep these.

  • 6

    Distinctive

    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:

    Ask with structured multiple-choice questions (AskUserQuestion in Claude Code.

    line 27
  2. Distinctive:

    Do not ask about repo (use the current checkout), sub-agents, lint, or release handling — those are fixed by standing policy below.

    line 58
  3. Distinctive:

    Read and follow the composed skills at dispatch time.

    line 83
  4. Very specific:

    Red main is P0: If main is or goes red at any point: pause the current lane, file an issue (per the issue skill), fix it on a branch (per …

    line 88
  5. Distinctive:

    Assess before amplifying: When babysitting PRs you did not implement in this session, review the implementation on its merits.

    line 91
  6. Distinctive:

    Releases: follow the composed skills' release handling (1 PR = 1 release where that is the repo convention).

    line 97
  7. Distinctive:

    Sub-agents: run lanes and babysitters as background sub-agents so the main thread stays free, where the harness supports it.

    line 99

“Common” is measured: kept by at least 6 in 10 of the 35 edited versions of this file we could read. “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

Backlog

Route a backlog session to the right workflow via a short interview, then dispatch to implement-issues and/or babysit-pr. This skill decides and delegates — it implements nothing itself.

Invocation

  • /backlog — run the interview below.
  • Args answer questions in advance; skip any question already answered:
    • /backlog merge / /backlog open-pr
    • /backlog merge #124 #125 — explicit PR list
    • /backlog open-pr #12 #14 — explicit issue list

Interview

Ask with structured multiple-choice questions (AskUserQuestion in Claude Code; plain questions elsewhere). One round per step — this is a router, not a grilling.

Q1 — Goal

What should this session drive toward?

  • merge-pr — take PRs (and optionally fresh issues) all the way to merged, releases included.
  • open-pr — implement issues and stop at merge-ready open PRs; the human merges.

Q2 — branch on the answer

If merge-pr:

What's in scope?

  • All open PRs in the repo (default).
  • Specific PRs — take the list from args or ask.
  • Issues first, then all PRs — run implement-issues on issues without PRs, then babysit everything open.

If open-pr:

Which issues?

  • All open issues without a PR (default).
  • Specific issues — take the list from args or ask.

Do not ask about repo (use the current checkout), sub-agents, lint, or release handling — those are fixed by standing policy below.

Q3 — Plan confirmation (deliberate, keep it)

The interview scopes the session; it does not replace the composed skills' own confirm steps. After triage, present the concrete plan — the issue/PR set, any surprises found (stale issues, no-PR-shaped work, orphaned branches), and any decision the issues themselves reserve for the owner — and confirm before spawning lanes. The owner wants to be in the loop on judgment calls the workflow would otherwise assume; never trade this checkpoint away for fewer clicks.

Routing

  • merge-pr → for the issues-first variant, run the implement-issues skill to open PRs, then run the babysit-pr skill with --merge across the in-scope PRs (one babysitter for all of them, per that skill's guidance). Otherwise go straight to babysit-pr --merge.
  • open-pr → run the implement-issues skill, then run the babysit-pr skill without --merge across the resulting PRs (one babysitter for all of them, per that skill's guidance) until Phase 5 exit conditions hold (threads resolved, checks green). Report PR URLs and stop — never merge in this mode.

Read and follow the composed skills at dispatch time; do not restate their workflows here.

Standing policy (applies to every route)

  • Red main is P0. If main is or goes red at any point: pause the current lane, file an issue (per the issue skill), fix it on a branch (per the pr skill), babysit that PR first, then resume.
  • Assess before amplifying. When babysitting PRs you did not implement in this session, review the implementation on its merits; where you disagree, fix or push back on the PR rather than shepherding it through unchanged.
  • CodeRabbit rate limits do not block exit — now the babysit-pr Step E default; no override needed.
  • Releases: follow the composed skills' release handling (1 PR = 1 release where that is the repo convention).
  • Sub-agents: run lanes and babysitters as background sub-agents so the main thread stays free, where the harness supports it.

Final report

Whatever the route, end with: PRs opened, PRs merged (or n/a), releases merged, blocked lanes with reasons, and any pending human gates.

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.