kivo360/backend/omoi_os/sandbox_skills/pr-creator

PR Creator

Create well-structured pull requests that are easy to review.

PR Title Format

{type}({scope}): {description} [TKT-{num}]

| Type | Description | |------|-------------| | feat | New feature | | fix | Bug fix | | refactor | Code refactoring | | test | Test additions | | docs | Documentation | | chore | Maintenance | | perf | Performance |

Examples:

• feat(auth): implement OAuth2 login [TKT-123]
• fix(api): handle null response in user endpoint [TKT-456]
• refactor(db): optimize query performance [TKT-789]

PR Description Template

## Summary
{1-2 sentence high-level description of what this PR does}

## Changes
{Bullet list of specific changes}

- Add {component/feature} for {purpose}
- Update {file} to {change}
- Remove {deprecated thing}

## Implementation Details
{Technical details for reviewers}

### Key Decisions
- **{Decision 1}**: Chose {approach} because {reason}
- **{Decision 2}**: Used {pattern} for {benefit}

### Notable Files
- `path/to/main/file.py` - Core implementation
- `path/to/tests.py` - Test coverage

## Testing

### Automated Tests
- [ ] Unit tests added/updated
- [ ] Integration tests pass
- [ ] E2E tests pass (if applicable)

### Manual Testing
{Steps to manually verify}

1. {Step 1}
2. {Step 2}
3. Expected: {outcome}

## Checklist
- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Documentation updated
- [ ] No new warnings/errors
- [ ] Tests cover new functionality

## Related
- Closes TKT-{num}
- Relates to #{other-pr}
- Depends on #{blocking-pr}

## Screenshots
{For UI changes, add before/after screenshots}

| Before | After |
|--------|-------|
| {img}  | {img} |

Creating PR via CLI

# Using GitHub CLI (gh)
gh pr create \
  --title "feat(auth): implement OAuth2 login [TKT-123]" \
  --body "$(cat <<'EOF'
## Summary
Implements OAuth2 login flow with Google and GitHub providers.

## Changes
- Add OAuth2 provider configuration
- Implement callback handling
- Add session management for OAuth users

## Testing
- [ ] Unit tests for OAuth flow
- [ ] Manual testing with Google/GitHub

Closes TKT-123
EOF
)" \
  --base main \
  --label "feature" \
  --label "auth"

Labels to Apply

| Label | When to Use | |-------|-------------| | feature | New functionality | | bugfix | Bug fixes | | breaking | Breaking changes | | security | Security-related | | performance | Performance improvements | | documentation | Doc changes only | | needs-review | Ready for review | | work-in-progress | Not ready yet |

Size Guidelines

| Size | Lines Changed | Review Time | |------|---------------|-------------| | XS | < 50 | < 15 min | | S | 50-200 | 15-30 min | | M | 200-500 | 30-60 min | | L | 500-1000 | 1-2 hours | | XL | > 1000 | Consider splitting |

Best Practices

1. Keep PRs small - Easier to review, fewer conflicts
2. One concern per PR - Don't mix features with refactors
3. Include tests - Every feature/fix should have tests
4. Update docs - Keep documentation in sync
5. Add context - Help reviewers understand decisions
6. Link issues - Use "Closes #123" to auto-close
7. Request specific reviewers - Tag domain experts
8. Respond to feedback - Address all comments

Draft PRs

Use draft PRs for:

• Work in progress that needs early feedback
• Large changes that will take multiple commits
• Exploring approaches before finalizing

gh pr create --draft --title "WIP: feat(auth): OAuth2 exploration"

Merge Strategy

| Strategy | When to Use | |----------|-------------| | Squash | Default - clean history, one commit per PR | | Merge | When preserving commit history matters | | Rebase | When linear history is required |

# Squash merge (recommended)
gh pr merge --squash

# With custom commit message
gh pr merge --squash --subject "feat(auth): OAuth2 login"