/engineer-expertise-extractor

name: engineer-expertise-extractor
description: Research and extract an engineer's coding style, patterns, and best practices from their GitHub contributions. Creates structured knowledge base for replicating their expertise.

Engineer Expertise Extractor

Extract and document an engineer's coding expertise by analyzing their GitHub contributions, creating a structured knowledge base that captures their coding style, patterns, best practices, and architectural decisions.

What This Skill Does

Researches an engineer's work to create a "digital mentor" by:

• **Analyzing Pull Requests** - Extract code patterns, review style, decisions
• **Extracting Coding Style** - Document their preferences and conventions
• **Identifying Patterns** - Common solutions and approaches they use
• **Capturing Best Practices** - Their quality standards and guidelines
• **Organizing Examples** - Real code samples from their work
• **Documenting Decisions** - Architectural choices and reasoning

Why This Matters

**Knowledge Preservation:**

• Capture expert knowledge before they leave
• Document tribal knowledge
• Create mentorship materials
• Onboard new engineers faster

**Consistency:**

• Align team coding standards
• Replicate expert approaches
• Maintain code quality
• Scale expertise across team

**Learning:**

• Learn from senior engineers
• Understand decision-making
• See real-world patterns
• Improve code quality

How It Works

1. Research Phase

Using GitHub CLI (`gh`), the skill:

• Fetches engineer's pull requests
• Analyzes code changes
• Reviews their comments and feedback
• Extracts patterns and conventions
• Identifies their expertise areas

2. Analysis Phase

Categorizes findings into:

• **Coding Style** - Formatting, naming, structure
• **Patterns** - Common solutions and approaches
• **Best Practices** - Quality guidelines
• **Architecture** - Design decisions
• **Testing** - Testing approaches
• **Code Review** - Feedback patterns
• **Documentation** - Doc style and practices

3. Organization Phase

Creates structured folders:

engineer_profiles/
└── [engineer_name]/
    ├── README.md (overview)
    ├── coding_style/
    │   ├── languages/
    │   ├── naming_conventions.md
    │   ├── code_structure.md
    │   └── formatting_preferences.md
    ├── patterns/
    │   ├── common_solutions.md
    │   ├── design_patterns.md
    │   └── code_examples/
    ├── best_practices/
    │   ├── code_quality.md
    │   ├── testing_approach.md
    │   ├── performance.md
    │   └── security.md
    ├── architecture/
    │   ├── design_decisions.md
    │   ├── tech_choices.md
    │   └── trade_offs.md
    ├── code_review/
    │   ├── feedback_style.md
    │   ├── common_suggestions.md
    │   └── review_examples.md
    └── examples/
        ├── by_language/
        ├── by_pattern/
        └── notable_prs/

Output Structure

Engineer Profile README

**Contains:**

• Engineer overview
• Areas of expertise
• Languages and technologies
• Key contributions
• Coding philosophy
• How to use this profile

Coding Style Documentation

**Captures:**

• Naming conventions (variables, functions, classes)
• Code structure preferences
• File organization
• Comment style
• Formatting preferences
• Language-specific idioms

**Example:**

# Coding Style: [Engineer Name]

## Naming Conventions

### Variables
- Use descriptive names: `userAuthentication` not `ua`
- Boolean variables: `isActive`, `hasPermission`, `canEdit`
- Collections: plural names `users`, `items`, `transactions`

### Functions
- Verb-first: `getUserById`, `validateInput`, `calculateTotal`
- Pure functions preferred
- Single responsibility

### Classes
- PascalCase: `UserService`, `PaymentProcessor`
- Interface prefix: `IUserRepository`
- Concrete implementations: `MongoUserRepository`

## Code Structure

### File Organization
- One class per file
- Related functions grouped together
- Tests alongside implementation
- Clear separation of concerns

### Function Length
- Max 20-30 lines preferred
- Extract helper functions
- Single level of abstraction

Patterns Documentation

**Captures:**

• Recurring solutions
• Design patterns used
• Architectural patterns
• Problem-solving approaches

**Example:**

# Common Patterns: [Engineer Name]

## Dependency Injection

Used consistently across services:

\`\`\`typescript
// Pattern: Constructor injection
class UserService {
  constructor(
    private readonly userRepo: IUserRepository,
    private readonly logger: ILogger
  ) {}
}
\`\`\`

**Why:** Testability, loose coupling, clear dependencies

## Error Handling

Consistent error handling approach:

\`\`\`typescript
// Pattern: Custom error types + global handler
class ValidationError extends Error {
  constructor(message: string) {
    super(message);
    this.name = 'ValidationError';
  }
}

// Usage
if (!isValid(input)) {
  throw new ValidationError('Invalid input format');
}
\`\`\`

**Why:** Type-safe errors, centralized handling, clear debugging

Best Practices Documentation

**Captures:**

• Quality standards
• Testing approaches
• Performance guidelines
• Security practices
• Documentation standards

**Example:**

# Best Practices: [Engineer Name]

## Testing

### Unit Test Structure
- AAA pattern (Arrange, Act, Assert)
- One assertion per test preferred
- Test names describe behavior
- Mock external dependencies

\`\`\`typescript
describe('UserService', () => {
  describe('createUser', () => {
    it('should create user with valid data', async () => {
      // Arrange
      const userData = { email: 'test@example.com', name: 'Test' };
      const mockRepo = createMockRepository();

      // Act
      const result = await userService.createUser(userData);

      // Assert
      expect(result.id).toBeDefined();
      expect(result.email).toBe(userData.email);
    });
  });
});
\`\`\`

### Test Coverage
- Aim for 80%+ coverage
- 100% coverage for critical paths
- Integratio