backlog
Skill25 starsChanged 3 months agoMITView on GitHub
Seed a backlog from the project's documents: the Product Owner reads docs/ (plus the constitution and ROADMAP.md), proposes an ordered list of feature-sized items each traced to a source section, the user edits the list, and on explicit confirmation each item is filed as a GitHub issue that /story-time <n> can import. Use on a new or document-first repo with no backlog, or when a tracker or runner needs proposed work as issues.
36 other projects use a version of this.
Adopted by
Most recently taken up by
- newkayak12/claude-skillstheir own version, first seen Nov 1, 2026
- ellebelle99/backlog-skilltheir own version, first seen Nov 1, 2026
- ovargas/virtual-teamtheir own version, first seen Oct 25, 2026
- nschurmann/hola-aitheir own version, first seen Oct 25, 2026
- dpleshakov/tfsclitheir own version, first seen Oct 20, 2026
- RumbleJack56/skillstheir own version, first seen Oct 20, 2026
Used with
Projects with it also use issue, worktree and 10 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.
AWSSkillissue
Implement a GitHub issue end-to-end — branch, code, test, docs, and commit.
Also in 3 projects that use this
MicrosoftSkillworktree
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
AWSSkillretro
Conduct a retrospective on a coding session.
Also in 4 projects that use this
HashiCorpSkillchangelog
Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.
Also in 3 projects that use this
BlockSkillplan
Draft a TDD, PRD, or lightweight plan in the conversation without committing it.
Also in 4 projects that use this
VercelSkilldeploy
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
Other versions36 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 36
- sammcj/agentic-coding★ 169same name
- nschurmann/hola-ai★ 101same name
- camtrik/agent-trail★ 15same name
- ovargas/virtual-team★ 14same name
- greglas75/zuvo★ 7same name
- gonimar/claude-web-studio★ 4same name
- maxekman/skills★ 4same name
- cirne/agent-skills★ 3same name
- newkayak12/claude-skills★ 3same name
- beeltec/skills★ 2same name
26 more not listed
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 repository12 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- campaignSkill
- charterSkill
- demo-daySkill
- go-liveSkill
- incrementSkill
- look-and-feelSkill
- next-stepsSkill
- peer-reviewSkill
- sparkSkill
- sprint-planSkill
- story-timeSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 2 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 35 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 70
Only new items (and a chosen narrower item) are offered for filing by default.
- Distinctive: line 113
If the user fixes the cause in this conversation, offer to file only the items not yet created, re-confirming per step 7, so nothing is …
- Distinctive: line 122
Never create an issue before the explicit confirmation in step 7.
- Very specific: line 123
Never file an item marked covered, done or partly covered unless the user explicitly overrides that row.
- Very specific: line 125
Never write or modify files under .spark/.
- Very specific: line 126
Every item has a docs/<file>#<section> source (or the constitution's section or ROADMAP entry named as such).
- Very specific: line 129
Every issue carries the generation: 0 line.
“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.
Files
/backlog — Seed a Backlog from docs/ (Product Owner)
An advisory-then-writing ceremony with one gate. The Product Owner proposes
an ordered backlog from the project's own documents; the user edits it; only on
explicit confirmation are issues created. Nothing is written to .spark/, and
no spec is created here: specs belong to /story-time.
Input
Optional: --label <name> (repeatable) or a steer such as "only the MVP". No
other input is needed.
Steps
- Gather the sources yourself. The
product-owneragent cannot read the repo's remote or rungh. Read:docs/(Markdown/text documents only; read each section's heading and lead paragraph, not full bodies, and note file names and headings, as source references need them. Skip binary or non-text files and name what was skipped in the step 9 report),.spark/constitution.mdandROADMAP.mdif present.- If there is no
docs/(or it holds no readable documents) and no constitution, name/charteras the first step and stop there. Never invoke it yourself, and write nothing. Same rule as/next-steps.
- Read the tracker (best effort). Resolve the repo from
origin(as step 6 does; no unambiguousorigincounts as "cannot see") and trygh issue list --repo <owner/repo> --state all --json number,title,state,body,closedAt --limit 200andgh pr list --repo <owner/repo> --state all --json number,title,state,body,mergedAt --limit 200(same call shape as/next-steps, aSPARK issue #110). Ifghis missing, unauthenticated, the repo is unresolved or a call fails, say once, in one line, "Could not see the tickets, proposed items are not checked for duplicates", and behave as without this step (every item isnew). - Delegate to the Product Owner. Invoke the
product-owneragent in its propose backlog mode (## Proposing a Backlogin its definition) with the document excerpts (file + section headings), the issues and merged PRs from step 2 (or "tickets not visible"), the constitution excerpt or "none",ROADMAP.mdif present, and the user's steer. - Show the list as a plan. Present it as a numbered, ordered table: title,
problem statement, size (S/M/L), dependencies, source reference
docs/<file>#<section>. Drop any item that arrives without a source reference, or whose reference names no file and heading you gathered in step 1: nothing is invented. This check is an instruction to you and the agent, not an enforcement; look at every row yourself. Mark each row against the tracker data from step 2 (skip when it could not be read) with aStatuscolumn:new: no open or closed issue, and no merged PR, matches the item's title and scope.covered by #N: an open issue matches title and scope. Not filed.done in #N / PR #M: a closed issue or merged PR delivered it. Not filed.partly covered by #N: an open issue covers only part. Say which of the two you propose: a comment on #N (user posts it; this ceremony never edits or closes issues) or a narrower new item for the uncovered part (retitled, state what is left out). Neither is filed unless the user picks it. Match on title and scope, not on title alone; when unsure, markcovered by #Nand say why. TheSource:line of an issue this ceremony filed earlier also counts as a match, so re-running right after filing yields onlycoveredrows (nothing new). This matching is an instruction to you, not an enforcement: check every row yourself. Onlynewitems (and a chosen narrower item) are offered for filing by default; the user may explicitly override a row.
- Let the user edit. They may drop, merge, reorder or reword items. Apply the edits (re-invoke the agent for merges/rewording if useful) and re-show the list. Repeat until the user confirms the final list or abandons it. Abandoning writes nothing.
- Resolve the repo and labels, once, before filing.
- Repo: from
origin(git remote get-url origin/gh repo view), as in/story-time. Echo the resolvedowner/repoto the user. No unambiguousorigin→ STOP and say so; never guess. - Labels: default none. Use labels passed as arguments; otherwise the
labels:list in the optional.spark/backlog.yml; arguments win. Echo them (or "no labels"). Apply them with--label; do not assume any particular automation behind them.
- Repo: from
- Ask for explicit confirmation to file, naming the count, repo and
labels. If the repo is public, say so here, once: the content of
docs/goes into the issue bodies. Only a yes in this conversation permits step 8. File in order. For each item run
gh issue create --repo <owner/repo> --title '<title>' --body-file -(plus--labelper label), feeding the body on stdin from a single-quoted heredoc (<<'ASPARK_BACKLOG_BODY'). Never put text fromdocs/inside double quotes: the shell would run any backtick or$(...)in it. If any body line equals the delimiter, pick another one: that line would end the heredoc and the shell would run the rest. In the single-quoted title, write each'as'\''. Record each returned issue number; in later bodies, refer to dependencies already filed as#<n>, otherwise by title. The body is exactly:## Problem <short problem statement> **Size:** <S|M|L> **Depends on:** <#n, titles, or none> **Source:** <docs/<file>#<section>, or the constitution / ROADMAP.md section> generation: 0This is the shape
/story-time <n>imports as the idea. Ifghis missing, unauthenticated or a call fails, stop, report the real error and list the issues created so far. Never retry silently or claim success. If the user fixes the cause in this conversation, offer to file only the items not yet created, re-confirming per step 7, so nothing is duplicated.- Close with a report stating: repo, issues created (number + title), items skipped as covered/done (with #N), the "Could not see the tickets" line if it applied,
labels applied, items dropped for lack of a source, files in
docs/skipped as non-text in step 1 (or "none"), and that/story-time <n>or/sparkstarts any of them.
Rules
- Never create an issue before the explicit confirmation in step 7.
- Never file an item marked
covered,doneorpartly coveredunless the user explicitly overrides that row. Never edit or close existing issues. - Never write or modify files under
.spark/. - Every item has a
docs/<file>#<section>source (or the constitution's section or ROADMAP entry named as such); otherwise it is not proposed. - Labels are optional and tracker-agnostic; default is none.
- Every issue carries the
generation: 0line.
Handoff
- Issues filed →
/story-time <n>or/sparkper issue, on the user's go. - User abandons → stop; nothing persists.
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
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.

