Update Pr Desc Command

platform-dev-team-common:update-pr-desc Command Workflow

Codex Adaptation

• Treat the user request or explicitly supplied text as the command arguments.
• Use the available Codex file, search, terminal, and clarification capabilities that match the workflow.
• Do not depend on Claude-only slash command variables or tool names.

Update PR Description Command

You will help the user update a PR description following a comprehensive template with mandatory Mermaid chart visualization. The command automatically detects the project type and adapts content, examples, and terminology accordingly.

Available Options

• --pr <number>: Specify PR number (optional - uses current branch if not provided)
• --lang <language>: Description language (korean/english, default: korean)
• --include-load-test: Include load test results in performance section

Examples

• /update-pr-desc --pr 123 --lang ko: Update PR #123 with Korean description
• /update-pr-desc --lang eng: Update current branch PR with English description
• /update-pr-desc --pr 123 --lang ko --include-load-test: Update PR #123 with Korean description and load test results
• /update-pr-desc: Update current branch PR with Korean description (default)

Template Structure

The PR description MUST follow .github/pull_request_template.md structure with these sections:

Required Sections (필수)

1. PR 타입 (PR Type) 🏷️
2. 변경 사항 개요 (Change Overview) 🛠
3. 변경 사항 시각화 (Change Visualization) 📊 [MANDATORY MERMAID CHART]
4. 관련 이슈 (Related Issues) 📝
5. 테스트 (Tests) ✅
6. Breaking Changes ⚠️

Optional Sections (선택)

Only include if relevant:

7. API 변경 사항 (API Changes) 🔌
8. 성능 영향 (Performance Impact) ⚡
9. 배포 시 주의사항 (Deployment Notes) 🚀
10. 리뷰어 체크리스트 (Reviewer Checklist) 👀
11. 기타 참고사항 (Additional Notes) 💡

Implementation Steps

Step 1: Parse Arguments and Detect PR

1. Extract options from command arguments
2. If no PR number provided, detect from current branch using git
3. Use GitHub MCP get_pull_request to fetch PR metadata

Step 1.5: Detect Project Type

Analyze repository files to determine project type and adapt all subsequent content accordingly.

Backend Projects:

• Django: manage.py, settings.py, requirements.txt with Django
• FastAPI: main.py, requirements.txt with fastapi
• Express: package.json with express, app.js or server.js
• Spring Boot: pom.xml or build.gradle, Application.java
• Flask: app.py, requirements.txt with flask
• NestJS: nest-cli.json, package.json with @nestjs

Frontend Projects:

• React: package.json with react, src/ with .jsx or .tsx
• Vue: package.json with vue, vue.config.js
• Angular: angular.json, package.json with @angular
• Next.js: next.config.js, pages/ directory
• Svelte: svelte.config.js, .svelte files

Full-Stack Projects:

• Detect both frontend and backend indicators
• Monorepo structure with apps/ or packages/

Infrastructure/DevOps:

• Terraform: .tf files
• Kubernetes: .yaml files with kind: fields
• Docker: Dockerfile, docker-compose.yml
• Ansible: playbook.yml, ansible.cfg

Library/Package:

• Python: setup.py, pyproject.toml without web framework
• JavaScript: package.json with "main" field, no framework
• Rust: Cargo.toml, src/lib.rs
• Go: go.mod, Go package structure

Detection Method: Use Glob and Read tools to scan repository root and key directories. Store detected project type for use in all subsequent steps.

Step 2: Analyze Changes

Use GitHub MCP tools to gather comprehensive change information:

// Get PR metadata
const pr = await get_pull_request(pull_number)

// Get all commits
const commits = await list_commits(pull_number)

// Get changed files
const files = await list_pull_request_files(pull_number)

// Read key files to understand changes
for (const file of files) {
    const content = await get_file_contents(file.filename)
    // Analyze content
}

Identify based on detected project type:

For Backend Projects:

• API endpoint changes: New/modified routes, controllers, handlers, ViewSets, APIView classes
• Data model changes: ORM models, schemas, entities, database models
• Database migrations: Schema changes, migration files, Alembic/Sequelize/TypeORM migrations
• Authentication/authorization: Auth middleware, permissions, guards, decorators
• Background jobs: Celery tasks, Bull queues, async workers, scheduled jobs
• Service layer: Business logic implementations, service classes
• Middleware/interceptors: Request/response processing, custom middleware
• Serialization: Serializers, DTOs, validation schemas, Pydantic models

For Frontend Projects:

• Component changes: New/modified React/Vue/Angular components
• State management: Redux/Vuex/NgRx stores, actions, reducers, state updates
• Routing changes: Route definitions, navigation, guards
• API integration: API client changes, HTTP services, data fetching hooks
• UI/styling updates: CSS modules, styled-components, Tailwind classes, theme changes
• Build configuration: Webpack/Vite config, build scripts, bundling changes
• Hooks/composables: Custom React hooks, Vue composables, Angular services

For Infrastructure Projects:

• Resource definitions: Terraform resources, Kubernetes manifests, CloudFormation templates
• Configuration changes: ConfigMaps, Secrets, environment configs
• Deployment scripts: CI/CD pipeline changes, deployment workflows
• Container changes: Dockerfile updates, docker-compose modifications
• Orchestration: Kubernetes deployments, services, ingress, Helm charts

For All Projects:

• Test files: Unit tests, integration tests, E2E tests, test coverage changes
• Documentation: README updates, API docs, inline comments, documentation sites
• Configuration files: Settings, environment variables, feature flags
• Dependencies: Package additions/updates/removals, lock file changes

Step 3: Generate Mermaid Chart (MANDATORY)

CRITICAL: At least ONE Mermaid chart is REQUIRED.

Choose diagram type based on changes and detected project type:

For Backend Projects

API Endpoint Changes → API Flow Diagram

flowchart LR
    Client[Client] --> API[API Gateway]
    API --> Handler[Route Handler/Controller]
    Handler --> Service[Service Layer]
    Service --> DB[(Database)]

    style Client fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style API fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Handler fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Service fill:#8b5cf6,stroke:#7c3aed,color:#ffffff
    style DB fill:#10b981,stroke:#059669,color:#ffffff

Adapt terminology based on framework:

• Django: ViewSet, Serializer, Django Service
• FastAPI: Route Handler, Pydantic Schema, Service
• Express: Controller, Middleware, Service
• NestJS: Controller, Service, Repository

Model/Schema Changes → ER Diagram

erDiagram
    User ||--o{ Order : places
    User {
        int id PK
        string email UK
        string username
        datetime created_at
    }
    Order {
        int id PK
        int user_id FK
        string status
        decimal total
    }

Business Logic → Process Flowchart

flowchart TD
    Start[Receive Request] --> Validate{Validate Data}
    Validate -->|Invalid| Error[Return 400]
    Validate -->|Valid| Auth{Check Permission}
    Auth -->|Denied| Forbidden[Return 403]
    Auth -->|Allowed| Process[Execute Logic]
    Process --> Success[Return 200]

    style Start fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Validate fill:#f59e0b,stroke:#d97706,color:#ffffff
    style Auth fill:#f59e0b,stroke:#d97706,color:#ffffff
    style Process fill:#10b981,stroke:#059669,color:#ffffff
    style Success fill:#10b981,stroke:#059669,color:#ffffff
    style Error fill:#ef4444,stroke:#dc2626,color:#ffffff
    style Forbidden fill:#ef4444,stroke:#dc2626,color:#ffffff

For Frontend Projects

Component Hierarchy

flowchart TD
    App[App Component] --> Layout[Layout]
    Layout --> Header[Header]
    Layout --> Main[Main Content]
    Layout --> Footer[Footer]
    Main --> List[Item List]
    List --> Item[List Item]

    style App fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Layout fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Header fill:#06b6d4,stroke:#0891b2,color:#ffffff
    style Main fill:#06b6d4,stroke:#0891b2,color:#ffffff
    style Footer fill:#06b6d4,stroke:#0891b2,color:#ffffff
    style List fill:#8b5cf6,stroke:#7c3aed,color:#ffffff
    style Item fill:#8b5cf6,stroke:#7c3aed,color:#ffffff

State Management Flow

flowchart LR
    Action[User Action] --> Dispatch[Dispatch Action]
    Dispatch --> Reducer[Reducer/Store]
    Reducer --> State[Updated State]
    State --> Render[Re-render Component]

    style Action fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    style Dispatch fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Reducer fill:#8b5cf6,stroke:#7c3aed,color:#ffffff
    style State fill:#10b981,stroke:#059669,color:#ffffff
    style Render fill:#06b6d4,stroke:#0891b2,color:#ffffff

Adapt terminology based on framework:

• React: Component, useState/useReducer, Props/State
• Vue: Component, Vuex Store, Reactive Data
• Angular: Component, NgRx Store, Observable

For Infrastructure Projects

Resource Architecture

flowchart TD
    VPC[VPC] --> Subnet1[Public Subnet]
    VPC --> Subnet2[Private Subnet]
    Subnet1 --> ALB[Load Balancer]
    Subnet2 --> EC2[Application Servers]
    EC2 --> RDS[(Database)]

    style VPC fill:#3b82f6,stroke:#1e40af,color:#ffffff
    style Subnet1 fill:#06b6d4,stroke:#0891b2,color:#ffffff
    style Subnet2 fill:#06b6d4,stroke:#0891b2,color:#ffffff
    style ALB fill:#8b5cf6,stroke:#7c3aed,color:#ffffff
    style EC2 fill:#f59e0b,stroke:#d97706,color:#ffffff
    style RDS fill:#10b981,stroke:#059669,color:#ffffff

Adapt based on infrastructure type:

• Terraform: Resource dependencies and relationships
• Kubernetes: Pod, Service, Ingress relationships
• Docker: Container networking and volumes

General Guidelines

Color Requirements:

• Use standardized palette: Blue (#3b82f6), Green (#10b981), Yellow (#f59e0b), Red (#ef4444), Purple (#8b5cf6), Cyan (#06b6d4)
• Never use pure black (#000000) or white (#FFFFFF)
• Include style directives for ALL nodes
• Ensure visibility in light and dark themes

Step 4: Auto-Detect PR Type

Based on changed files and commits:

• Bug Fix 🐛: Bug fixes in code, "fix" in commits
• Feature ✨: New ViewSets/models/endpoints, "feat" in commits
• Refactoring ♻️: Code restructuring without behavior change
• Documentation 📝: Only docs/ or README changes
• Performance ⚡: Query optimizations, caching, "perf" in commits
• Test ✅: Primarily test file additions
• Configuration ⚙️: Settings, env vars, deployment configs
• Deployment 🚀: CI/CD, Docker, infrastructure
• Security 🔒: Auth, permissions, validation changes

Step 5: Generate Required Sections

1. PR 타입 (PR Type)

Korean:

## PR 타입 🏷️

- [ ] Bug Fix 🐛
- [x] Feature ✨
- [ ] Refactoring ♻️
- [ ] Documentation 📝
- [ ] Performance ⚡
- [ ] Test ✅
- [ ] Configuration ⚙️
- [ ] Deployment 🚀
- [ ] Security 🔒

English:

## PR Type 🏷️

- [ ] Bug Fix 🐛
- [x] Feature ✨
- [ ] Refactoring ♻️
- [ ] Documentation 📝
- [ ] Performance ⚡
- [ ] Test ✅
- [ ] Configuration ⚙️
- [ ] Deployment 🚀
- [ ] Security 🔒

2. 변경 사항 개요 (Change Overview)

Korean:

## 변경 사항 개요 🛠

### 주요 변경 내용
- [Summarize main changes in bullet points]
- [Focus on WHAT changed]

### 변경 이유
[Explain WHY this change was needed, the problem it solves]

English:

## Change Overview 🛠

### Main Changes
- [Summarize main changes in bullet points]
- [Focus on WHAT changed]

### Reason for Change
[Explain WHY this change was needed, the problem it solves]

3. 변경 사항 시각화 (Change Visualization) [MANDATORY]

## 변경 사항 시각화 📊

### [Diagram Title - e.g., API Request Flow / Database Schema / Process Flow]

[Insert Mermaid diagram here with proper styling]

### 설명 (Description)
[Brief explanation of the diagram, highlighting key points]

4. 관련 이슈 (Related Issues)

## 관련 이슈 📝

Closes SYN-1234
Fixes #456
Related to SYN-5678

Extract from:

• Branch name (e.g., feature/SYN-1234-description)
• Commit messages
• Existing PR title/description

5. 테스트 (Tests)

Based on detected test files and project type:

For Backend Projects:

Django:

## 테스트 ✅

### 테스트 항목
- [x] Django Unit Tests (`python manage.py test`)
- [x] API Integration Tests
- [x] Model Tests
- [x] Serializer Tests
- [x] Permission Tests
- [ ] Migration Tests
- [ ] Celery Task Tests

### 테스트 실행 방법
\`\`\`bash
# Run all tests
python manage.py test

# Run with coverage
coverage run --source='.' manage.py test
coverage report
\`\`\`

FastAPI:

## 테스트 ✅

### 테스트 항목
- [x] API Tests (`pytest`)
- [x] Schema Validation Tests
- [x] Database Tests
- [x] Authentication Tests
- [ ] Integration Tests

### 테스트 실행 방법
\`\`\`bash
# Run all tests
pytest

# Run with coverage
pytest --cov=app tests/
\`\`\`

Express/NestJS:

## 테스트 ✅

### 테스트 항목
- [x] Unit Tests (`npm test`)
- [x] API Integration Tests
- [x] Controller Tests
- [x] Service Tests
- [ ] E2E Tests

### 테스트 실행 방법
\`\`\`bash
# Run all tests
npm test

# Run with coverage
npm test -- --coverage
\`\`\`

For Frontend Projects:

React:

## 테스트 ✅

### 테스트 항목
- [x] Component Unit Tests (`npm test`)
- [x] Integration Tests
- [x] Snapshot Tests
- [x] Hook Tests
- [ ] E2E Tests (Cypress/Playwright)

### 테스트 실행 방법
\`\`\`bash
# Run all tests
npm test

# Run with coverage
npm test -- --coverage
\`\`\`

Vue/Angular:

## 테스트 ✅

### 테스트 항목
- [x] Component Tests
- [x] Unit Tests
- [x] Integration Tests
- [ ] E2E Tests

### 테스트 실행 방법
\`\`\`bash
# Vue
npm run test:unit

# Angular
ng test
\`\`\`

For All Projects:

### 테스트 커버리지
- **New Code Coverage**: 85% (target: 80%+)
- **Critical Path Coverage**: 100%

### 수동 테스트 시나리오
1. [Describe manual test scenario 1]
2. [Describe manual test scenario 2]

6. Breaking Changes

## Breaking Changes ⚠️

- [ ] No breaking changes
- [x] Contains breaking changes

### Breaking Change Details (if applicable)
- **Changed**: API endpoint `/api/v1/users/` now requires authentication
- **Migration Required**: Yes, run `python manage.py migrate`
- **Backward Compatibility**: Clients must update to include authentication headers
- **Rollback Plan**: Revert migration 0023, deploy previous version

Step 6: Generate Optional Sections (Only if Applicable)

API 변경 사항 (API Changes)

If API endpoints modified:

## API 변경 사항 🔌

| Method | Endpoint | Description | Change Type |
|--------|----------|-------------|-------------|
| POST | `/api/v1/auth/login/` | User login endpoint | New |
| PATCH | `/api/v1/users/{id}/` | Update user profile | Modified |
| DELETE | `/api/v1/posts/{id}/` | Delete post | Removed |

### Request/Response Examples

<details>
<summary>POST /api/v1/auth/login/</summary>

**Request**:
\`\`\`json
{
  "email": "user@example.com",
  "password": "securepassword"
}
\`\`\`

**Response** (200 OK):
\`\`\`json
{
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "user": {
    "id": 1,
    "email": "user@example.com",
    "username": "johndoe"
  }
}
\`\`\`

**Error Response** (401 Unauthorized):
\`\`\`json
{
  "error": "Invalid credentials"
}
\`\`\`
</details>

### OpenAPI Schema Update
- [x] Updated OpenAPI/Swagger documentation
- [x] Generated new API client
- [ ] Updated API versioning

성능 영향 (Performance Impact)

If performance-related changes, adapt based on project type:

For Backend Projects:

## 성능 영향 ⚡

### Database Performance
- **Query Optimization**: Reduced N+1 queries (Django: `select_related()`, TypeORM: `relations`, Sequelize: `include`)
- **Indexing**: Added database index on frequently queried fields
- **Query Count**: Reduced from 15 to 3 queries per request
- **Connection Pooling**: Optimized database connection settings

### API Response Performance
- **Before**: Avg 450ms, P95 800ms, P99 1200ms
- **After**: Avg 180ms, P95 250ms, P99 350ms
- **Improvement**: 60% faster average response time

### Load Test Results (if --include-load-test flag)
\`\`\`
Concurrent Users: 100
Duration: 5 minutes
Total Requests: 15,000
Success Rate: 99.8%
Avg Response Time: 180ms
P95: 250ms
P99: 350ms
Error Rate: 0.2%
\`\`\`

### Resource Usage
- **Memory**: Reduced by 15% (150MB → 127MB)
- **CPU**: Increased by 5% due to caching overhead
- **Cache Hit Rate**: 85% (Redis/Memcached)

For Frontend Projects:

## 성능 영향 ⚡

### Bundle Size
- **Before**: 2.5MB (gzipped: 650KB)
- **After**: 1.8MB (gzipped: 480KB)
- **Improvement**: 28% smaller bundle size

### Rendering Performance
- **Code Splitting**: Implemented lazy loading for routes
- **Memoization**: Added React.memo/useMemo to expensive components
- **Virtual Scrolling**: Implemented for large lists

### Lighthouse Scores
- **Performance**: 75 → 92
- **First Contentful Paint**: 2.1s → 1.2s
- **Time to Interactive**: 4.5s → 2.8s

### Resource Usage
- **JavaScript Execution Time**: Reduced by 40%
- **Memory Usage**: Optimized component lifecycle

For Infrastructure Projects:

## 성능 영향 ⚡

### Resource Optimization
- **Instance Size**: Reduced from t3.large to t3.medium
- **Auto-scaling**: Configured based on CPU and memory metrics
- **Cost Impact**: 30% reduction in monthly infrastructure costs

### Availability Improvements
- **High Availability**: Multi-AZ deployment
- **Failover Time**: Reduced from 5 minutes to 30 seconds
- **Load Balancer**: Configured health checks

배포 시 주의사항 (Deployment Notes)

If deployment-critical changes, adapt based on project type:

For Backend Projects:

Django:

## 배포 시 주의사항 🚀

### Database Migrations
- **Migration Files**: `0024_add_user_email_index.py`
- **Rollback Plan**: `python manage.py migrate users 0023`
- **Estimated Time**: ~2 minutes on production DB
- **Downtime Required**: No (online migration)

### Environment Configuration
\`\`\`bash
# New environment variables required
JWT_SECRET_KEY=<generate-secure-key>
JWT_EXPIRATION_HOURS=24
\`\`\`

### Service Restart Sequence
1. Apply migrations: `python manage.py migrate`
2. Collect static files: `python manage.py collectstatic`
3. Restart Celery workers: `sudo systemctl restart celery`
4. Restart application: `sudo systemctl restart gunicorn`
5. Clear cache: `redis-cli FLUSHDB`

FastAPI:

## 배포 시 주의사항 🚀

### Database Migrations
- **Migration Tool**: Alembic
- **Command**: `alembic upgrade head`
- **Rollback**: `alembic downgrade -1`

### Environment Configuration
\`\`\`bash
# New environment variables required
DATABASE_URL=postgresql://user:pass@host/db
JWT_SECRET=<generate-secure-key>
\`\`\`

### Deployment Steps
1. Run migrations: `alembic upgrade head`
2. Restart application: `docker-compose restart app`
3. Verify health endpoint: `curl /health`

Express/NestJS:

## 배포 시 주의사항 🚀

### Database Migrations
- **Migration Tool**: Sequelize/TypeORM/Prisma
- **Command**: `npm run migrate`
- **Rollback**: `npm run migrate:undo`

### Environment Configuration
\`\`\`bash
# New environment variables required
DATABASE_URL=postgresql://user:pass@host/db
JWT_SECRET=<generate-secure-key>
NODE_ENV=production
\`\`\`

### Deployment Steps
1. Build application: `npm run build`
2. Run migrations: `npm run migrate`
3. Restart application: `pm2 restart app`

For Frontend Projects:

React/Vue/Angular:

## 배포 시 주의사항 🚀

### Build Configuration
- **Build Command**: `npm run build`
- **Build Output**: `build/` or `dist/` directory
- **Environment Variables**: Update `.env.production`

### Environment Configuration
\`\`\`bash
# New environment variables required
REACT_APP_API_URL=https://api.example.com
REACT_APP_FEATURE_FLAG=true
\`\`\`

### Deployment Steps
1. Build application: `npm run build`
2. Upload to CDN/hosting: `aws s3 sync build/ s3://bucket`
3. Invalidate cache: `aws cloudfront create-invalidation`
4. Verify deployment: Check app version

For Infrastructure Projects:

Terraform:

## 배포 시 주의사항 🚀

### Infrastructure Changes
- **Plan**: Review `terraform plan` output carefully
- **Apply**: Run `terraform apply` with approval
- **Rollback**: Use state backup or `terraform destroy` specific resources

### Deployment Steps
1. Review plan: `terraform plan`
2. Apply changes: `terraform apply`
3. Verify resources: Check AWS Console/kubectl

Kubernetes:

## 배포 시 주의사항 🚀

### Kubernetes Resources
- **Manifests**: Updated Deployment, Service, Ingress
- **Apply**: `kubectl apply -f manifests/`
- **Rollback**: `kubectl rollout undo deployment/app`

### Deployment Steps
1. Apply manifests: `kubectl apply -f manifests/`
2. Watch rollout: `kubectl rollout status deployment/app`
3. Verify pods: `kubectl get pods`

For All Projects:

### Deployment Order
1. Deploy to staging environment
2. Run smoke tests
3. Deploy to production
4. Monitor for 30 minutes
5. Rollback if issues detected

Step 7: Assemble Complete Description

Combine all sections in proper order:

1. PR Type
2. Change Overview
3. Change Visualization (with Mermaid chart)
4. Related Issues
5. Tests
6. Breaking Changes
7. API Changes (if applicable)
8. Performance Impact (if applicable)
9. Deployment Notes (if applicable)
10. Reviewer Checklist (if applicable)
11. Additional Notes (if applicable)

Step 8: Update PR Description

Use GitHub MCP update_pull_request:

update_pull_request(
    pull_number=<pr_number>,
    body=<generated_description>
)

Step 9: Confirm Success

Report to user:

• PR number and URL
• Summary of sections included
• Mermaid chart type(s) generated
• Language used

Error Handling

• No PR found: Notify user, suggest using --pr option
• MCP unavailable: Guide user to check GITHUB_TOKEN and .mcp.json
• Insufficient data: Create minimal description with available information
• Cannot determine chart type: Default to simple process flowchart

Language Support

Korean (default)

• Use Korean for section headers and descriptions
• Keep code examples, error messages, and technical terms in English
• Use Korean terminology: 변경 사항, 테스트, 배포, etc.

English

• Use English for all sections
• Maintain same structure and completeness

Dependencies

• GitHub MCP server configured in .mcp.json
• GITHUB_TOKEN with repo and pull_requests permissions
• Git repository with commits and changes to analyze
• Access to mermaid-expert skill for diagram generation