AI Prompts Library

You are a senior engineer who writes clear, thorough pull request descriptions that make code review efficient and productive. Given a diff or description of changes, write a comprehensive PR description.

**Changes:** [DESCRIBE CHANGES or PASTE DIFF]
**Related Issue/Ticket:** [TICKET_NUMBER or DESCRIPTION]
**Repository:** [REPO_NAME]
**Type of Change:** [Feature / Bug Fix / Refactor / Hotfix / Dependency Update / Documentation]

**Generate a PR description with:**

1. **Title:** (Conventional format)
   - `feat:`, `fix:`, `refactor:`, `docs:`, `test:`, `chore:`
   - Clear, concise summary under 72 characters

2. **Summary:**
   - 2-3 sentences explaining WHAT changed and WHY
   - Link to issue/ticket
   - Business context for the change

3. **Changes Made:**
   - Bullet list of specific changes, grouped by file or component
   - For each change: what was modified and why
   - Highlight any architectural decisions made

4. **How to Test:**
   - Step-by-step manual testing instructions
   - Expected behavior for each test case
   - Edge cases to verify
   - Test data setup if needed

5. **Screenshots/Recordings:**
   - Description of visual changes (suggest what screenshots to add)
   - Before/after comparison points

6. **Checklist:**
   - [ ] Tests added/updated for these changes
   - [ ] Documentation updated if needed
   - [ ] No breaking changes (or breaking changes documented)
   - [ ] Database migrations are reversible
   - [ ] Feature flag added for gradual rollout
   - [ ] Accessibility checked
   - [ ] Performance impact assessed

7. **Reviewer Notes:**
   - Areas that need special attention during review
   - Questions for the reviewer
   - Known trade-offs or technical debt introduced
   - Deployment considerations

**Output**: Complete PR description in Markdown, ready to paste into GitHub/GitLab.

Generate comprehensive API documentation for [API NAME].

**API Details:**
- Base URL: [URL]
- Authentication: [TYPE]
- Version: [VERSION]

**For Each Endpoint:**

```yaml
/api/endpoint:
  method:
    summary: Brief description
    description: Detailed explanation
    parameters:
      - name: param
        in: query/path/header
        required: true/false
        schema:
          type: string/number/etc
        description: Parameter purpose
    requestBody:
      content:
        application/json:
          schema:
            type: object
            properties:
              field: type
    responses:
      '200':
        description: Success response
        content:
          application/json:
            example:
              {data}
      '400':
        description: Error response
```

**Include:**
- Authentication guide
- Rate limiting info
- Error codes
- Code examples (cURL, JavaScript, Python)
- Changelog
- Postman collection

Generate semantic commit messages following Conventional Commits standard.

**Changes Made:**
[DESCRIBE YOUR CHANGES]

**Generate commits in format:**

```
type(scope): subject

body (optional)

footer (optional)
```

**Types:**
- feat: New feature
- fix: Bug fix
- docs: Documentation
- style: Formatting, missing semi-colons, etc
- refactor: Code refactoring
- perf: Performance improvement
- test: Adding tests
- chore: Maintenance tasks

**Guidelines:**
- Subject: Imperative mood, lowercase, no period, max 50 chars
- Body: Explain what and why (not how), max 72 chars per line
- Footer: Breaking changes, issue references

**Examples:**
```
feat(auth): add OAuth2 Google login

Implements Google OAuth2 authentication flow with
proper token management and refresh logic.

Closes #123
```

Generate database migration script for [DATABASE: PostgreSQL/MySQL/MongoDB].

**Migration Type:**
- [ ] Create table
- [ ] Alter table
- [ ] Add column
- [ ] Drop column
- [ ] Add index
- [ ] Data migration

**Details:**
[DESCRIBE SCHEMA CHANGES]

**Generate:**

1. **Up Migration** (apply changes)
2. **Down Migration** (rollback)
3. **Data Migration** (if needed)
4. **Validation Queries**

**Requirements:**
- Idempotent (can run multiple times safely)
- Transaction-wrapped
- Rollback-safe
- Include comments
- Handle edge cases
- Test data examples
- Performance considerations for large tables

**Also provide:**
- Pre-migration checklist
- Post-migration validation
- Backup recommendations

Create and explain regular expression patterns.

**Task**: [DESCRIBE WHAT YOU WANT TO MATCH]

**Examples of valid inputs:**
- [EXAMPLE 1]
- [EXAMPLE 2]

**Examples of invalid inputs:**
- [EXAMPLE 1]
- [EXAMPLE 2]

**Generate:**

1. **Regex Pattern**
```
/pattern/flags
```

2. **Explanation** (step-by-step breakdown)
- `^` - Start of string
- `[a-z]` - Lowercase letter
- etc.

3. **Flags Explained**
- `g` - Global match
- `i` - Case insensitive
- `m` - Multiline

4. **Test Cases**
```
Should match:
✓ "example1"
✓ "example2"

Should not match:
✗ "invalid1"
✗ "invalid2"
```

5. **Code Examples**
- JavaScript
- Python
- PHP

6. **Performance Tips**
- Optimization suggestions
- Common pitfalls
- Alternative approaches

Build Chrome extension [NAME]:

**manifest.json** (v3)
**popup.html/js** (UI & logic)
**content.js** (page interaction)
**background.js** (service worker)
**styles.css**

Include:
- Complete working code
- Permissions setup
- Installation guide
- Testing steps
- Store submission guide
- Security best practices

Production-ready, documented.

Webhook endpoint for [SERVICE A → SERVICE B]:

**Endpoint** - POST handler
**Signature Verification** - HMAC validation, timestamp check
**Payload Processing** - Validation, transformation, error handling
**Idempotency** - Prevent duplicate processing
**Retry Logic** - Exponential backoff
**Monitoring** - Logging, alerts, metrics

Include: Full code, tests, deployment.

Optimize Dockerfile:

**Multi-stage Build** - Builder + production stages
**Layer Caching** - Dependencies first, code last
**Security** - Non-root user, minimal base image
**Size Reduction** - Alpine Linux, .dockerignore
**Performance** - Parallel builds, BuildKit

Include: Optimized Dockerfile, .dockerignore, docker-compose.yml, build commands, size comparison.

Design comprehensive API error response:

```json
{
  "error": {
    "code": "ERROR_CODE",
    "message": "Human-readable error message",
    "details": "Detailed explanation",
    "timestamp": "2025-10-02T02:00:00Z",
    "request_id": "uuid",
    "documentation_url": "https://docs.example.com/errors/ERROR_CODE",
    "field_errors": [
      {
        "field": "email",
        "message": "Invalid email format",
        "code": "INVALID_FORMAT"
      }
    ]
  }
}
```

**Error Categories**:
- 4xx Client Errors: Authentication, validation, not found
- 5xx Server Errors: Internal, service unavailable, timeout

**Best Practices**:
- Use consistent error codes
- Provide actionable messages
- Include request tracking
- Add documentation links
- Never expose sensitive data

Optimize [WEB APP/API/DATABASE] performance:

**Frontend Optimization**:
- [ ] Minify CSS/JS/HTML
- [ ] Compress images (WebP, lazy loading)
- [ ] Use CDN for static assets
- [ ] Implement code splitting
- [ ] Add browser caching headers
- [ ] Reduce HTTP requests
- [ ] Optimize fonts (font-display: swap)

**Backend Optimization**:
- [ ] Database query optimization
- [ ] Add database indexes
- [ ] Implement caching (Redis/Memcached)
- [ ] Use connection pooling
- [ ] Add rate limiting
- [ ] Optimize API responses (pagination, partial)
- [ ] Enable gzip compression

**Database Optimization**:
- [ ] Analyze slow queries (EXPLAIN)
- [ ] Add composite indexes
- [ ] Denormalize where beneficial
- [ ] Implement query caching
- [ ] Optimize table structure
- [ ] Regular VACUUM/ANALYZE

**Monitoring**:
- [ ] Set up APM (New Relic, DataDog)
- [ ] Track Core Web Vitals
- [ ] Monitor error rates
- [ ] Set performance budgets

Security audit following OWASP Top 10:

**1. Injection Flaws**
- [ ] Use parameterized queries
- [ ] Validate & sanitize all inputs
- [ ] Use ORM safely

**2. Broken Authentication**
- [ ] Implement MFA
- [ ] Use secure session management
- [ ] Hash passwords (bcrypt/Argon2)
- [ ] Implement rate limiting

**3. Sensitive Data Exposure**
- [ ] Encrypt data at rest & in transit (TLS 1.3)
- [ ] Don't log sensitive data
- [ ] Use secure key management

**4. XML External Entities (XXE)**
- [ ] Disable XML external entity processing
- [ ] Use secure XML parsers

**5. Broken Access Control**
- [ ] Verify permissions server-side
- [ ] Implement RBAC/ABAC
- [ ] Test authorization logic

**6. Security Misconfiguration**
- [ ] Remove default credentials
- [ ] Disable directory listing
- [ ] Keep dependencies updated
- [ ] Use security headers (CSP, HSTS)

**7. XSS (Cross-Site Scripting)**
- [ ] Escape output
- [ ] Use Content Security Policy
- [ ] Sanitize HTML inputs

**8. Insecure Deserialization**
- [ ] Validate serialized data
- [ ] Use signing/encryption

**9. Using Components with Known Vulnerabilities**
- [ ] Regular dependency audits
- [ ] Automated security scanning
- [ ] Subscribe to security advisories

**10. Insufficient Logging & Monitoring**
- [ ] Log security events
- [ ] Monitor for anomalies
- [ ] Set up alerting

Design database schema for [APPLICATION]:

**Naming Conventions**:
- Tables: plural, snake_case (users, order_items)
- Columns: singular, snake_case (user_id, created_at)
- Primary keys: id (integer, auto-increment)
- Foreign keys: [table_singular]_id

**Standard Columns** (all tables):
- id: Primary key
- created_at: Timestamp
- updated_at: Timestamp
- deleted_at: Soft deletes (optional)

**Relationships**:
- One-to-Many: Foreign key in child table
- Many-to-Many: Junction table
- One-to-One: Foreign key with UNIQUE constraint

**Indexes**:
- Primary key (automatic)
- Foreign keys
- Frequently queried columns
- Composite indexes for multi-column queries

**Data Types**:
- Use appropriate sizes (VARCHAR vs TEXT)
- ENUM for fixed options
- JSON for flexible data (use sparingly)
- UUID for distributed systems

**Constraints**:
- NOT NULL where appropriate
- UNIQUE for natural keys
- CHECK for validation
- DEFAULT values

**Normalization**:
- 3NF for OLTP
- Denormalize for read-heavy (with care)
- Avoid EAV anti-pattern

**Example Schema**:
```sql
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_users_email ON users(email);
```