forge-create-issue

Name: forge-create-issue
Author: mgratzer

32installs5forks

How to install forge-create-issue?

mgratzer/forge/forge-create-issue

$npx -y skills add mgratzer/forge --skill forge-create-issue

Installs into the current project.

Summary

Collaboratively plan and create well-structured Issues through interactive discussion. Use when the user wants to create an Issue, plan a feature, report a bug, or scope out work for implementation. Supports GitHub, markdown plan/ folder, and other providers.

Files · 1

View on GitHub

SKILL.md

1	# Create Issue
2
3	Collaboratively plan and create well-structured Issues through interactive discussion. The Issue is created in the project's Issue tracker — see [CONTEXT.md](../../CONTEXT.md) for provider detection.
4
5	## Input
6
7	The issue idea or problem description: $ARGUMENTS
8
9	If no argument is provided, ask the user what they'd like to create an issue for.
10
11	## Process
12
13	### Step 1: Understand and Clarify
14
15	Parse the user's input, then use AskUserQuestion to gather:
16	- Problem context — what triggered this, who's affected, current vs desired behavior
17	- Success criteria — how will we know this is done
18	- Constraints — technical limitations, dependencies
19
20	### Step 2: Research the Codebase
21
22	Before proposing solutions, explore relevant code:
23	- Find related existing implementations and patterns
24	- Identify integration points and potential reuse
25	- Look for similar past implementations
26
27	Verify external dependencies are accessible if relevant — flag broken ones before proceeding.
28
29	### Step 3: Present Alternative Approaches
30
31	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.
32
33	Otherwise, always present 2-4 different approaches. Never jump to a single solution.
34
35	For each approach:
36	- One-line summary
37	- How it works (brief)
38	- Pros and cons
39	- Relative complexity (Low / Medium / High)
40	- Key files affected
41
42	Let the user choose or combine approaches.
43
44	### Step 4: Assess Scope
45
46	Evaluate if this should be one Issue or multiple.
47
48	Split when: distinct deliverables, different codebase areas, parallelizable work, or effort exceeds 1-2 days.
49
50	Keep together when: tightly coupled changes or splitting adds coordination overhead.
51
52	When splitting, slice vertically — each Issue is a thin end-to-end path (see [vertical-slicing](../_shared/vertical-slicing.md)). Classify each as AFK or HITL (see [afk-vs-hitl.md](references/afk-vs-hitl.md)). Order by dependency.
53
54	If splitting makes sense, offer: single Issue, multiple linked Issues, or epic with sub-issues.
55
56	### Step 5: Draft the Issue
57
58	Title: Use conventional commit format — `<type>(<scope>): <description>`
59
60	Labels: When using GitHub, discover available labels with `gh label list`. When using the markdown provider, choose labels freely — there is no predefined set. Apply at least one type label and relevant area labels.
61
62	Body structure:
63
64	```markdown
65	## Summary
66	[1-2 sentences]
67
68	## Problem / Motivation
69	[Why this needs to exist]
70
71	## Proposed Solution
72	[Chosen approach with implementation details]
73
74	### Alternatives Considered
75	[Other approaches and why they weren't chosen]
76
77	### Implementation Constraints
78	[When applicable: preferred libraries, config locations, patterns to follow, external dependencies]
79
80	## Acceptance Criteria
81	- [ ] [Specific, testable criteria]
82	- [ ] Tests added/updated
83	- [ ] Documentation updated (if applicable)
84	```
85
86	### Step 6: Review and Create
87
88	Present the draft to the user. Iterate until satisfied. Then create the Issue using the project's Issue tracker — see [issue-operations](../_shared/issue-operations.md) for provider-specific mechanics.
89
90	For GitHub epics, create the parent issue first, then sub-issues with `--parent <PARENT_NUMBER>`.
91
92	Share the issue reference. Suggest using `forge-implement` to start implementation.
93
94	## Guidelines
95
96	- Be curious — challenge assumptions, ask "why" and "what if"
97	- Explore first — always research the codebase before proposing solutions
98	- Never skip alternatives — even if one approach seems obvious
99	- Don't over-specify — leave room for implementer judgment
100	- No time estimates
101
102	## Related Skills
103
104	Next step: Use `forge-implement` to implement the issue.
105
106	## Example Usage
107
108	```
109	/forge-create-issue add dark mode support
110	/forge-create-issue
111	```

People who liked this also viewed

6 picks

Type

forge-create-issue

32installs5forks

View on GitHub

How to install forge-create-issue?

mgratzer/forge/forge-create-issue

$npx -y skills add mgratzer/forge --skill forge-create-issue

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Create Issue
2
3	Collaboratively plan and create well-structured Issues through interactive discussion. The Issue is created in the project's Issue tracker — see [CONTEXT.md](../../CONTEXT.md) for provider detection.
4
5	## Input
6
7	The issue idea or problem description: $ARGUMENTS
8
9	If no argument is provided, ask the user what they'd like to create an issue for.
10
11	## Process
12
13	### Step 1: Understand and Clarify
14
15	Parse the user's input, then use AskUserQuestion to gather:
16	- Problem context — what triggered this, who's affected, current vs desired behavior
17	- Success criteria — how will we know this is done
18	- Constraints — technical limitations, dependencies
19
20	### Step 2: Research the Codebase
21
22	Before proposing solutions, explore relevant code:
23	- Find related existing implementations and patterns
24	- Identify integration points and potential reuse
25	- Look for similar past implementations
26
27	Verify external dependencies are accessible if relevant — flag broken ones before proceeding.
28
29	### Step 3: Present Alternative Approaches
30
31	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.
32
33	Otherwise, always present 2-4 different approaches. Never jump to a single solution.
34
35	For each approach:
36	- One-line summary
37	- How it works (brief)
38	- Pros and cons
39	- Relative complexity (Low / Medium / High)
40	- Key files affected
41
42	Let the user choose or combine approaches.
43
44	### Step 4: Assess Scope
45
46	Evaluate if this should be one Issue or multiple.
47
48	Split when: distinct deliverables, different codebase areas, parallelizable work, or effort exceeds 1-2 days.
49
50	Keep together when: tightly coupled changes or splitting adds coordination overhead.
51
52	When splitting, slice vertically — each Issue is a thin end-to-end path (see [vertical-slicing](../_shared/vertical-slicing.md)). Classify each as AFK or HITL (see [afk-vs-hitl.md](references/afk-vs-hitl.md)). Order by dependency.
53
54	If splitting makes sense, offer: single Issue, multiple linked Issues, or epic with sub-issues.
55
56	### Step 5: Draft the Issue
57
58	Title: Use conventional commit format — `<type>(<scope>): <description>`
59
60	Labels: When using GitHub, discover available labels with `gh label list`. When using the markdown provider, choose labels freely — there is no predefined set. Apply at least one type label and relevant area labels.
61
62	Body structure:
63
64	```markdown
65	## Summary
66	[1-2 sentences]
67
68	## Problem / Motivation
69	[Why this needs to exist]
70
71	## Proposed Solution
72	[Chosen approach with implementation details]
73
74	### Alternatives Considered
75	[Other approaches and why they weren't chosen]
76
77	### Implementation Constraints
78	[When applicable: preferred libraries, config locations, patterns to follow, external dependencies]
79
80	## Acceptance Criteria
81	- [ ] [Specific, testable criteria]
82	- [ ] Tests added/updated
83	- [ ] Documentation updated (if applicable)
84	```
85
86	### Step 6: Review and Create
87
88	Present the draft to the user. Iterate until satisfied. Then create the Issue using the project's Issue tracker — see [issue-operations](../_shared/issue-operations.md) for provider-specific mechanics.
89
90	For GitHub epics, create the parent issue first, then sub-issues with `--parent <PARENT_NUMBER>`.
91
92	Share the issue reference. Suggest using `forge-implement` to start implementation.
93
94	## Guidelines
95
96	- Be curious — challenge assumptions, ask "why" and "what if"
97	- Explore first — always research the codebase before proposing solutions
98	- Never skip alternatives — even if one approach seems obvious
99	- Don't over-specify — leave room for implementer judgment
100	- No time estimates
101
102	## Related Skills
103
104	Next step: Use `forge-implement` to implement the issue.
105
106	## Example Usage
107
108	```
109	/forge-create-issue add dark mode support
110	/forge-create-issue
111	```

People who liked this also viewed

6 picks

Type