github-workflow

SKILL.md

--- frontmatter

name: GitHub Workflow
description: GitHub workflow patterns for Orchestrator AI. Branch naming, PR process, code review, CI/CD. CRITICAL: Use conventional branch names (feature/, fix/, chore/). PRs require quality gates to pass. Use GitHub Actions for CI/CD.
allowed-tools: Read, Write, Edit, Bash, Grep, Glob

GitHub Workflow Skill

CRITICAL: Follow GitHub workflow patterns: conventional branch names, PR process, quality gates, code review.

When to Use This Skill

Use this skill when:

•Creating branches
•Opening pull requests
•Setting up CI/CD
•Reviewing code
•Managing GitHub workflows

Branch Naming Conventions

✅ CORRECT - Conventional Names

bash

feature/user-authentication
feature/add-api-endpoint
fix/login-bug
fix/memory-leak
chore/update-dependencies
chore/refactor-service
docs/update-readme
test/add-unit-tests

❌ WRONG - Non-Conventional Names

bash

❌ my-feature
❌ bugfix
❌ update
❌ new-stuff
❌ feature_branch (use hyphens, not underscores)

Branch Types

Type	Prefix	Example	Purpose
Feature	`feature/`	`feature/user-auth`	New features
Bug Fix	`fix/`	`fix/login-error`	Bug fixes
Chore	`chore/`	`chore/update-deps`	Maintenance tasks
Documentation	`docs/`	`docs/api-guide`	Documentation updates
Test	`test/`	`test/unit-tests`	Test additions
Refactor	`refactor/`	`refactor/service-layer`	Code refactoring

PR Process

Step 1: Create Branch

bash

# Create feature branch
git checkout -b feature/user-authentication

# Or fix branch
git checkout -b fix/login-bug

Step 2: Make Changes

bash

# Edit files
vim apps/api/src/auth/auth.service.ts

# Stage changes
git add .

# Commit with conventional commit message
git commit -m "feat(auth): add user authentication"

Step 3: Push Branch

bash

# Push branch to remote
git push origin feature/user-authentication

Step 4: Open PR

•Go to GitHub repository
•Click "New Pull Request"
•Select your branch
•
Fill PR description:
- •What changed
- •Why changed
- •How to test
- •Screenshots (if UI changes)

Step 5: Quality Gates

PR must pass:

• Code formatting (npm run format)
• Linting (npm run lint)
• Tests (npm test)
• Build (npm run build)

Step 6: Code Review

•Request review from team members
•Address review comments
•Update PR as needed

Step 7: Merge

Once approved and quality gates pass:

•Merge PR (squash and merge recommended)
•Delete branch after merge

PR Description Template

markdown

## Description
Brief description of changes

## Type of Change
- [ ] Feature
- [ ] Bug Fix
- [ ] Chore
- [ ] Documentation
- [ ] Refactor

## Changes Made
- Change 1
- Change 2
- Change 3

## Testing
How to test these changes:
1. Step 1
2. Step 2
3. Step 3

## Screenshots (if applicable)
[Add screenshots for UI changes]

## Checklist
- [ ] Code follows project conventions
- [ ] Self-review completed
- [ ] Comments added for complex code
- [ ] Documentation updated
- [ ] No new warnings generated
- [ ] Tests added/updated
- [ ] All tests pass locally

CI/CD Workflow

GitHub Actions Example

yaml

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run format -- --check
      - run: npm run lint
      - run: npm test
      - run: npm run build

Code Review Guidelines

What to Review

• Code follows project conventions
• No hardcoded values (use env vars)
• Error handling implemented
• Tests added/updated
• Documentation updated
• No security issues
• Performance considerations

Review Comments

markdown

# Good review comment
```typescript
// Consider using environment variable instead of hardcoded value
const apiUrl = process.env.API_URL || 'http://localhost:7100';

markdown

# Another good review comment
```typescript
// Should we add error handling here?
const result = await service.call();

code


## Common Workflow Patterns

### Pattern 1: Feature Development

```bash
# 1. Create feature branch
git checkout -b feature/new-feature

# 2. Make changes and commit
git add .
git commit -m "feat(module): add new feature"

# 3. Push and open PR
git push origin feature/new-feature
# Open PR on GitHub

# 4. Address review comments
git add .
git commit -m "fix(module): address review comments"
git push

# 5. Merge after approval

Pattern 2: Hotfix

bash

# 1. Create fix branch from main
git checkout main
git pull
git checkout -b fix/critical-bug

# 2. Fix and commit
git add .
git commit -m "fix(module): fix critical bug"

# 3. Push and open PR
git push origin fix/critical-bug
# Open PR, request urgent review

# 4. Merge immediately after approval

Branch Protection Rules

Recommended branch protection for main:

•Require pull request reviews (at least 1)
•
Require status checks to pass
- •Format check
- •Lint check
- •Test check
- •Build check
•Require branches to be up to date
•Do not allow force pushes
•Do not allow deletions

Checklist for GitHub Workflow

When working with GitHub:

• Branch name follows convention (feature/, fix/, etc.)
• Commits use conventional commit format
• PR description is complete
• Quality gates pass before opening PR
• Code review requested
• Review comments addressed
• Branch deleted after merge

GitHub Workflow Skill

When to Use This Skill

Branch Naming Conventions

✅ CORRECT - Conventional Names

❌ WRONG - Non-Conventional Names

Branch Types

PR Process

Step 1: Create Branch

Step 2: Make Changes

Step 3: Push Branch

Step 4: Open PR

Step 5: Quality Gates

Step 6: Code Review

Step 7: Merge

PR Description Template

CI/CD Workflow

GitHub Actions Example

Code Review Guidelines

What to Review

Review Comments

Pattern 2: Hotfix

Branch Protection Rules

Checklist for GitHub Workflow

Related Documentation