agentleFS
Sign inStart free
prestariusprestarius/jet-skills-stack/skills/plan-to-issues/SKILL.md

plan-to-issues

Skill1 starsChanged 2 months agoMITView on GitHub

Split a repo's plan file into GitHub issues with gh, one per unit of work, in dependency order, after the human has approved the split as a table and said what every issue must carry. Use when a plan is written and has no issues yet, when the user says "turn the plan into issues", "split this into tickets", or before coordinator-workers can hand issues to workers. Not for issues from data or reports (that is a per-repo list, not a plan).

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 5

    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. Very specific:

    Read the plan, AGENTS.md/CLAUDE.md and docs/adr/ (or wherever the repo keeps its rules).

    line 17
  2. Distinctive:

    Ask the human what every issue must carry (fields, labels, wording), unless it is already written down in this session or in the repo.

    line 22
  3. Distinctive:

    Create each issue in dependency order, so blocked-by can cite real numbers.

    line 28
  4. Distinctive:

    Don't paste the whole plan into one issue, and don't keep issues only in chat.

    line 54
  5. Distinctive:

    Don't invent sections the plan doesn't have.

    line 55
  6. Distinctive:

    Don't create a repo or issues before the human's yes.

    line 56

“Common” is measured: kept by at least 6 in 10 of the 6 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

plan-to-issues

Turns a plan file (plan.md, docs/plans/<name>.md, whatever the repo uses) into GitHub issues that a worker can pick up cold. Easiest with gh, authenticated, in a shell this agent can run. Running the issues afterwards is coordinator-workers.

Steps

  1. Read the plan, AGENTS.md/CLAUDE.md and docs/adr/ (or wherever the repo keeps its rules).
  2. Draft the split as a table: title · plan section · scope · done when · blocked by. One issue per unit of work. Put the shared contract (types, schema, signature) in its own first issue when more than one issue depends on it.
  3. Stop and show the table to the human. Publish nothing until they approve it.
  4. Ask the human what every issue must carry (fields, labels, wording), unless it is already written down in this session or in the repo. Offer this default and use it on "default": first line Source: <plan file> § <n>, then ## Scope, ## Done when, ## Blocked by (real issue numbers, or none), and the label plan:<plan name>. A reviewer sorts by the first line and the label. Once the human decides, write the shape into the repo (its skill or AGENTS.md) so the next session does not ask again.

  5. Create each issue in dependency order, so blocked-by can cite real numbers. Write the body to a file first; long quoted one-liners break in zsh.

    gh issue create --title "<title>" --body-file <tmp.md> --label "plan:<name>"
  6. Record every issue URL from gh's output (not from memory) and reply with the list.

Closing one, with the repo's closing comment shape (AGENTS.md often prescribes it):

gh issue close <n> -c "<closing comment>"

An issue whose "done when" is someone else's act (a review, a reply, a scheduled run) stays open until that act lands, with a comment saying what it waits on. A clean-up issue is blocked by it.

No gh

Steps 1–4 hold either way. GitHub reachable another way (a connector, the REST API, the web UI): the same issues, made that way. GitHub out of reach altogether: write them as files in docs/issues/ in the repo's format, then commit and push.

Don'ts

  • Don't paste the whole plan into one issue, and don't keep issues only in chat.
  • Don't invent sections the plan doesn't have. If the plan is unclear, ask.
  • Don't create a repo or issues before the human's yes; say who will see them.

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