---

name: learning-before-coding description: >- 新しいコードを書く前に既存の実装から学ぶことを強制する。 新機能の実装、クラス/関数の追加、既存コードの修正時にこのスキルを使用する。 AIがプロジェクト規約を無視した「教科書的な」コードを書くことを防止する。 トリガー：新機能実装、コンポーネント追加、リファクタリング、コード生成リクエスト。

コーディング前の学習

新しいコードを書く前に既存の実装を分析する。既存のコードベースこそがプロジェクト規約のドキュメントである。

基本原則

このプロジェクトで類似のコードがどのように書かれているかを理解せずにコードを書いてはならない。

AIは一般的なベストプラクティスに従った「教科書的に正しい」コードを書く傾向があるが、プロジェクト固有のパターンを無視しがちである。このスキルは必須の分析フェーズを強制することでそれを防ぐ。

必須の実装前ワークフロー

ステップ1：類似コードの特定

何かを実装する前に、以下の条件を満たす既存のコードを見つける：

• 同じレイヤー：リポジトリを追加するなら、他のリポジトリを見つける
• 同じ種類：サービスを追加するなら、他のサービスを見つける
• 同じドメイン：認証周りで作業するなら、他の認証コードを見つける
• 同じパターン：APIエンドポイントを追加するなら、他のエンドポイントを見つける

検索戦略（例)：

Copy# 類似のクラス/モジュールを検索
Glob: **/*Repository*.{ts,py,go,rs}
Glob: **/*UseCase*.{ts,py,go,rs}
Glob: **/*Controller*.{ts,py,go,rs}

# 類似のパターンを検索
Grep: "class.*Repository"
Grep: "interface.*UseCase"

ステップ2：プロジェクトパターンの抽出

2〜3個の類似実装を分析してドキュメント化する。コードタイプ別の詳細なチェックリストについては、pattern-checklist.mdを参照。

ステップ3：コーディング前に発見事項をドキュメント化

メンタルチェックリストを作成：

Copyプロジェクトパターン分析：
- [ ] 構造: [例：「インターフェースなしの直接クラス」]
- [ ] 命名: [例：「PascalCase、*Repositoryサフィックス」]
- [ ] DIパターン: [例：「コンストラクタインジェクション」]
- [ ] エラー処理: [例：「カスタム例外」]
- [ ] テストパターン: [例：「*.test.tsを同じ場所に配置」]

ステップ4：パターンに従って実装

ステップ1〜3を完了した後にのみ、以下を満たすコードを書く：

• 特定した構造に正確に一致
• 同じ命名規約を使用
• 同じエラー処理アプローチに従う
• ファイルを同じ場所に配置

避けるべきアンチパターン

クイックリファレンスチェックリスト

新しいコードを書く前に：

1. 検索：2〜3個の類似する既存実装を見つける
2. 読む：その構造、パターン、規約を学ぶ
3. 抽出：プロジェクト固有のパターンをドキュメント化
4. 一致：新しいコードが特定したパターンに正確に従うようにする
5. 検証：新しいコードを既存の例と比較

例

悪い例：分析なしでコードを書く

Copyユーザー：「UserRepositoryを追加して」
AI：*すぐに書き始める*
interface IUserRepository { ... }
class UserRepository implements IUserRepository { ... }

良い例：まず分析する

Copyユーザー：「UserRepositoryを追加して」
AI：*まず検索する*
Glob: **/*Repository*.ts

AI：*既存のリポジトリを読む*
発見：ProductRepository.ts, OrderRepository.ts
パターン：インターフェースなしの直接クラスエクスポート、コンストラクタDI

AI：*次にパターンに合わせて実装*
class UserRepository {
  constructor(private db: Database) {}
  ...
}

開発ワークフローとの統合

このスキルは以下のタイミングで有効化すべき：

• 実装タスクの開始時
• 新しいクラス、関数、モジュールを書く前
• 既存コードをリファクタリングする時
• 新機能のテストを追加する時

分析フェーズは通常2〜5分かかるが、何時間ものリファクタリングを節約できる。