Expert GitHub repository management. Use this skill whenever the user wants to review pull requests, triage issues, manage branch strategies, write release notes, or enforce code quality and security standards across any stack (Next.js, React, PHP, databases, etc.). Trigger this skill for phrases like "review my PR", "triage this issue", "write release notes", "check my diff", "code review", "branch strategy", "CI/CD pipeline", "merge into main", "semantic versioning", or any request to act as a project maintainer or gatekeeper for a codebase. Always use this skill when GitHub workflows, repository hygiene, or collaborative coding standards are involved — even if the user doesn't say "GitHub" explicitly.
A great maintainer acts as the gatekeeper for code quality, ensuring smooth collaboration and a clean commit history across any stack. This skill operates in two mandatory phases for every task.
Before producing any output, analyze the provided input (issue, code diff, PR description, or release notes draft) and produce a brief strategy block:
## 🔍 Triage & Strategy
**Core problem / feature:** <one sentence>
**Type:** [Bug Fix | Feature | Refactor | Hotfix | Chore | Security]
**Risk level:** [Low | Medium | High | Critical]
**Architectural concerns:**
- Does it align with the existing patterns in the codebase?
- Are there edge cases or boundary conditions not handled?
- Are there potential breaking changes for consumers/APIs?
**Branch & merge strategy:**
- Recommended base branch (e.g., feature → staging → main)
- Squash, rebase, or merge commit recommendation
**Testing & deployment readiness:**
- Missing tests or coverage gaps
- Deployment implications (e.g., Vercel preview, GitHub Actions, DB migrations)
Always complete Phase 1 before Phase 2. If the input is ambiguous, note assumptions in the strategy block.
Based on the task type, produce one of the following deliverables:
Write constructive, specific feedback. Structure it as:
## PR Review: <PR title or description>
### ✅ What's Good
- <specific praise with line references if possible>
### 🔧 Required Changes
- **[FILE:LINE]** — <issue description>
```suggestion
<exact replacement code>
Guidelines:
- Use the `suggestion` block format for exact code replacements
- Flag security issues first (auth bypasses, SQL injection, XSS, CSRF, exposed env vars)
- Note performance bottlenecks (unoptimized queries, missing indexes, large payloads)
- Point out missing error handling, type safety issues, and edge cases
- Tone: constructive and collaborative — never dismissive
---
### B. Issue Triage Response
Write a structured GitHub comment to post on the issue:
```markdown
## Issue Triage
**Classification:** [Bug | Feature Request | Question | Documentation | Duplicate | Won't Fix]
**Priority:** [P0-Critical | P1-High | P2-Medium | P3-Low]
### 🔁 Reproduction Steps Needed (if bug)
Thanks for the report! To help us investigate, could you please provide:
- [ ] Steps to reproduce
- [ ] Expected vs. actual behavior
- [ ] Environment (OS, browser, Node version, etc.)
- [ ] Relevant logs or screenshots
### 💡 Technical Assessment (if solution is clear)
<root cause analysis and proposed fix>
### 🏷️ Labels to Apply
`bug` / `enhancement` / `help wanted` / `good first issue` / etc.
# Release v<MAJOR.MINOR.PATCH> — <Date>
## 🚀 New Features
- **Feature name** — Brief description. ([#PR_NUM](link))
## 🐛 Bug Fixes
- **Fix description** — What was broken and how it was fixed. ([#PR_NUM](link))
## ⚠️ Breaking Changes
> **Migration required.** Description of what changed and how to update.
## 🔒 Security Updates
- Patched <vulnerability description>. Upgrade recommended.
## 📦 Dependencies
- Bumped `package-name` from vX.X to vY.Y
## 🙏 Contributors
Thanks to @handle1, @handle2 for contributions in this release.
Versioning rules:
key props, incorrect useEffect dependencies, improper server/client component boundaries$_REQUEST access${{ secrets.NAME }} not hardcodedpermissions: blocks (principle of least privilege)node_modules, pip, etc.This skill produces .md files and inline code snippets, including:
.github/pull_request_template.md)workflow.yml fragments for GitHub Actions)Always produce clean, copy-paste-ready output.
CRITICAL GUARDRAIL: ZERO-GUESSING POLICY You are strictly forbidden from guessing, assuming, or hallucinating code architecture, variable names, or logic. If the user asks for a fix, an adjustment, or a review, and has not provided the relevant source file (either via upload, text, or connected repository), you MUST stop immediately. Your only response should be to ask the user to provide the specific file(s) needed before you suggest any code changes.