agentleFS
Sign inStart free
GreatFigure8GreatFigure8/Claude-Skills/Skills/bmn-issue/SKILL.md

bmn-issue

Skill0 starsChanged 4 months agoUnlicenseView on GitHub

Create a GitHub story issue for the dev-bother-me-nope pipeline from a one-line summary. Use when the user runs /bmn-issue <summary> or asks to file a story issue for bmn. The text after the command is the summary; the skill drafts the template fields and creates the issue with the bmn label.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

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

    Use that owner/repo for every gh call.

    line 18
  2. Very specific:

    Constraints and out of scope: only what the summary states, else None stated.

    line 27
  3. Very specific:

    Create the issue: Ensure the label exists, then create the issue: gh label create bmn --color 5319e7 --description "Work to run through …

    line 52
  4. Distinctive:

    Create the issue only from the summary the user gave with the command.

    line 62
  5. Distinctive:

    Don't ask follow-up questions unless the summary is empty.

    line 64
  6. Distinctive:

    Don't set assignees, milestones, or projects unless asked.

    line 66

≈ “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

bmn-issue

Turns a one-line summary into a GitHub story issue in the current repo, shaped like the repo's "Story for dev-bother-me-nope" template (.github/ISSUE_TEMPLATE/story.yml) and labelled bmn, so dev-bother-me-nope can read it as a story.

Steps

  1. Summary. The text after /bmn-issue is the summary. If it is empty, ask for one line and stop there. Do not invent a summary.
  2. Repo. gh repo view --json nameWithOwner -q .nameWithOwner in the working directory. Use that owner/repo for every gh call. If it fails, say the directory is not a GitHub checkout and stop.
  3. Draft the fields. Expand only from what the summary says. Anything you infer is marked (inferred) so Jonathan can see it.
    • Title: [story] <summary>, keeping the summary's wording.
    • Goal: one or two sentences restating what should be true when this is done.
    • Acceptance criteria: 2 to 5 testable lines, each starting - [ ]. Each is one outcome a test can check. Mark a line (inferred) if you added it beyond the summary.
    • Constraints and out of scope: only what the summary states, else None stated.
    • Touches a screen a person looks at?: Yes if the summary names a page, screen, button, form, or other visible UI; otherwise No. Mark it (inferred).

  4. Write the body to <scratchpad>/bmn-issue-body.md in the same headings the template renders, so the issue reads like one filed from the form:

    ### Goal

<goal>

### Acceptance criteria

<criteria>

### Constraints and out of scope

<constraints>

### Touches a screen a person looks at?

<Yes|No>
  5. Create the issue. Ensure the label exists, then create the issue: gh label create bmn --color 5319e7 --description "Work to run through dev-bother-me-nope" --repo <owner/repo> || true gh issue create --repo <owner/repo> --title "<title>" --body-file <body file> --label bmn
  6. Report. Print the issue URL, then the lines you marked (inferred) so Jonathan can edit any of them. Don't restate the whole body. If he wants a change, edit the issue with gh issue edit <n> --repo <owner/repo> --body-file <file>, not a new issue.

Rules

  • Create the issue only from the summary the user gave with the command. Don't pull in text from other sources.
  • Don't ask follow-up questions unless the summary is empty. Draft, create, and list the inferred parts.
  • Don't set assignees, milestones, or projects unless asked.

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