You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Generate and create pull request descriptions automatically using GitHub CLI. Use when the user asks to create a PR, generate a PR description, make a pull request, or submit changes for review. Analyzes git diff and commit history to create concise, meaningful PR descriptions that explain what changedand why.
3
+
description: Generate and create pull request descriptions automatically using GitHub CLI. Use when the user asks to create a PR, generate a PR description, make a pull request, or submit changes for review. Analyzes git diff and commit history to create comprehensive, meaningful PR descriptions that explain what changed, why it matters, and how to test it.
4
4
---
5
5
6
6
# Create PR Description
7
7
8
-
Generate concise pull request descriptions and create PRs using GitHub CLI.
8
+
Generate comprehensive pull request descriptions and create PRs using GitHub CLI.
9
9
10
10
## Workflow
11
11
@@ -49,6 +49,9 @@ Classify the PR into one of these categories:
49
49
-**feature**: New functionality, capabilities, or enhancements
- Commit messages (keywords like "fix", "add", "optimize", "refactor")
@@ -57,59 +60,235 @@ Base this on:
57
60
58
61
### 4. Generate Description
59
62
60
-
Create a concise description with this structure:
63
+
Create a comprehensive description with this structure:
61
64
62
65
```markdown
63
-
## [Change Type]: [One-line summary]
66
+
## Summary
67
+
[One sentence explaining what this PR does and why it matters]
64
68
65
-
**Before**: [What was happening before - the problem, limitation, or state]
69
+
## Context
70
+
[Background information, related issues, previous work, or the problem being solved]
66
71
67
-
**After**: [What changed meaningfully - the solution, new capability, or improvement]
72
+
## Changes
73
+
[High-level description of what changed]
68
74
69
-
### Changes
70
-
-[High-level change 1]
71
-
-[High-level change 2]
72
-
-[High-level change 3]
75
+
### Key Implementation Details
76
+
[Technical details that help reviewers understand the approach, especially for complex changes]
77
+
78
+
## Use Cases
79
+
[Concrete examples of how this will be used - helps reviewers understand practical value]
80
+
81
+
## Testing
82
+
[How to test the changes - step-by-step instructions]
83
+
84
+
## Links
85
+
- Related issues: #123, #456
86
+
- Documentation: URL (if applicable)
87
+
- Original implementation: URL (if applicable)
73
88
```
74
89
75
-
**Guidelines**:
76
-
- Keep it concise - focus on high-level changes, not implementation details
77
-
- "Before" should explain the context or problem
78
-
- "After" should explain the meaningful impact
79
-
- Changes should be 3-5 bullet points maximum
80
-
- Use clear, direct language
81
-
- Don't include:
82
-
- File-by-file breakdowns
83
-
- Low-level implementation details
84
-
- Boilerplate statements
85
-
- Testing instructions (assumed)
90
+
### Description Guidelines
86
91
87
-
**Examples**:
92
+
**Essential Elements:**
93
+
-**Summary**: One clear sentence explaining the change and its value
94
+
-**Context**: Why this change was needed, what problem it solves
95
+
-**Changes**: What was actually changed at a high level
96
+
-**Testing**: How reviewers can verify the changes
88
97
89
-
```markdown
90
-
## Feature: Add semantic code search
98
+
**Optional but Recommended:**
99
+
-**Implementation Details**: For complex changes, explain the technical approach
100
+
-**Use Cases**: Concrete examples of how the feature will be used
101
+
-**Links**: Related issues, documentation, papers, or original implementations
102
+
-**Known Issues**: Any limitations or known problems
91
103
92
-
**Before**: No way to search codebase by concepts or behavior, only exact string matching.
104
+
**What to Avoid:**
105
+
- Empty descriptions or just issue links
106
+
- Placeholder text like "Fixes #(issue)"
107
+
- File-by-file breakdowns (unless necessary)
108
+
- Low-level implementation details (keep it high-level)
109
+
- Boilerplate statements
110
+
- Personal checklists as the main description
111
+
112
+
### Description Examples
113
+
114
+
**Example 1: Feature Addition**
115
+
116
+
```markdown
117
+
## Summary
118
+
Add semantic code search to enable searching codebase by concepts and behavior rather than exact string matching.
93
119
94
-
**After**: Users can now search using natural language queries like "authentication flow" or "retry logic" to find relevant code across the repository.
120
+
## Context
121
+
Currently, users can only search using exact string matching, which makes it difficult to find code based on functionality or behavior. This has been a recurring request in issues #123 and #456.
95
122
96
-
###Changes
97
-
- Implemented semantic search using embeddings
123
+
## Changes
124
+
- Implemented semantic search using vector embeddings
98
125
- Integrated with existing search interface
99
-
- Added support for multiple concurrent queries
126
+
- Added support for multiple concurrent queries with result aggregation
127
+
- Configurable search scope (entire codebase or specific directories)
128
+
129
+
### Key Implementation Details
130
+
Uses OpenAI embeddings for code representation and cosine similarity for matching. Index is built incrementally to support large codebases. Search results are reranked based on code context and usage patterns.
131
+
132
+
## Use Cases
133
+
- Find authentication flow without knowing exact function names
134
+
- Locate retry logic across the codebase
135
+
- Search for "database connection" patterns
136
+
137
+
## Testing
138
+
```bash
139
+
# Run the search service
140
+
npm run search:dev
141
+
142
+
# Test semantic queries
143
+
curl -X POST http://localhost:3000/search \
144
+
-H "Content-Type: application/json" \
145
+
-d '{"query": "user authentication"}'
146
+
```
147
+
148
+
## Links
149
+
- Related issues: #123, #456
150
+
- Documentation: /docs/semantic-search.md
100
151
```
101
152
153
+
**Example 2: Bug Fix**
154
+
102
155
```markdown
103
-
## Fix: Resolve database connection timeout
156
+
## Summary
157
+
Fix database connection timeout that caused service to hang indefinitely when database became unavailable.
158
+
159
+
## Context
160
+
Service would hang indefinitely when database became unavailable, requiring manual restart. This was reported in production incident #789 and affected multiple users.
- Improved error messages with specific failure reasons
166
+
- Added circuit breaker pattern to prevent cascading failures
167
+
168
+
### Key Implementation Details
169
+
Timeout is applied at the connection pool level. Backoff strategy: 1s, 2s, 4s, 8s, 16s. Circuit breaker opens after 5 consecutive failures and resets after 60 seconds.
170
+
171
+
## Testing
172
+
```bash
173
+
# Simulate database failure
174
+
docker-compose stop db
175
+
176
+
# Verify timeout and retry behavior
177
+
npm test -- tests/integration/connection-timeout.test.ts
178
+
179
+
# Verify circuit breaker activation
180
+
curl http://localhost:3000/health # Should return 503 after circuit opens
Optimize image processing pipeline to reduce memory usage by 60% and improve throughput by 2.5x.
193
+
194
+
## Context
195
+
Current image processing implementation loads entire images into memory, causing OOM errors with large files and limiting throughput. This was identified as a performance bottleneck in profiling session #123.
196
+
197
+
## Changes
198
+
- Implemented streaming image processing using chunked reading
199
+
- Added parallel processing for multiple images
200
+
- Optimized memory allocation with object pooling
201
+
- Added caching for frequently accessed image metadata
104
202
105
-
**Before**: Service would hang indefinitely when database became unavailable, requiring manual restart.
203
+
### Key Implementation Details
204
+
Uses Node.js streams for memory-efficient processing. Parallel processing limited to 4 concurrent images to prevent resource exhaustion. Object pool reduces GC pressure by reusing buffers.
106
205
107
-
**After**: Service now handles connection failures gracefully with automatic retry and timeout.
206
+
## Use Cases
207
+
- Process large images (>100MB) without OOM errors
208
+
- Batch process thousands of images efficiently
209
+
- Reduced memory footprint allows higher concurrent user load
Refactor authentication module to use clean architecture patterns, improving testability and reducing coupling.
233
+
234
+
## Context
235
+
Authentication module had tight coupling between business logic and infrastructure, making it difficult to test and modify. This was identified in technical debt review #234.
236
+
237
+
## Changes
238
+
- Separated business logic from infrastructure dependencies
239
+
- Introduced repository pattern for data access
240
+
- Added service layer for authentication operations
241
+
- Extracted interfaces for better mocking in tests
242
+
243
+
### Key Implementation Details
244
+
Business logic now depends on interfaces rather than concrete implementations. Infrastructure (database, cache) is injected as dependencies. All services are unit-testable without external dependencies.
245
+
246
+
## Use Cases
247
+
- Easier to add new authentication providers (OAuth, SAML)
248
+
- Simpler to mock for unit tests
249
+
- Clear separation of concerns improves maintainability
0 commit comments