engineer-expertise-extractor

エンジニアの専門知識の抽出

エンジニアのGitHubへの貢献を分析してコーディングの専門知識を抽出し、コーディングスタイル、パターン、ベストプラクティス、アーキテクチャ上の決定をまとめた体系的なナレッジベースを作成します。

このスキルでできること

エンジニアの仕事を調査し、「デジタルメンター」を作成します。

• プルリクエストの分析 - コードのパターン、レビューのスタイル、決定を抽出します
• コーディングスタイルの抽出 - エンジニアの好みや規約を文書化します
• パターンの特定 - よく使われる解決策やアプローチを特定します
• ベストプラクティスの把握 - 品質基準やガイドラインを記録します
• サンプルの整理 - 実際の業務で書かれたコード例を整理します
• 決定の文書化 - アーキテクチャ上の選択とその理由を文書化します

重要性

知識の保存：

• エキスパートが退職する前に知識を記録します
• 暗黙知を文書化します
• メンタリングの資料を作成します
• 新しいエンジニアのオンボーディングを迅速化します

一貫性：

• チームのコーディング規約を統一します
• エキスパートのアプローチを再現します
• コード品質を維持します
• チーム全体で専門知識を活用できるようにします

学習：

• シニアエンジニアから学びます
• 意思決定の方法を理解します
• 実際のパターンを確認します
• コード品質を向上させます

動作の仕組み

1. 調査フェーズ

GitHub CLI（gh）を使用して、このスキルは次の処理を行います。

• エンジニアのプルリクエストを取得します
• コード変更を分析します
• コメントやフィードバックを確認します
• パターンや規約を抽出します
• 専門分野を特定します

2. 分析フェーズ

分析結果を次のカテゴリに分類します。

• コーディングスタイル - 書式、命名、構造
• パターン - よく使われる解決策やアプローチ
• ベストプラクティス - 品質ガイドライン
• アーキテクチャ - 設計上の決定
• テスト - テストのアプローチ
• コードレビュー - フィードバックのパターン
• ドキュメント - ドキュメントのスタイルや慣習

3. 整理フェーズ

次のような体系的なフォルダーを作成します。

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/

出力構成

エンジニアプロフィールのREADME

内容：

• エンジニアの概要
• 専門分野
• 言語とテクノロジー
• 主な貢献
• コーディング哲学
• このプロフィールの使い方

コーディングスタイルのドキュメント

記録する内容：

• 命名規則（変数、関数、クラス）
• コード構造の好み
• ファイルの整理方法
• コメントのスタイル
• 書式の好み
• 言語固有の慣用表現

例：

# 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

パターンのドキュメント

記録する内容：

• 繰り返し使われる解決策
• 使用するデザインパターン
• アーキテクチャパターン
• 問題解決のアプローチ

例：

# 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: [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: '[email protected]', 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
- Integration tests for APIs
- E2E tests for user flows

## Code Review Standards

### What to Check
- [ ] Tests included and passing
- [ ] No console.logs remaining
- [ ] Error handling present
- [ ] Comments explain "why" not "what"
- [ ] No hardcoded values
- [ ] Security considerations addressed

アーキテクチャのドキュメント

記録する内容：

• 設計上の決定
• テクノロジーの選択
• 選択に伴うトレードオフ
• システム設計のアプローチ

例：

# Architectural Decisions: [Engineer Name]

## Decision: Microservices vs Monolith

**Context:** Scaling user service
**Decision:** Start monolith, extract services when needed
**Reasoning:**
- Team size: 5 engineers
- Product stage: MVP
- Premature optimization risk
- Easier debugging and deployment

**Trade-offs:**
- Monolith pros: Simpler, faster development
- Monolith cons: Harder to scale later
- Decision: Optimize for current needs, refactor when hitting limits

## Decision: REST vs GraphQL

**Context:** API design for mobile app
**Decision:** REST with versioning
**Reasoning:**
- Team familiar with REST
- Simple use cases
- Caching easier
- Over-fetching not a problem yet

**When to reconsider:** If frontend needs complex queries

コードレビューのドキュメント

記録する内容：

• フィードバックのパターン
• レビューの進め方
• よくある提案
• コミュニケーションスタイル

例：

# Code Review Style: [Engineer Name]

## Review Approach

### Priority Order
1. Security vulnerabilities
2. Logic errors
3. Test coverage
4. Code structure
5. Naming and style

### Feedback Style
- Specific and constructive
- Explains "why" behind suggestions
- Provides examples
- Asks questions to understand reasoning

### Common Suggestions

**Security:**
- "Consider input validation here"
- "This query is vulnerable to SQL injection"
- "Should we rate-limit this endpoint?"

**Performance:**
- "This N+1 query could be optimized with a join"
- "Consider caching this expensive operation"
- "Memoize this pure function"

**Testing:**
- "Can we add a test for the error case?"
- "What happens if the API returns null?"
- "Let's test the boundary conditions"

**Code Quality:**
- "Can we extract this into a helper function?"
- "This function is doing too many things"
- "Consider a more descriptive variable name"

このスキルの使い方

エンジニアプロフィールの抽出

./scripts/extract_engineer.sh [github-username]

対話型ワークフロー：

1. GitHubユーザー名を入力します
2. リポジトリの範囲（すべて／特定の組織）を選択します
3. 分析の深さ（直近N件のPR）を選択します
4. 対象分野（言語、トピック）を指定します
5. 分析結果を抽出して整理します

出力： engineer_profiles/[username]/ に作成される体系的なプロフィール

特定のリポジトリの分析

./scripts/analyze_repo.sh [repo-url] [engineer-username]

特定のリポジトリへの貢献に絞って分析します。

既存プロフィールの更新

./scripts/update_profile.sh [engineer-username]

新しいPRを追加し、既存のプロフィールを更新します。

調査ソース

GitHub CLIのクエリ

プルリクエスト：

gh pr list --author [username] --limit 100 --state all
gh pr view [pr-number] --json title,body,files,reviews,comments

コード変更：

gh pr diff [pr-number]
gh api repos/{owner}/{repo}/pulls/{pr}/files

レビュー：

gh pr view [pr-number] --comments
gh api repos/{owner}/{repo}/pulls/{pr}/reviews

コミット：

gh api search/commits --author [username]

分析手法

パターン認識：

• 繰り返し使われるコード構造を特定する
• 共通する解決策を抽出する
• 命名パターンを検出する
• アーキテクチャ上の選択を見つける

スタイルの抽出：

• フォーマットの一貫性を分析する
• 命名規則を抽出する
• コメントのパターンを特定する
• 構造上の好みを検出する

ベストプラクティスの特定：

• テストのパターンを調べる
• エラー処理の手法を見つける
• セキュリティ対策を特定する
• パフォーマンス最適化を抽出する

ユースケース

1. 新しいエンジニアのオンボーディング

課題： 新しいエンジニアがチームの標準を学ぶ必要がある 解決策： シニアエンジニアのプロフィールを参考資料として提供する

メリット：

• コードベースにある実例を参照できる
• チームの慣習を理解できる
• 意思決定のプロセスを確認できる
• ベストプラクティスを学べる

2. コードレビューのトレーニング

課題： 優れたコードレビューのスキルを教える 解決策： 経験豊富なレビュアーのフィードバックのパターンを学ぶ

メリット：

• 確認すべき点を学べる
• フィードバックのスタイルを理解できる
• よくある問題を確認できる
• レビューの質を高められる

3. 知識移転

課題： シニアエンジニアの退職により、知識が失われる 解決策： 退職前にその専門知識を抽出する

メリット：

• 暗黙知を保持できる
• 意思決定を文書化できる
• コードの品質を維持できる
• バス係数を下げられる

4. チーム標準の確立

課題： チーム内でコーディングスタイルに一貫性がない 解決策： 優れたエンジニアのパターンを抽出し、標準を作成する

メリット：

• 根拠に基づく標準を策定できる
• 実例を活用できる
• チームの賛同を得られる
• コードベースの一貫性を保てる

5. AI エージェントのトレーニング

課題： エージェントが特定のエンジニアのようにコードを書く必要がある 解決策： 抽出したプロフィールをエージェントに提供する

メリット：

• エキスパートのスタイルに合わせられる
• その人のパターンに従える
• その人のベストプラクティスを適用できる
• 一貫性を維持できる

エージェントによるプロフィールの活用

エージェントがエンジニアのプロフィールを利用できる場合、次のことができます。

コード生成：

• 抽出した命名規則に従う
• 特定されたパターンを使用する
• 文書化されたベストプラクティスを適用する
• アーキテクチャのスタイルを合わせる

コードレビュー：

• エンジニアのスタイルでフィードバックを提供する
• その人が見つけるであろう一般的な問題を確認する
• その人の品質基準を適用する
• その人の優先事項に合わせる

問題解決：

• その人がよく使う解決策を用いる
• その人のアーキテクチャ上のアプローチに従う
• その人のデザインパターンを適用する
• その人が考慮するトレードオフを検討する

エージェントプロンプトの例：

"Using the profile at engineer_profiles/senior_dev/, write a user service
following their coding style, patterns, and best practices. Pay special
attention to their error handling approach and testing standards."

ベストプラクティス

調査倫理

すること：

• ✅ 抽出する前に許可を得る
• ✅ 公開されている貢献に焦点を当てる
• ✅ プライバシーを尊重する
• ✅ 学習と改善のために活用する

しないこと：

• ❌ 許可なく抽出する
• ❌ プロフィールを外部に共有する
• ❌ 機密情報を含める
• ❌ 人事評価に使用する

プロフィールのメンテナンス

定期的な更新：

• 四半期ごとに更新する
• 新たに重要な PR を追加する
• 最新のパターンを反映する
• 古くなった手法をアーカイブする

品質管理：

• 抽出したパターンを検証する
• 例が適切かどうかを確認する
• ドキュメントを更新する
• 非推奨の手法を削除する

効果的な活用

学習する場合：

• コンテキストとともにパターンを学ぶ
• 選択の背後にある理由を理解する
• 手法を実践する
• 不明な点は質問する

再現する場合：

• スタイルガイドから始める
• 類似した問題のパターンを参照する
• 現在のコンテキストに合わせて調整する
• むやみにコピーしない

制限事項

抽出できる内容：

• ✅ コーディングスタイルと慣習
• ✅ よく使われるパターンとアプローチ
• ✅ ベストプラクティスとガイドライン
• ✅ アーキテクチャ上の決定
• ✅ レビューのフィードバックパターン

把握できない内容：

• ❌ リアルタイムの問題解決プロセス
• ❌ 口頭でのコミュニケーションスタイル
• ❌ 会議での議論
• ❌ 設計段階での思考
• ❌ 対人関係におけるメンタリング

今後の機能強化

追加の可能性：

• Slack メッセージの分析（コミュニケーションスタイル）
• 設計ドキュメントの抽出（設計思考）
• 会議メモの分析（意思決定プロセス）
• 動画の分析（ペアプログラミングのセッション）
• コードメトリクスの追跡（時間の経過に伴う変化）

出力例

engineer_profiles/
└── senior_dev/
    ├── README.md
    │   # Senior Dev - Staff Engineer
    │   Expertise: TypeScript, Node.js, System Design
    │   Focus: API design, performance optimization
    │
    ├── coding_style/
    │   ├── typescript_style.md
    │   ├── naming_conventions.md
    │   └── code_structure.md
    │
    ├── patterns/
    │   ├── dependency_injection.md
    │   ├── error_handling.md
    │   └── examples/
    │       ├── service_pattern.ts
    │       └── repository_pattern.ts
    │
    ├── best_practices/
    │   ├── testing_strategy.md
    │   ├── code_quality.md
    │   └── performance.md
    │
    ├── architecture/
    │   ├── api_design.md
    │   ├── database_design.md
    │   └── scaling_approach.md
    │
    ├── code_review/
    │   ├── feedback_examples.md
    │   └── review_checklist.md
    │
    └── examples/
        └── notable_prs/
            ├── pr_1234_auth_refactor.md
            └── pr_5678_performance_fix.md

概要

このスキルは、エンジニアの GitHub への貢献を、構造化された再利用可能なナレッジベースに変換します。専門知識を、次のような形式で記録します。

• 人が学べる - 例を含む明確なドキュメント
• エージェントが再現できる - 構造化されたパターンとガイドライン
• チームが導入できる - エビデンスに基づくベストプラクティス
• 組織が継承できる - 人員の入れ替わり後も残る知識

目標： 専門知識を、拡張可能で、学習でき、再現可能なものにします。

---

「学ぶための最良の方法は、すでにそれを習得した人から学ぶことです。」