forge-create-issue
Skill86 starsChanged 8 days agoMITView on GitHub
Plan and create well-structured Issues with the user (GitHub, markdown plan/ folder, or other providers), researching the codebase first and confirming the approach and draft interactively. Use when the user or an orchestrating agent asks for forge-create-issue or to file an Issue for work that is already understood, not when a bug merely comes up in conversation; use forge-shape first when the idea is still vague.
In this repository10 other files it gives its agents.
- AGENTS.mdAGENTS.md
- forge-address-pr-feedbackSkill
- forge-batchSkill
- forge-guardSkill
- forge-implementSkill
- forge-landSkill
- forge-reflectSkill
- forge-setup-projectSkill
- forge-shapeSkill
- forge-shipSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
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
- Distinctive: line 17
If no argument is provided, ask the user what they'd like to create an Issue for.
- Distinctive: line 27
Verify external dependencies are accessible if relevant — flag broken ones before proceeding.
- Distinctive: line 31
Use AskUserQuestion to gather what the code can't answer:
- Distinctive: line 38
Skip this step: if the input already contains a chosen approach with rationale — the decision was already made through deliberate analysis.
- Distinctive: line 61
If splitting makes sense, offer: an epic with sub-issues (the default for several Issues), linked Issues without a parent, or a single …
- Very specific: line 65
Title: Use conventional commit format — <type>(<scope>): <description>
- Distinctive: line 95
When a view explains the Proposed Solution better than prose, include one (see visuals).
- Very specific: line 111
Next step: Use forge-implement to implement the Issue.
≈ “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.
Files
Create Issue
Collaboratively plan and create well-structured Issues through interactive discussion. The Issue is created in the project's Issue tracker — see issue-operations for provider detection.
Input
The Issue idea or problem description: $ARGUMENTS
Optional: -- <additional context> for execution guidance.
If no argument is provided, ask the user what they'd like to create an Issue for.
Process
Step 1: Research the Codebase
Parse the user's input, then explore the relevant code before asking anything:
- Find related existing implementations and patterns
- Identify integration points and potential reuse
Verify external dependencies are accessible if relevant — flag broken ones before proceeding.
Step 2: Clarify
Use AskUserQuestion to gather what the code can't answer:
- Problem context — what triggered this, who's affected, current vs desired behavior
- Success criteria — how will we know this is done
- Constraints — technical limitations, dependencies
Step 3: Present Alternative Approaches
Skip this step if the input already contains a chosen approach with rationale — the decision was already made through deliberate analysis. Proceed directly to Step 4.
Otherwise, present the structurally distinct approaches you found — usually two to four — rather than a single recommendation; the choice belongs to the user.
For each approach:
- One-line summary
- How it works (brief)
- Pros and cons
- Relative complexity (Low / Medium / High)
- Key files affected
Let the user choose or combine approaches via AskUserQuestion.
Step 4: Assess Scope
Evaluate if this should be one Issue or multiple.
Split when: distinct deliverables, different codebase areas, parallelizable work, or effort exceeds 1-2 days.
Keep together when: tightly coupled changes or splitting adds coordination overhead.
When splitting, slice vertically — each Issue is a thin end-to-end path (see vertical-slicing). Classify each as AFK or HITL (see afk-vs-hitl.md). Order by dependency, and note which Issues each one is blocked by. A forge-shape breakdown arrives sliced, classified, and ordered: check it against the same rules and re-slice only a horizontal Issue.
If splitting makes sense, offer: an epic with sub-issues (the default for several Issues), linked Issues without a parent, or a single Issue.
Step 5: Draft the Issue
Title: Use conventional commit format — <type>(<scope>): <description>
Labels: Discover what labels exist before applying any — see issue-operations. Apply at least one type label and relevant area labels.
Body structure:
## Summary
[1-2 sentences]
**Execution mode:** [AFK | HITL] <!-- markdown provider: use the `mode` frontmatter field instead -->
## Problem / Motivation
[Why this needs to exist]
## Proposed Solution
[Chosen approach with implementation details]
### Alternatives Considered
[Other approaches and why they weren't chosen]
### Implementation Constraints
[When applicable: preferred libraries, config locations, patterns to follow, external dependencies]
## Acceptance Criteria
- [ ] [Specific, testable criteria]
- [ ] Tests added/updated
- [ ] Documentation updated (if applicable)When a view explains the Proposed Solution better than prose, include one (see visuals).
Step 6: Review and Create
Present the draft to the user and iterate until satisfied (use AskUserQuestion for approve/revise decisions). Then create the Issue using the project's Issue tracker — see issue-operations for provider-specific mechanics. For several Issues, create them in dependency order, then Link Issues: each sub-issue to its parent, and each Issue to the Issues it is blocked by.
Share the Issue reference. Suggest using forge-implement to start implementation.
Guidelines
- Be curious — challenge assumptions, ask "why" and "what if"
- Don't over-specify — leave room for implementer judgment
- No time estimates in the Issue — the Step 4 effort heuristic is for deciding splits, not for the Issue body
Related Skills
Next step: Use forge-implement to implement the Issue.
Example Usage
/forge-create-issue add dark mode support
/forge-create-issue add dark mode support -- keep it to a single Issue
/forge-create-issueDoes 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.

