Context
- Current git status: !
git status
- Current branch: !
git branch --show-current
- Unpushed commits: !
git log @{u}..HEAD --oneline 2>/dev/null || git log --oneline -5
- GitHub authentication: !
gh auth status
- Repository changes: !
git diff --stat HEAD~1..HEAD 2>/dev/null || echo "No recent changes"
Requirements
- Ensure the repository is clean, authenticated, and ready for PR submission.
- Complete lint, test, build, and security checks before creating the PR.
- Link related issues and apply accurate labels for traceability.
- Use atomic commits for logical units of work: Each commit should represent one complete, cohesive change.
- Title: entirely lowercase, <50 chars, imperative mood (e.g., "add", "fix", "update"), conventional commits format (feat:, fix:, docs:, refactor:, test:, chore:)
- Scope (optional): lowercase noun, 1-2 words. Must match existing scopes in git history.
- Body: blank line after title, ≤72 chars per line, must start with uppercase letter, standard capitalization and punctuation. Describe what changed and why, not how.
- Footer (optional): Must start with uppercase letter, standard capitalization. Reference issues/PRs (Closes #123, Fixes #456, Linked to PR #789). Use BREAKING CHANGE: prefix for breaking changes.
Examples
feat(auth): add google oauth login flow
- Introduce Google OAuth 2.0 for user sign-in
- Add backend callback endpoint `/auth/google/callback`
- Update login UI with Google button and loading state
Add a new authentication option improving cross-platform
sign-in.
Closes #42. Linked to #38 and PR #45
fix(api): handle null payload in session refresh
- Validate payload before accessing `user.id`
- Return proper 400 response instead of 500
- Add regression test for null input
Prevents session refresh crash when token expires.
Fixes #105
feat(auth): migrate to oauth 2.0
- Replace basic auth with OAuth 2.0 flow
- Update authentication middleware
- Add token refresh endpoint
BREAKING CHANGE: Authentication API now requires OAuth 2.0 tokens. Basic auth is no longer supported.
Closes #120. Linked to #115 and PR #122
Your Task
IMPORTANT: You MUST use the Task tool to complete ALL tasks.
- Validate repository readiness, analyse change scope, and detect any blockers.
- Run the necessary quality and security checks; resolve failures by collaborating with specialized agents when required.
- Assemble the pull request with the prescribed structure, link issues, apply labels, and report the final status to the team.
Workflow Steps
- Repository Validation - Check authentication and branch status
- Change Analysis - Analyze commits and file changes
- Quality Validation - Run project-specific quality checks
- Security Scanning - Check for sensitive data exposure
- Issue Discovery - Find and link related issues
- PR Creation - Generate and create pull request with proper metadata
Quality Validation Process
Node.js Projects:
- Run lint, test, build, and type-check commands
- Validate package.json changes
- Check for security vulnerabilities
Python Projects:
- Run ruff, black, pytest, and mypy
- Validate requirements and dependencies
- Check for security issues
Security Validation
- Scan for sensitive files (.env, .key, .pem)
- Check for hardcoded secrets, passwords, tokens
- Validate input sanitization in changed files
- Ensure no credentials in commit history
Pre-Creation Requirements
- Repository state validated and clean
- All quality checks passed (lint, test, build)
- Security scan completed without issues
- Related issues identified and linked
- Proper branch naming and commit messages following standards
Failure Resolution Process
When quality checks fail:
- Use TodoWrite to create specific task list for failures
- Use Task tool with specialized agents:
- @code-reviewer — logic correctness, tests, error handling.
- @security-reviewer — authentication, data protection, validation.
- Fix issues systematically with validation after each fix
- Mark tasks completed immediately after resolution
- Re-run quality checks until all pass
PR Structure Requirements
Title Guidelines:
- Maximum 70 characters
- Use imperative mood
- No emojis
- Clear and descriptive
Body Template:
## Summary
Brief description of changes and business impact
## Changes
- List of key modifications
- Technical details and rationale
## Related Issues
Fixes #123, Closes #456
## Testing
- [ ] Unit tests added/updated
- [ ] All tests pass
- [ ] Manual testing completed
- [ ] Edge cases covered
## Security & Quality
- [ ] No sensitive data exposed
- [ ] Input validation implemented
- [ ] Linting and type checking passed
- [ ] Build successful
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
Automated Labeling
testing - Test file modifications
documentation - Documentation updates
dependencies - Package file changes
security - Security-related modifications
Commit Message Validation
- Use atomic commits for logical units of work: Each commit should represent one complete, cohesive change.
- Title: entirely lowercase, <50 chars, imperative mood (e.g., "add", "fix", "update"), conventional commits format (feat:, fix:, docs:, refactor:, test:, chore:)
- Scope (optional): lowercase noun, 1-2 words. Must match existing scopes in git history.
- Body: blank line after title, ≤72 chars per line, must start with uppercase letter, standard capitalization and punctuation. Describe what changed and why, not how.
- Footer (optional): Must start with uppercase letter, standard capitalization. Reference issues/PRs (Closes #123, Fixes #456, Linked to PR #789). Use BREAKING CHANGE: prefix for breaking changes.
Examples
feat(auth): add google oauth login flow
- Introduce Google OAuth 2.0 for user sign-in
- Add backend callback endpoint `/auth/google/callback`
- Update login UI with Google button and loading state
Add a new authentication option improving cross-platform
sign-in.
Closes #42. Linked to #38 and PR #45
fix(api): handle null payload in session refresh
- Validate payload before accessing `user.id`
- Return proper 400 response instead of 500
- Add regression test for null input
Prevents session refresh crash when token expires.
Fixes #105
feat(auth): migrate to oauth 2.0
- Replace basic auth with OAuth 2.0 flow
- Update authentication middleware
- Add token refresh endpoint
BREAKING CHANGE: Authentication API now requires OAuth 2.0 tokens. Basic auth is no longer supported.
Closes #120. Linked to #115 and PR #122
- Review all commits in branch for compliance
- Handle non-standard commits by documenting in PR description or interactive rebase if safe
Best Practices
- Quality-first: All checks must pass before PR creation
- Security validation: Comprehensive scanning for vulnerabilities
- Issue linking: Connect PRs to related issues with auto-closing keywords
- Small, focused changes: Easier to review and merge
1---2name: create-pr-53description: Create comprehensive GitHub pull requests with quality validation4---5
6## Context
7
8- Current git status: !`git status`
9- Current branch: !`git branch --show-current`
10- Unpushed commits: !`git log @{u}..HEAD --oneline 2>/dev/null || git log --oneline -5`
11- GitHub authentication: !`gh auth status`
12- Repository changes: !`git diff --stat HEAD~1..HEAD 2>/dev/null || echo "No recent changes"`
13
14## Requirements
15
16- Ensure the repository is clean, authenticated, and ready for PR submission.
17- Complete lint, test, build, and security checks before creating the PR.
18- Link related issues and apply accurate labels for traceability.
19- **Use atomic commits for logical units of work**: Each commit should represent one complete, cohesive change.
20- Title: entirely lowercase, <50 chars, imperative mood (e.g., "add", "fix", "update"), conventional commits format (feat:, fix:, docs:, refactor:, test:, chore:)
21 - Scope (optional): lowercase noun, 1-2 words. Must match existing scopes in git history.
22- Body: blank line after title, ≤72 chars per line, must start with uppercase letter, standard capitalization and punctuation. Describe what changed and why, not how.
23- Footer (optional): Must start with uppercase letter, standard capitalization. Reference issues/PRs (Closes #123, Fixes #456, Linked to PR #789). Use BREAKING CHANGE: prefix for breaking changes.
24
25### Examples
26
27```
28feat(auth): add google oauth login flow
29
30- Introduce Google OAuth 2.0 for user sign-in
31- Add backend callback endpoint `/auth/google/callback`
32- Update login UI with Google button and loading state
33
34Add a new authentication option improving cross-platform
35sign-in.
36
37Closes #42. Linked to #38 and PR #45
38```
39
40```
41fix(api): handle null payload in session refresh
42
43- Validate payload before accessing `user.id`
44- Return proper 400 response instead of 500
45- Add regression test for null input
46
47Prevents session refresh crash when token expires.
48
49Fixes #105
50```
51
52```
53feat(auth): migrate to oauth 2.0
54
55- Replace basic auth with OAuth 2.0 flow
56- Update authentication middleware
57- Add token refresh endpoint
58
59BREAKING CHANGE: Authentication API now requires OAuth 2.0 tokens. Basic auth is no longer supported.
60
61Closes #120. Linked to #115 and PR #122
62```
63
64## Your Task
65
66**IMPORTANT: You MUST use the Task tool to complete ALL tasks.**
67
681. Validate repository readiness, analyse change scope, and detect any blockers.
692. Run the necessary quality and security checks; resolve failures by collaborating with specialized agents when required.
703. Assemble the pull request with the prescribed structure, link issues, apply labels, and report the final status to the team.
71
72### Workflow Steps
73
741. **Repository Validation** - Check authentication and branch status
752. **Change Analysis** - Analyze commits and file changes
763. **Quality Validation** - Run project-specific quality checks
774. **Security Scanning** - Check for sensitive data exposure
785. **Issue Discovery** - Find and link related issues
796. **PR Creation** - Generate and create pull request with proper metadata
80
81### Quality Validation Process
82
83**Node.js Projects:**
84
85- Run lint, test, build, and type-check commands
86- Validate package.json changes
87- Check for security vulnerabilities
88
89**Python Projects:**
90
91- Run ruff, black, pytest, and mypy
92- Validate requirements and dependencies
93- Check for security issues
94
95### Security Validation
96
97- Scan for sensitive files (.env, .key, .pem)
98- Check for hardcoded secrets, passwords, tokens
99- Validate input sanitization in changed files
100- Ensure no credentials in commit history
101
102### Pre-Creation Requirements
103
104- Repository state validated and clean
105- All quality checks passed (lint, test, build)
106- Security scan completed without issues
107- Related issues identified and linked
108- Proper branch naming and commit messages following standards
109
110### Failure Resolution Process
111
112When quality checks fail:
113
1141. Use TodoWrite to create specific task list for failures
1152. Use Task tool with specialized agents:
116 - **@code-reviewer** — logic correctness, tests, error handling.
117 - **@security-reviewer** — authentication, data protection, validation.
1183. Fix issues systematically with validation after each fix
1194. Mark tasks completed immediately after resolution
1205. Re-run quality checks until all pass
121
122### PR Structure Requirements
123
124**Title Guidelines:**
125
126- Maximum 70 characters
127- Use imperative mood
128- No emojis
129- Clear and descriptive
130
131**Body Template:**
132
133```markdown
134## Summary
135Brief description of changes and business impact
136
137## Changes
138- List of key modifications
139- Technical details and rationale
140
141## Related Issues
142Fixes #123, Closes #456
143
144## Testing
145- [ ] Unit tests added/updated
146- [ ] All tests pass
147- [ ] Manual testing completed
148- [ ] Edge cases covered
149
150## Security & Quality
151- [ ] No sensitive data exposed
152- [ ] Input validation implemented
153- [ ] Linting and type checking passed
154- [ ] Build successful
155
156## Type of Change
157- [ ] Bug fix
158- [ ] New feature
159- [ ] Breaking change
160- [ ] Documentation update
161```
162
163### Automated Labeling
164
165- `testing` - Test file modifications
166- `documentation` - Documentation updates
167- `dependencies` - Package file changes
168- `security` - Security-related modifications
169
170### Commit Message Validation
171
172- **Use atomic commits for logical units of work**: Each commit should represent one complete, cohesive change.
173- Title: entirely lowercase, <50 chars, imperative mood (e.g., "add", "fix", "update"), conventional commits format (feat:, fix:, docs:, refactor:, test:, chore:)
174 - Scope (optional): lowercase noun, 1-2 words. Must match existing scopes in git history.
175- Body: blank line after title, ≤72 chars per line, must start with uppercase letter, standard capitalization and punctuation. Describe what changed and why, not how.
176- Footer (optional): Must start with uppercase letter, standard capitalization. Reference issues/PRs (Closes #123, Fixes #456, Linked to PR #789). Use BREAKING CHANGE: prefix for breaking changes.
177
178### Examples
179
180```
181feat(auth): add google oauth login flow
182
183- Introduce Google OAuth 2.0 for user sign-in
184- Add backend callback endpoint `/auth/google/callback`
185- Update login UI with Google button and loading state
186
187Add a new authentication option improving cross-platform
188sign-in.
189
190Closes #42. Linked to #38 and PR #45
191```
192
193```
194fix(api): handle null payload in session refresh
195
196- Validate payload before accessing `user.id`
197- Return proper 400 response instead of 500
198- Add regression test for null input
199
200Prevents session refresh crash when token expires.
201
202Fixes #105
203```
204
205```
206feat(auth): migrate to oauth 2.0
207
208- Replace basic auth with OAuth 2.0 flow
209- Update authentication middleware
210- Add token refresh endpoint
211
212BREAKING CHANGE: Authentication API now requires OAuth 2.0 tokens. Basic auth is no longer supported.
213
214Closes #120. Linked to #115 and PR #122
215```
216
217- Review all commits in branch for compliance
218- Handle non-standard commits by documenting in PR description or interactive rebase if safe
219
220### Best Practices
221
222- **Quality-first**: All checks must pass before PR creation
223- **Security validation**: Comprehensive scanning for vulnerabilities
224- **Issue linking**: Connect PRs to related issues with auto-closing keywords
225- **Small, focused changes**: Easier to review and merge