agentleFS
Sign inStart free
ralphkraussralphkrauss/agent-orchestrator/.agents/skills/create-issue/SKILL.md

create-issue

Skill4 starsChanged 6 months agoMITView on GitHub

Create a structured GitHub issue with proper context, acceptance criteria, and labels. Gathers context from code, docs, and conversation before drafting. Use when the user mentions "create issue", "open issue", "new issue", "file issue", "report bug", "feature request", or wants to create a GitHub issue.

  • Commits and pushes

We split this skill into the rules it gives an agent

9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 47 edited versions we read keep these.

  • 7

    Distinctive

    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. Distinctive:

    ACCEPTANCE CRITERIA ARE MANDATORY: Every issue must have testable acceptance criteria

    line 13
  2. Distinctive:

    NO DUPLICATE ISSUES: Search for existing issues before creating

    line 14
  3. Very specific:

    COMMENT PREFIX: If posting follow-up comments, start with [Claude Code]:

    line 16
  4. Distinctive:

    If unclear, ask the user.

    line 33
  5. Distinctive:

    Search existing issues to avoid duplicates:

    line 37
  6. Very specific:

    Search existing issues using the available GitHub tools (query: repo:{owner}/{repo} {keywords from the issue}).

    line 39
  7. Distinctive:

    If potential duplicates found:

    line 41
  8. Distinctive:

    No acceptance criteria that duplicate what other issues already track

    line 110
  9. Distinctive:

    Create a branch: if the user wants to start working immediately:

    line 132

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

Create Issue

Structured workflow for creating GitHub issues. Gathers context from the codebase, conversation, and docs to produce well-formed issues with acceptance criteria, labels, and cross-references.

Critical Rules

  1. CONTEXT FIRST: Investigate the codebase before writing the issue — reference specific files, functions, and patterns
  2. ACCEPTANCE CRITERIA ARE MANDATORY: Every issue must have testable acceptance criteria
  3. NO DUPLICATE ISSUES: Search for existing issues before creating
  4. LINK RELATED WORK: Reference related issues, PRs, and code locations
  5. COMMENT PREFIX: If posting follow-up comments, start with **[Claude Code]:**

Instructions

Step 1: Determine Issue Type

From the user's request, classify the issue:

TypeTemplateLabels
bugBug report with repro stepsbug
featureFeature request with scopeenhancement
taskImplementation task (often from PR triage or planning)task
choreMaintenance, cleanup, tech debtchore

If unclear, ask the user.

Step 2: Search for Duplicates

Search existing issues to avoid duplicates:

Search existing issues using the available GitHub tools (query: repo:{owner}/{repo} {keywords from the issue}). Check both open and recently closed issues.

If potential duplicates found:

Found potentially related issues:
- #{number}: {title} ({state})
- #{number}: {title} ({state})

Is this a duplicate, or should we create a new issue? (new/duplicate of #N/related to #N)

Step 3: Gather Context

Investigate the codebase for relevant context:

  1. Search code — grep/glob for related files, functions, patterns
  2. Read docs — check docs/ for relevant architecture or guides
  3. Check git history — recent changes in the affected area
  4. Check related issues/PRs — cross-reference for context

Present your findings:

Context gathered:
- Affected area: {files/modules}
- Related docs: {doc paths}
- Related issues: {#numbers}
- Current behavior: {what happens now}
- Relevant patterns: {what the codebase already does}

Step 4: Draft the Issue

Present a draft to the user for review:

Draft Issue:

Title: {concise title, under 70 characters}
Labels: {labels}
Milestone: {if applicable}

---

## Summary
{1-3 sentences describing the issue}

## Context
{relevant background — affected files, current behavior, related issues}

## Acceptance Criteria
- [ ] {specific, testable criterion}
- [ ] {specific, testable criterion}
- [ ] {specific, testable criterion}

## Notes
{implementation hints, links to docs, constraints}

## Related
- #{number} — {brief description of relationship}
---

Review this draft. Any changes? (Y to create/edit instructions)

Draft quality checklist:

  • Title is specific and actionable (not "Fix bug" or "Update code")
  • Summary explains the why, not just the what
  • Acceptance criteria are testable — someone can check each box and know it's done
  • Context references actual code locations when applicable
  • No acceptance criteria that duplicate what other issues already track

Step 5: Create the Issue

Once the user approves:

gh issue create \
  --title "{title}" \
  --label "{label1},{label2}" \
  --body "{body}" \
  2>&1

Or create the issue using the available GitHub tools (owner, repo, title, body, labels).

Step 6: Post-Creation

After creating:

  1. Report the issue URL to the user
  2. Link to related issues — if the issue references other issues, add a comment on those issues noting the new one
  3. Create a branch if the user wants to start working immediately:
    • Branch name: {issue-number}-{slug} (e.g., 394-add-missing-skills)
    • git checkout -b {branch} origin/main && git push -u origin {branch}
Created: #{number} — {title}
URL: {url}
Labels: {labels}

Want me to create a branch and start working on this? (Y/N)

Checklist

  • Issue type determined
  • Duplicate search completed
  • Codebase context gathered
  • Draft reviewed by user
  • Issue created on GitHub
  • Related issues cross-linked
  • Branch created (if requested)

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.

Reviews can't be read right now.

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