changelog-generator
---
name: changelog-generator
description: "Generate CHANGELOG entries in Keep a Changelog format from git commit history between two tags or refs."
license: MIT
---
## Instructions
When generating a changelog:
- Run `git log <previous-tag>...<current-tag> --oneline --no-merges` to get the commit list.
- If no tags are provided, use `git log $(git describe --tags --abbrev=0)...HEAD --oneline --no-merges`.
- Group commits into Keep a Changelog sections (omit empty sections):
- **Added** — new features (`feat`)
- **Changed** — changes to existing behavior (`refactor`, `perf`)
- **Deprecated** — soon-to-be removed features
- **Removed** — removed features
- **Fixed** — bug fixes (`fix`)
- **Security** — security fixes (`fix(security)`, `gosec` findings)
- Strip conventional commit prefixes from the human-readable entries.
- Use the release date from the tag (`git log -1 --format=%ai <tag>`) or today's date if unreleased.
- Flag any commits that look like breaking changes (contain `BREAKING CHANGE` or `!`) and add them prominently under **Changed**.
## Example
**Input commits:**
```
feat(auth): add JWT refresh token rotation
fix(api): return 404 instead of 500 for missing orders
perf(db): add index on orders.created_at
chore: update dependencies
```
**Output:**
```markdown
## [1.4.0] - 2026-03-04
### Added
- Auth: JWT refresh token rotation
### Changed
- DB: Add index on `orders.created_at` for improved query performance
### Fixed
- API: Return 404 instead of 500 for missing orders
```
debug-goroutine
---
name: debug-goroutine
description: "Diagnose goroutine leaks, deadlocks, and race conditions in Go programs from stack traces, pprof output, or code review."
license: MIT
---
## Instructions
When debugging goroutine issues:
- For a goroutine leak, check if the provided stack trace has goroutines stuck in:
- `chan receive` — waiting on a channel that is never sent to or closed.
- `select` — blocked on a case that can never be satisfied.
- `net/http` — persistent connections or request handlers that never return.
- Identify the goroutine's launch site (the line below `created by`) to find where it was started.
- For deadlocks (`all goroutines are asleep`), map out which goroutine holds which lock and which lock each is waiting for.
- For race conditions, check if `go test -race ./...` output is provided and identify the conflicting goroutines and memory addresses.
- Suggest fixes:
- Use `context.Context` with cancellation to terminate goroutines.
- Ensure channels are always closed by their sender, not their receiver.
- Use `sync.WaitGroup` to wait for goroutines before returning.
- Use `goleak` in tests to detect goroutine leaks automatically.
- If reviewing code (not a stack trace), flag goroutines launched without a cancellation or timeout mechanism.
## Example
**Input stack trace (goroutine leak):**
```
goroutine 42 [chan receive]:
main.worker(0xc000018180)
/app/worker.go:15 +0x45
created by main.startWorker
/app/main.go:30 +0x6a
```
**Diagnosis:**
- `worker` is blocked waiting on a channel at line 15.
- It was launched by `startWorker` at `main.go:30`.
- The channel was likely never closed when the parent context was cancelled.
**Suggested fix:**
```go
func worker(ctx context.Context, ch <-chan Job) {
for {
select {
case job, ok := <-ch:
if !ok {
return // channel closed, exit cleanly
}
process(job)
case <-ctx.Done():
return // context cancelled, exit cleanly
}
}
}
```
docker-review
---
name: docker-review
description: "Review Dockerfiles for security issues, layer efficiency, and production best practices."
license: MIT
---
## Instructions
When reviewing a Dockerfile:
- Check the base image:
- Must be pinned to a specific digest or version tag — never `latest`.
- Prefer minimal images (`alpine`, `distroless`, `scratch`) over full OS images for production.
- Check for non-root user: the final stage must have `USER <non-root>` before `CMD`/`ENTRYPOINT`.
- Check layer efficiency:
- `RUN apt-get install` should chain with `&&` and end with `rm -rf /var/lib/apt/lists/*`.
- `COPY` and `RUN` ordering should place least-frequently-changed layers first (e.g., copy `go.mod`/`go.sum` and run `go mod download` before copying source).
- Check multi-stage builds: production images should not contain build tools, source code, or test dependencies.
- Flag secrets in `ENV`, `ARG`, or `RUN` commands — use build secrets (`--mount=type=secret`) instead.
- Verify `HEALTHCHECK` is defined for long-running services.
- Check that `EXPOSE` matches the port the application actually listens on.
## Example
**Input:**
```dockerfile
FROM golang:latest
COPY . .
RUN go build -o app .
CMD ["./app"]
```
**Issues found:**
1. `golang:latest` — unpinned tag; use `golang:1.22-alpine` or pin to a digest.
2. No multi-stage build — final image contains the entire Go toolchain (~800MB).
3. No `USER` directive — container runs as root.
4. No `HEALTHCHECK`.
5. `COPY . .` before `go mod download` — invalidates module cache on every source change.
**Suggested fix:**
```dockerfile
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN go build -o app .
FROM alpine:3.19
RUN adduser -D appuser
USER appuser
COPY --from=builder /app/app /app
HEALTHCHECK CMD wget -qO- http://localhost:8080/health || exit 1
EXPOSE 8080
ENTRYPOINT ["/app"]
```
git-commit-message
---
name: git-commit-message
description: "Write a conventional commit message from staged changes or a provided diff."
license: MIT
---
## Instructions
When writing a commit message:
- Run `git diff --cached` to inspect staged changes (or use the provided diff).
- Follow the Conventional Commits spec: `<type>(<scope>): <subject>`
- Types: `feat`, `fix`, `refactor`, `perf`, `test`, `docs`, `chore`, `ci`, `build`
- Scope: the package, module, or area affected (e.g., `auth`, `api`, `db`)
- Subject: imperative mood, lowercase, no trailing period, max 72 chars
- Add a body paragraph if the change is non-obvious — explain *why*, not *what*.
- Add a `BREAKING CHANGE:` footer if the change breaks a public API or contract.
- Do not include file names in the subject — describe the behavior change.
- If the diff contains unrelated changes, flag this and suggest splitting into multiple commits.
## Example
**Input diff:** Adds retry logic to an HTTP client in `internal/client/http.go`.
**Output:**
```
feat(client): add exponential backoff retry to HTTP client
Transient network errors were causing immediate failures in production.
Retries with jitter reduce thundering herd on downstream services.
Max 3 retries with 100ms base delay.
```
**Example with breaking change:**
```
feat(auth): replace session tokens with JWTs
BREAKING CHANGE: Existing session tokens are invalidated. Clients must
re-authenticate to obtain a JWT. See migration guide in docs/auth.md.
```
golang-code-review---
name: golang-code-review
description: "Act as a strict reviewer for Golang repositories. Check for idiomatic Go usage, lint issues, vet warnings, security risks, and test coverage."
license: MIT
---
## Instructions
When reviewing Golang code:
- Run `golangci-lint run ./...` to detect style, naming, and staticcheck issues.
- Run `go vet ./...` to catch potential bugs.
- Run `gosec ./...` to identify security vulnerabilities.
- Run `go test ./...` to ensure tests pass.
- Highlight performance issues (e.g., string concatenation in loops, goroutine leaks).
- Suggest idiomatic Go improvements (e.g., use `strings.Builder` instead of `+` for concatenation).
- Flag SQL injection, command injection, and other injection risks when string formatting is used to build queries or commands.
- Check that all returned errors are handled — never silently discarded with `_`.
## Example
**Input (PR diff):**
```go
func buildQuery(user string) string {
return "SELECT * FROM users WHERE name = '" + user + "'"
}
```
**Issues found:**
1. **SQL injection** (`gosec` G201): User input is concatenated directly into the query string. An attacker can supply `' OR '1'='1` to bypass authentication.
2. **String concatenation**: Use `strings.Builder` or parameterized queries instead.
**Suggested fix:**
```go
func buildQuery(db *sql.DB, user string) (*sql.Rows, error) {
return db.Query("SELECT * FROM users WHERE name = ?", user)
}
```
openapi-review
---
name: openapi-review
description: "Review OpenAPI/Swagger specs for REST conventions, breaking changes, missing error codes, and schema completeness."
license: MIT
---
## Instructions
When reviewing an OpenAPI spec:
- Check every endpoint has: summary, operationId, at least one 2xx response, and a 4xx (400/404) response.
- Flag missing `500` responses on mutating endpoints (POST, PUT, PATCH, DELETE).
- Verify request bodies have fully defined schemas — no bare `{}` or `type: object` without properties.
- Check for breaking changes if a previous version is available:
- Removed or renamed endpoints
- Required fields added to request bodies
- Response field removals or type changes
- Enforce naming conventions:
- Paths: lowercase, hyphen-separated (`/user-profiles`, not `/userProfiles`)
- operationId: camelCase verb+noun (`listUsers`, `createOrder`)
- Schema names: PascalCase
- Flag any endpoint that accepts `application/json` but lacks a request body schema.
- Check pagination: list endpoints should have `limit`/`offset` or cursor parameters.
## Example
**Input:** An OpenAPI path definition missing error responses.
```yaml
/orders/{id}:
get:
summary: Get order by ID
responses:
'200':
description: Order found
```
**Issues found:**
1. Missing `404` response — required when a resource may not exist.
2. Missing `500` response.
3. No `operationId` defined.
4. `200` response has no schema defined.
**Suggested fix:**
```yaml
/orders/{id}:
get:
summary: Get order by ID
operationId: getOrderById
responses:
'200':
description: Order found
content:
application/json:
schema:
$ref: '#/components/schemas/Order'
'404':
description: Order not found
'500':
description: Internal server error
```
pr-description
---
name: pr-description
description: "Generate a structured pull request description from a git diff, including summary, what changed, and testing notes."
license: MIT
---
## Instructions
When generating a PR description:
- Run `git diff main...HEAD` (or the relevant base branch) to get the full diff.
- Run `git log main...HEAD --oneline` to get the commit list.
- Produce a description with these sections:
- **Summary**: One sentence explaining the purpose of the PR.
- **Changes**: Bullet list of what was added, modified, or removed — grouped by concern (not by file).
- **Testing**: How the change was tested or how a reviewer can verify it.
- **Notes** (optional): Breaking changes, migration steps, or follow-up items.
- Do not include file paths as the primary grouping — describe behavior and intent.
- Flag any diff sections that look risky or incomplete and suggest the author address them before merging.
## Example
**Input:** `git diff main...HEAD` showing a new `/health` endpoint added to a Go HTTP server.
**Output:**
```
## Summary
Add a `/health` endpoint for liveness probes in Kubernetes deployments.
## Changes
- Added `GET /health` handler returning 200 OK with JSON `{"status":"ok"}`
- Registered route in `server.go` router setup
- Added unit test covering healthy and degraded response paths
## Testing
Run `go test ./internal/handler/...` — all tests pass.
Manually: `curl http://localhost:8080/health` returns `{"status":"ok"}`.
## Notes
This endpoint is unauthenticated by design. If auth middleware is applied globally in future, ensure `/health` is excluded.
```
sql-migration-review
---
name: sql-migration-review
description: "Review SQL migration files for safety issues including missing rollbacks, locking risks, non-nullable columns, and destructive operations."
license: MIT
---
## Instructions
When reviewing SQL migration files:
- Check every `up` migration has a corresponding `down` (rollback) migration.
- Flag operations that take full table locks in PostgreSQL:
- `ADD COLUMN` with a non-nullable default on large tables (use `ADD COLUMN NULL` + `UPDATE` + `SET NOT NULL` in steps)
- `ALTER COLUMN TYPE` changes
- Adding a non-concurrent index (`CREATE INDEX` without `CONCURRENTLY`)
- Flag destructive operations that cannot be undone:
- `DROP TABLE`, `DROP COLUMN`, `TRUNCATE`
- Recommend these are split into a separate migration deployed after confirming no code references them.
- Check new columns:
- Non-nullable columns must have a `DEFAULT` or the migration will fail on non-empty tables.
- Warn if a `VARCHAR` length is set very low (< 50) for user-facing string fields.
- Check for missing indexes on new foreign keys.
- Flag any raw `UPDATE` statements without a `WHERE` clause.
## Example
**Input migration:**
```sql
ALTER TABLE users ADD COLUMN verified BOOLEAN NOT NULL;
```
**Issues found:**
1. **Table lock risk**: Adding a `NOT NULL` column without a default locks the entire `users` table during migration.
2. **Missing default**: Will fail immediately on a non-empty table in PostgreSQL.
**Suggested fix:**
```sql
-- Step 1: add nullable (no lock)
ALTER TABLE users ADD COLUMN verified BOOLEAN;
-- Step 2: backfill
UPDATE users SET verified = false WHERE verified IS NULL;
-- Step 3: enforce NOT NULL (fast metadata change after backfill)
ALTER TABLE users ALTER COLUMN verified SET NOT NULL;
ALTER TABLE users ALTER COLUMN verified SET DEFAULT false;
```
| 
發表於