project-references

---

プロジェクト参照

このスキルは、自分の GitHub リポジトリのローカルミラーを ~/projects/referenzen/ の下に管理し、推測したり、すべてのリポジトリを手当たり次第に読んだりせずに、規約や実装パターンを参照できるようにします。

参照プロジェクトに対する操作はすべて読み取り専用です。このディレクトリに書き込むのは git clone と git pull のみで、編集は行いません。

---

手順

ステップ 1：関連するリポジトリがすでにクローンされているか確認する

ls ~/projects/referenzen/

必要なリポジトリがない場合は、まず scripts/clone-or-update.sh owner/repo を実行してクローンします。

ステップ 2：最も関連性の高い参照プロジェクトをユーザーに尋ねる

すべてのリポジトリを手当たり次第にスキャンしないでください。そうするとコンテキストが埋まってしまいます。「このパターンを使っている兄弟プロジェクトはどれですか？」と尋ねるか、利用可能なリポジトリを一覧表示してユーザーに選んでもらいます。

ステップ 3：対象を絞って検索する ― まずファイルを探し、その後 grep する

find でファイル名からファイルを探し、cat または grep で関連箇所だけを読みます。検索コマンドとパターンについては、references/search-patterns.md を参照してください。

ステップ 4：パターンを採用する際は出典を明記する

パターンを適用する前に、どのプロジェクトのどのファイルパスに由来するかを必ず明記します。

your-service の helm-charts/Chart.yaml 4 行目から採用したパターン

ステップ 5：明示的に依頼された場合のみ同期する

ユーザーが「すべて同期」または「参照をすべて更新」と言った場合に限り、scripts/sync-all.sh を実行します。単一のリポジトリの場合は、scripts/clone-or-update.sh を使います。

---

例

例 1：Helm チャートの規約を調べる

ユーザーの依頼：「このプロジェクトの Helm チャートはどのような構成にすればよいですか？」

操作：

1. 利用可能なリポジトリを確認するため、ls ~/projects/referenzen/ を実行します
2. 「どの兄弟プロジェクトを参照にしますか？」と尋ねます。ユーザーは your-service と答えます
3. find ~/projects/referenzen/your-service -name "Chart.yaml" を実行してファイルを探します
4. ファイルを読み、構成（apiVersion、依存関係、バージョンのパターン）を確認します
5. 同じ構成を適用し、「your-service/helm-charts/Chart.yaml から採用」と明記します

結果：兄弟プロジェクトと一貫性があり、追跡可能な出典が明記された Helm チャートになります。

例 2：新しい参照リポジトリをチェックアウトする

ユーザーの依頼：「参照用に other-service プロジェクトをクローンして」

操作：

1. bash scripts/clone-or-update.sh owner/other-service を実行します
2. CLONE/PULL/SKIP の進行状況がユーザーに見えるよう、出力をストリーミングします
3. ls ~/projects/referenzen/other-service/ で確認します

結果：パターンを調べるためのリポジトリがローカルで利用可能になります。編集は行われません。

例 3：設定パターンを見つける

ユーザーの依頼：「ほかのプロジェクトと同じようにデータベースのプールを設定するにはどうすればよいですか？」

操作：

1. ls ~/projects/referenzen/ で関連する兄弟プロジェクトを選びます
2. grep -rn "database.pool" ~/projects/referenzen/your-service/src/main/resources/ を実行します
3. 関連する設定箇所を読みます
4. 「your-service/src/main/resources/application.yaml の 42 行目のパターン」と明記します

結果：推測ではなく、実績のある兄弟プロジェクトの正確な設定を参照できます。

例 4：GitHub Actions のトリガーを一覧で確認する

ユーザーの依頼：「プロジェクトの GitHub Actions はいつ実行されますか？ push、PR、それともスケジュールですか？」

操作：

1. bash scripts/list-workflow-triggers.sh を実行します（パイプラインを 1 つに絞るには --glob を、別のチェックアウトディレクトリを指定するには --root を追加します）
2. 曜日と時刻を人間が読みやすい形式と元の cron 形式で示した、ソート済みの一覧と、イベントのみで実行されるワークフローを提示します
3. 生成されたレポート target/workflow-triggers.md を案内します

結果：各ワークフローファイルを開かずに、参照リポジトリ全体のトリガーを時刻順にまとめた一覧と Markdown レポートを確認できます。

---

リポジトリの取得元

対応している取得元は 2 種類です。手動リストがある場合は、そちらを優先します。

1. 手動リスト（~/claude-shared/projekte.txt）：1 行につき GitHub リポジトリの URL または owner/name のスラッグを記載します。空行と # で始まるコメントは無視されます。
2. 自動検出：ファイルがない場合、またはユーザーが明示的に全件同期を依頼した場合に、gh repo list --limit 200 --json nameWithOwner を実行します。

---

スクリプト

すぐに使えるスクリプトが scripts/ に 2 つあります。インライン Bash を書く代わりに、これらを使用してください。どちらも環境変数による REFERENZEN_DIR の上書きに対応しています（デフォルト：~/projects/referenzen）。

scripts/clone-or-update.sh <owner/repo>

単一のリポジトリをクローンするか、ローカルにすでに存在する場合はプルします。ローカルに変更がある場合はプルを拒否します（終了コード 2）。スタッシュもリセットもしません。

bash scripts/clone-or-update.sh owner/your-repo

終了コード：0 = 成功、2 = スキップ（ローカルに変更あり）、3 = クローン／プル失敗。

scripts/sync-all.sh [--list <file>] [--limit <n>]

すべてのリポジトリを順に処理し、それぞれにクローンまたは更新のロジックを適用します。リストの取得元として ~/claude-shared/projekte.txt を優先し、ファイルがない場合は gh repo list にフォールバックします。最後に概要行を出力します。

# Sync everything (auto-detect source)
bash scripts/sync-all.sh

# Use a specific list file
bash scripts/sync-all.sh --list ~/claude-shared/projekte.txt

# Limit gh repo list to 50 repos
bash scripts/sync-all.sh --limit 50

決して sync-all を無条件で実行しないでください。ユーザーが明示的に「すべて同期」または「すべての参照を更新」と指示した場合にのみ使用してください。単一のリポジトリには、clone-or-update.sh を優先してください。

scripts/list-workflow-triggers.sh [--root <dir>] [--glob <pattern>] [--out <file>] [--no-report]

各リポジトリのチェックアウトをスキャンして .github/workflows/*.yml と *.yaml を探し、on: ブロックからトリガー（push、pull_request、schedule、workflow_dispatch、release など）と cron: 式を抽出し、概要を出力して Markdown レポートを書き出します。スケジュールされたワークフローは曜日／時刻順に並べられ、元の cron 式と並べて、人が読みやすい実行時刻（例：Monday 02:05）が表示されます。スケジュールのないワークフローは、イベントのみのセクションに分けて表示されます。読み取り専用で、ネットワークにはアクセスしません。

• --root <dir> — リポジトリのチェックアウトを含むディレクトリです。デフォルト： $REFERENZEN_DIR または ~/projects/referenzen。
• --glob <pattern> — 任意のファイル名フィルターです。例：maven-build.yml。 デフォルト：すべてのワークフロー。
• --out <file> — Markdown レポートのパスです。デフォルト：target/workflow-triggers.md （現在のプロジェクトディレクトリからの相対パスです。存在しない場合は作成されます）。
• --no-report — 標準出力のみに出力し、レポートファイルは作成しません。

# Overview + report for all reference repos
bash scripts/list-workflow-triggers.sh

# Only maven-build.yml, custom report location
bash scripts/list-workflow-triggers.sh --glob 'maven-build.yml' --out target/maven-triggers.md

# A different checkout root (e.g. Windows mount)
bash scripts/list-workflow-triggers.sh --root /mnt/c/Development/projects/all-git-repos

---

ワークフロー

1. リポジトリをチェックアウトまたは更新する

適切なスクリプトを実行し、出力をそのまま表示して、CLONE／PULL／SKIP の各アクションが発生するたびにユーザーに見えるようにします。

2. 参照プロジェクト内を検索する

検索範囲は、ユーザーが実際に必要としている内容に絞ります。広範な再帰的 grep より、対象を絞った検索を優先してください。すぐに使える検索コマンドと引用パターンについては、references/search-patterns.md を参照してください。

3. 利用可能な参照プロジェクトを見つける

ls ~/projects/referenzen/

~/claude-shared/projekte.txt が存在する場合は、その内容もあわせて表示し、追跡対象のリポジトリとローカルに存在するリポジトリを説明してください。

4. GitHub Actions のトリガーの概要

scripts/list-workflow-triggers.sh を実行して、各ワークフローの on: トリガーと cron: エントリをリポジトリ横断で確認します。また、レポートを target/workflow-triggers.md に書き出します。単一のパイプラインに絞るには --glob（例：maven-build.yml）を使用し、別のチェックアウトディレクトリを指定するには --root を使用します。

---

このスキルを先回りして提案する場合

次のような場合は、参照プロジェクトを調べることを提案してください。

• ユーザーが何かの構成方法を尋ねており、プロジェクトの慣例によって回答が異なる可能性がある場合（Helm チャートのレイアウト、Flyway マイグレーションの命名、Dockerfile のパターン、Maven プラグインの順序など）
• 妥当な方法が複数あり、関連プロジェクトとの一貫性が重要な場合
• ユーザーが対象のプロジェクトを指定せずに「ほかのプロジェクトと同じように」や「前と同じように」と言う場合

すべてをスキャンするのではなく、どの参照プロジェクトが最も関連するかをユーザーに尋ねてください。スキャンはコンテキストを多く消費します。

---

安全上のルール

• ~/projects/referenzen/ 内のファイルを編集、ステージ、コミット、削除しないでください。
• ローカルの変更が原因で git pull が失敗する場合は、競合を明確に報告して停止してください。スタッシュ、リセット、強制操作は行わないでください。
• シークレットを含むリポジトリの内容（.env、認証情報ファイル）を回答で公開しないでください。構造のみを読み取り、引用してください。