create-issue

Name: create-issue
Author: dsifry

361stars51forks

How to install create-issue?

dsifry/metaswarm/create-issue

$npx -y skills add dsifry/metaswarm --skill create-issue

Installs into the current project.

Summary

Create comprehensive GitHub issues with TDD plans, acceptance criteria, and agent instructions for autonomous PR lifecycle management

Files · 1

View on GitHub

SKILL.md

1	# Create GitHub Issue Skill
2
3	Create comprehensive, well-structured GitHub issues with embedded agent instructions for autonomous PR lifecycle management.
4
5	## Overview
6
7	This skill generates GitHub issues that are self-contained work packets. Each issue includes:
8
9	1. Problem/Feature specification with clear scope
10	2. Technical specification with types, schemas, and API design
11	3. TDD Implementation Plan with test-first cycles
12	4. Acceptance Criteria checklist
13	5. Agent Instructions for complete PR lifecycle (implementation → review → merge)
14
15	## Usage
16
17	```
18	/create-issue
19	```
20
21	## Interactive Flow
22
23	### Step 1: Issue Type
24
25	Ask the user:
26
27	```
28	What type of issue is this?
29	1. Feature - New functionality
30	2. Bug - Something broken
31	3. Refactor - Improving existing code
32	```
33
34	### Step 2: Brief Description
35
36	```
37	Brief description of the problem or feature? (1-2 sentences)
38	```
39
40	### Step 3: Complexity Assessment
41
42	```
43	What's the estimated complexity?
44	1. Simple (< 1 day)
45	2. Medium (2-5 days)
46	3. Complex (> 1 week)
47	```
48
49	### Step 4: Context Gathering
50
51	```
52	Any related files, services, or issues I should reference?
53	(Or say "explore codebase" and I'll investigate)
54	```
55
56	### Step 5: Generate Issue
57
58	Based on inputs, generate the full issue using the appropriate template below.
59
60	---
61
62	## Issue Templates
63
64	### Feature Template
65
66	````markdown
67	## Summary
68
69	[1-2 sentence description]
70
71	Complexity: [simple\|medium\|complex]
72	Estimated Effort: [X days]
73
74	---
75
76	## Problem
77
78	[What problem does this solve? Why is it needed?]
79
80	### Evidence
81
82	[Logs, metrics, user reports, or reasoning]
83
84	### Scope
85
86	- IN SCOPE: [what's included]
87	- OUT OF SCOPE: [what's explicitly NOT included]
88
89	---
90
91	## Architecture Decision
92
93	Decision: [What approach will be taken]
94	Rationale: [Why this approach, why NOT alternatives]
95
96	---
97
98	## Technical Specification
99
100	### Types/Interfaces
101
102	```typescript
103	// Key type definitions
104	```
105	````
106
107	### Zod Schemas (if applicable)
108
109	```typescript
110	// Validation schemas
111	```
112
113	### API Endpoints (if applicable)
114
115	\| Method \| Path \| Description \|
116	\| ------ \| ---- \| ----------- \|
117
118	### Database Changes (if applicable)
119
120	[Schema changes, migrations needed]
121
122	---
123
124	## TDD Implementation Plan
125
126	### Cycle 1: [Happy Path]
127
128	```typescript
129	it("should [expected behavior]", async () => {
130	// Test code
131	});
132	```
133
134	### Cycle 2: [Error Handling]
135
136	```typescript
137	it("should handle [error case]", async () => {
138	// Test code
139	});
140	```
141
142	### Cycle 3: [Edge Cases]
143
144	### Cycle 4: [Integration]
145
146	---
147
148	## Error Handling
149
150	\| Scenario \| Behavior \| Logging \|
151	\| -------- \| -------- \| ------- \|
152
153	---
154
155	## Implementation Phases
156
157	### Phase 1: [Core] (High Priority)
158
159	- [ ] Task 1
160	- [ ] Task 2
161
162	### Phase 2: [Enhancement] (Medium Priority)
163
164	- [ ] Task 3
165
166	---
167
168	## Files to Create/Modify
169
170	- NEW: `path/to/new/file.ts`
171	- `path/to/existing/file.ts` - [what changes]
172
173	---
174
175	## Acceptance Criteria
176
177	- [ ] All TDD cycles implemented with passing tests
178	- [ ] Zero TypeScript errors (`pnpm typecheck`)
179	- [ ] Zero lint warnings (`pnpm lint`)
180	- [ ] All tests pass (`pnpm test --run`)
181	- [ ] JSDoc documentation added to all new/modified services
182	- [ ] `docs/SERVICE_INVENTORY.md` updated (if new/modified service)
183	- [ ] Mock factories added/updated (if new service)
184	- [ ] PR created and all CI checks pass
185	- [ ] ALL code review comments addressed (see Agent Instructions)
186	- [ ] All review threads resolved
187	- [ ] PR approved and merged
188
189	---
190
191	## Agent Instructions
192
193	CRITICAL: Follow this protocol when implementing this issue. A PR is NOT complete until ALL steps are done.
194
195	### Phase 0: Research (BEFORE writing any code)
196
197	Read these files first to avoid reinventing the wheel:
198
199	1. Service Inventory - Check for existing services that might already do what you need:
200
201	```bash
202	# Read the service inventory
203	cat docs/SERVICE_INVENTORY.md
204	# Or search for specific functionality
205	grep -i "embedding\\|search\\|cache" docs/SERVICE_INVENTORY.md
206	```
207
208	2. Mock Factories - Review existing mocks to reuse patterns:
209
210	```bash
211	ls src/test-utils/factories/
212	```
213
214	3. Similar Services - Find services with similar patterns:
215	```bash
216	# Find orchestrator patterns
217	ls src/lib/services/-orchestrator.ts
218	# Find persistence patterns
219	ls src/lib/services/-persistence.ts
220	```
221
222	Why this matters: Reusing existing services and patterns saves time, maintains consistency, and prevents duplicate code.
223
224	### Phase A: Implementation
225
226	1. Create feature branch from main: `git checkout -b feat/[short-name]`
227	2. Follow TDD cycles exactly as specified above
228	3. Add JSDoc documentation to all new/modified services
229	4. Run local validation: `pnpm lint && pnpm typecheck && pnpm test --run`
230	5. Update service inventory (if new service)
231	6. Create PR with comprehensive description using `/create-pr`
232
233	### Phase B: C

People who liked this also viewed

6 picks

Type

caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026259k92k
git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026157k181k
setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026152k181k
resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026146k181k
using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026143k259k
finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026140k259k

create-issue

361stars51forks

View on GitHub

How to install create-issue?

dsifry/metaswarm/create-issue

$npx -y skills add dsifry/metaswarm --skill create-issue

Installs into the current project.

Summary

Create comprehensive GitHub issues with TDD plans, acceptance criteria, and agent instructions for autonomous PR lifecycle management

Files · 1

View on GitHub

SKILL.md

1	# Create GitHub Issue Skill
2
3	Create comprehensive, well-structured GitHub issues with embedded agent instructions for autonomous PR lifecycle management.
4
5	## Overview
6
7	This skill generates GitHub issues that are self-contained work packets. Each issue includes:
8
9	1. Problem/Feature specification with clear scope
10	2. Technical specification with types, schemas, and API design
11	3. TDD Implementation Plan with test-first cycles
12	4. Acceptance Criteria checklist
13	5. Agent Instructions for complete PR lifecycle (implementation → review → merge)
14
15	## Usage
16
17	```
18	/create-issue
19	```
20
21	## Interactive Flow
22
23	### Step 1: Issue Type
24
25	Ask the user:
26
27	```
28	What type of issue is this?
29	1. Feature - New functionality
30	2. Bug - Something broken
31	3. Refactor - Improving existing code
32	```
33
34	### Step 2: Brief Description
35
36	```
37	Brief description of the problem or feature? (1-2 sentences)
38	```
39
40	### Step 3: Complexity Assessment
41
42	```
43	What's the estimated complexity?
44	1. Simple (< 1 day)
45	2. Medium (2-5 days)
46	3. Complex (> 1 week)
47	```
48
49	### Step 4: Context Gathering
50
51	```
52	Any related files, services, or issues I should reference?
53	(Or say "explore codebase" and I'll investigate)
54	```
55
56	### Step 5: Generate Issue
57
58	Based on inputs, generate the full issue using the appropriate template below.
59
60	---
61
62	## Issue Templates
63
64	### Feature Template
65
66	````markdown
67	## Summary
68
69	[1-2 sentence description]
70
71	Complexity: [simple\|medium\|complex]
72	Estimated Effort: [X days]
73
74	---
75
76	## Problem
77
78	[What problem does this solve? Why is it needed?]
79
80	### Evidence
81
82	[Logs, metrics, user reports, or reasoning]
83
84	### Scope
85
86	- IN SCOPE: [what's included]
87	- OUT OF SCOPE: [what's explicitly NOT included]
88
89	---
90
91	## Architecture Decision
92
93	Decision: [What approach will be taken]
94	Rationale: [Why this approach, why NOT alternatives]
95
96	---
97
98	## Technical Specification
99
100	### Types/Interfaces
101
102	```typescript
103	// Key type definitions
104	```
105	````
106
107	### Zod Schemas (if applicable)
108
109	```typescript
110	// Validation schemas
111	```
112
113	### API Endpoints (if applicable)
114
115	\| Method \| Path \| Description \|
116	\| ------ \| ---- \| ----------- \|
117
118	### Database Changes (if applicable)
119
120	[Schema changes, migrations needed]
121
122	---
123
124	## TDD Implementation Plan
125
126	### Cycle 1: [Happy Path]
127
128	```typescript
129	it("should [expected behavior]", async () => {
130	// Test code
131	});
132	```
133
134	### Cycle 2: [Error Handling]
135
136	```typescript
137	it("should handle [error case]", async () => {
138	// Test code
139	});
140	```
141
142	### Cycle 3: [Edge Cases]
143
144	### Cycle 4: [Integration]
145
146	---
147
148	## Error Handling
149
150	\| Scenario \| Behavior \| Logging \|
151	\| -------- \| -------- \| ------- \|
152
153	---
154
155	## Implementation Phases
156
157	### Phase 1: [Core] (High Priority)
158
159	- [ ] Task 1
160	- [ ] Task 2
161
162	### Phase 2: [Enhancement] (Medium Priority)
163
164	- [ ] Task 3
165
166	---
167
168	## Files to Create/Modify
169
170	- NEW: `path/to/new/file.ts`
171	- `path/to/existing/file.ts` - [what changes]
172
173	---
174
175	## Acceptance Criteria
176
177	- [ ] All TDD cycles implemented with passing tests
178	- [ ] Zero TypeScript errors (`pnpm typecheck`)
179	- [ ] Zero lint warnings (`pnpm lint`)
180	- [ ] All tests pass (`pnpm test --run`)
181	- [ ] JSDoc documentation added to all new/modified services
182	- [ ] `docs/SERVICE_INVENTORY.md` updated (if new/modified service)
183	- [ ] Mock factories added/updated (if new service)
184	- [ ] PR created and all CI checks pass
185	- [ ] ALL code review comments addressed (see Agent Instructions)
186	- [ ] All review threads resolved
187	- [ ] PR approved and merged
188
189	---
190
191	## Agent Instructions
192
193	CRITICAL: Follow this protocol when implementing this issue. A PR is NOT complete until ALL steps are done.
194
195	### Phase 0: Research (BEFORE writing any code)
196
197	Read these files first to avoid reinventing the wheel:
198
199	1. Service Inventory - Check for existing services that might already do what you need:
200
201	```bash
202	# Read the service inventory
203	cat docs/SERVICE_INVENTORY.md
204	# Or search for specific functionality
205	grep -i "embedding\\|search\\|cache" docs/SERVICE_INVENTORY.md
206	```
207
208	2. Mock Factories - Review existing mocks to reuse patterns:
209
210	```bash
211	ls src/test-utils/factories/
212	```
213
214	3. Similar Services - Find services with similar patterns:
215	```bash
216	# Find orchestrator patterns
217	ls src/lib/services/-orchestrator.ts
218	# Find persistence patterns
219	ls src/lib/services/-persistence.ts
220	```
221
222	Why this matters: Reusing existing services and patterns saves time, maintains consistency, and prevents duplicate code.
223
224	### Phase A: Implementation
225
226	1. Create feature branch from main: `git checkout -b feat/[short-name]`
227	2. Follow TDD cycles exactly as specified above
228	3. Add JSDoc documentation to all new/modified services
229	4. Run local validation: `pnpm lint && pnpm typecheck && pnpm test --run`
230	5. Update service inventory (if new service)
231	6. Create PR with comprehensive description using `/create-pr`
232
233	### Phase B: C

People who liked this also viewed

6 picks

Type