agentleFS
richkuorichkuo/rk-skills/skills/github-issue-format/SKILL.md

github-issue-format

Skill50 starsChanged 4 days agoMITView on GitHub

Required format for creating or editing any GitHub issue — [C<score>] title convention, complexity rationale line, complete-body rule, mandatory Plain simple English section, attribution footer, milestone title rule. Load BEFORE creating or editing a GitHub issue or milestone.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

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

    Every milestone title you create or rename is one hyphenated token with no spaces (MCP-Read-foundations, Backtest-live-parity).

    line 15
  2. Very specific:

    Before you assign an issue to a milestone that has spaces in its title, rename that milestone to the hyphenated form (gh api -X PATCH …

    line 16
  3. Distinctive:

    Never create a placeholder, stub, or empty-bodied issue: Every issue gets a complete body at creation, even in a batch.

    line 20

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

GitHub issue format

Title

  • [C<score>] <title>: a plain-simple-English sentence in ASD-STE100, precise about component and behavior, e.g. [C95] Orders can be filled twice when two fills arrive at the same moment.
  • The complexity score (0–100) is a model and effort routing signal. validate-issue step 6 owns the formula, axes, and routing table; never restate or approximate them here.

Milestone

  • Every milestone title you create or rename is one hyphenated token with no spaces (MCP-Read-foundations, Backtest-live-parity). This holds for every path that creates one: a batch from prd-to-issues, a split of one issue into follow-ups, or a manual request.
  • Before you assign an issue to a milestone that has spaces in its title, rename that milestone to the hyphenated form (gh api -X PATCH repos/<owner>/<repo>/milestones/<number> -f title=<new-title>). The rename keeps every issue on the milestone. Quote a title that still has spaces in every gh call.

Body

  • Never create a placeholder, stub, or empty-bodied issue. Every issue gets a complete body at creation, even in a batch. If a follow-up is not ready to spec, track it in the parent issue or notes until it is.
  • Section order: complexity rationale line, ## Problem, ## Goal, ## Approach, ## Acceptance criteria, ## Plain simple English, then any Execution block, then the attribution footer.
  • Complexity rationale line (first line of the body): matches the title prefix and ends with an explicit plan signal: **Complexity: 95/100** — Capability 3 (Risk 4, Uncertainty 2 — money/data-integrity on order-fill path); Volume 20 (Scope 4, Coupling 3, Verification 3) — Opus 5.5, high · plan: yes. The line always carries all five axis grades; the validate-issue scoring reference owns the axes and their anchors.
  • plan signal: · plan: yes when the score is ≥ 75 (a plan is posted before the build, by Opus 5.5 at xhigh when the score is ≥ 85 and at high below 85, unless a Plan model: Fable 5.1 stamp asks for Fable, whose plan runs only at high; the builder is Opus 5.5 at high); · plan: no below 75. Always write it. Compatibility (owned here): the signal and the Execution block key were once spelled · fableplan: yes|no and **fableplan first:**, and the PR-title suffix , fableplan. Every reader accepts both spellings, every writer emits only plan, and a restamp rewrites an old spelling to the new one. Fable 5.1 effort tiers follow the LLM Attribution Footer section of CLAUDE.md.
  • ## Plain simple English is mandatory on every issue: one short paragraph under 55 words in ASD-STE100, per the CLAUDE.md/AGENTS.md Response Style definition. State what is wrong or missing and why it matters, for a reader who knows the product but not the code. Never restate the approach, list file paths or symbols, or give a time or effort estimate there. An edit that rewrites body prose adds the section when it is missing; an edit that changes only machine metadata (the Execution block, the [C<score>] title prefix, or the complexity rationale line, as a rescore-only edit does) leaves every prose section unchanged and does not add it.
  • LLM Attribution Footer ends the body: Created for a new issue, Validated when a validation pass produced the edit (validate-issue and its wrappers), Updated for any other edit. Stack the new line under the existing ones; never replace them, and never append an exact duplicate of a line already there.
  • Project precedence: a repo CLAUDE.md issue or footer format overrides this default.

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.