> For the complete documentation index, see [llms.txt](https://livlog-llc.gitbook.io/engineering-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://livlog-llc.gitbook.io/engineering-handbook/fu-lu/33-technology-stack-audit-prompt.md).

# 33. 技術スタック調査プロンプト

このページでは、各プロダクトのリポジトリから技術スタックを調査し、Handbookへ正確に反映するための共通プロンプトを定義します。

依存関係ファイルに名前があるだけで、その技術を現在利用しているとは限りません。過去の設定、未使用の依存関係、開発専用ツール、推移的依存関係を区別し、確認できた事実だけを記録します。

## 使い方

1. 調査対象のプロダクトリポジトリを開く
2. リポジトリ内のファイルを確認できるAIに次のプロンプトを渡す
3. AIが作成または更新した `docs/technology-stack.md` を確認する
4. AIが示した根拠ファイルと調査時点を人間が確認する
5. 不明点をプロダクトの管理者に確認する
6. 確認済みの情報だけをHandbookへ反映する

調査結果は、各リポジトリの `docs/technology-stack.md` に保存します。既存の文書がある場合は内容を確認して更新し、ない場合は新しく作成します。Handbookには詳細な依存関係をすべて複製せず、プロダクトを理解するために必要な主要技術と、その役割を掲載します。

## 共通プロンプト

次のプロンプトを各プロダクトのリポジトリで実行します。`<プロダクト名>` は実際の名称に置き換えます。

```
あなたは <プロダクト名> の技術スタック監査を担当します。
このリポジトリを調査し、現在の実装、ビルド、テスト、デプロイで実際に使用されている技術を、確認できる根拠とともに報告してください。

目的:
- Livlog Engineering Handbookへ反映する技術スタックの一次情報を作る
- 現在利用中の技術と、未使用・過去・候補の技術を区別する
- 人間が根拠ファイルを確認できる形にする
- 調査結果をリポジトリ内の文書として継続的に更新できるようにする

成果物:
- 調査結果を `docs/technology-stack.md` にMarkdownで出力してください。
- `docs/technology-stack.md` が存在する場合は、既存の正しい情報と人間が記述した注記を尊重し、今回の調査結果で更新してください。
- `docs` ディレクトリまたは対象ファイルが存在しない場合は作成してください。
- モノレポでプロダクトごとに文書を分ける既存ルールがある場合は、そのルールを優先し、実際の出力先を最終報告に明記してください。
- チャットの回答だけで完了せず、必ず文書ファイルを作成または更新してください。

重要な制約:
- 調査対象のソースコード、設定、依存関係、CI/CD、デプロイ定義は変更しないでください。変更してよいのは調査結果を記録する文書だけです。
- 推測で補完しないでください。確認できない項目は「不明」としてください。
- READMEの記述だけを事実とせず、設定ファイル、依存関係、ソースコード、CI、デプロイ設定と照合してください。
- ファイルに名前があるだけの技術を「利用中」と断定しないでください。
- 推移的依存関係を、直接採用している技術として報告しないでください。
- 開発用、テスト用、ビルド用、実行時の依存関係を区別してください。
- コメントアウトされた設定、未参照の設定、削除途中のコードは「利用中」としないでください。
- バージョンは確認できた場合だけ記載してください。範囲指定とロック済みバージョンを区別してください。
- APIキー、パスワード、トークン、非公開URL、個人情報などの秘密情報は出力しないでください。存在を確認した場合も値は表示しないでください。
- モノレポの場合は、全体共通の技術と各アプリ固有の技術を分けてください。
- 根拠には、可能な限りリポジトリ相対パスと行番号を付けてください。

最初に確認するもの:
1. AGENTS.mdなどのリポジトリ固有の作業指示
2. README、docs、設計文書
3. package.json、package-lock.json、pnpm-lock.yaml、yarn.lock
4. pom.xml、build.gradle、build.gradle.kts、gradle.properties
5. requirements.txt、pyproject.toml、uv.lock、Pipfile
6. go.mod、Cargo.toml、Gemfile、composer.jsonなどの依存関係ファイル
7. Dockerfile、compose.yaml、コンテナ設定
8. CI/CD設定、デプロイ設定、ホスティング設定
9. DBマイグレーション、スキーマ、ORM設定
10. ソースコードのimport、初期化処理、ルーティング、テンプレート、CSS設定
11. テスト設定、Lint、Formatter、コード生成設定
12. 外部API、地図、ストレージ、認証、監視に関する設定

技術の状態は次のいずれかで分類してください:
- 利用中: 実装や設定から、現在の利用を確認できる
- 開発専用: ローカル開発、ビルド、Lint、テストだけで利用する
- 条件付き: 特定環境または一部機能だけで利用する
- 過去・移行中: 残存しているが、現在の標準とは確認できない
- 候補: 文書やIssueに記載されているだけで、実装を確認できない
- 不明: 情報不足または根拠が矛盾している

次の順番で調査してください:
1. リポジトリの構成と実行単位を把握する
2. 既存の `docs/technology-stack.md` とリポジトリ固有の文書配置ルールを確認する
3. 依存関係と設定から技術候補を抽出する
4. ソースコードとCI/CDで実際の利用を確認する
5. READMEや設計文書との矛盾を探す
6. 秘密情報を含めず、指定形式で調査文書を作成または更新する
7. 作成した文書を読み直し、根拠、リンク、Markdown表、秘密情報の有無を確認する
8. 最終回答で出力先と変更概要を報告する

`docs/technology-stack.md` は次の形式で作成または更新してください:

# <プロダクト名> 技術スタック調査結果

## 調査情報
- 調査日: YYYY-MM-DD
- Git commit: 調査対象のコミットSHA。不明なら「不明」
- 調査範囲: リポジトリ全体、または対象ディレクトリ
- 実行単位: 単一アプリ、モノレポ、静的サイト、API、バッチなど
- 総合確度: 高 / 中 / 低

## Handbook反映用サマリー
- プロダクト種別:
- フロントエンド:
- バックエンド:
- データベース:
- データ形式:
- 地図・位置情報:
- 外部サービス・API:
- インフラ・ホスティング:
- ビルド・パッケージ管理:
- テスト・品質管理:
- CI/CD:
- 監視・運用:

該当しない項目は「該当なし」、確認できない項目は「不明」としてください。
各項目は主要技術だけを簡潔に記載してください。

## 技術詳細
| 領域 | 技術 | 役割 | 状態 | バージョン | 根拠 | 確度 |
|---|---|---|---|---|---|---|
| 例: フロントエンド | 例: HTMX | 画面の部分更新 | 利用中 | 例: 2.0.4 / 不明 | `path/to/file:10-20` | 高 |

確度の基準:
- 高: 依存関係または設定に加え、実装やデプロイでも利用を確認した
- 中: 依存関係と設定では確認したが、実行経路までは確認できない
- 低: 文書、コメント、ファイル名など限定的な根拠しかない

## 実行・デプロイ構成
利用者からデータストアまたは外部サービスまでの流れを、簡潔なテキスト図で示してください。
確認できない接続は推測で追加しないでください。

## README・文書との不一致
| 記述 | 実装で確認した内容 | 根拠 | 推奨対応 |
|---|---|---|---|

不一致がない場合は「確認した範囲では不一致なし」としてください。

## 未使用・過去・候補の可能性がある技術
| 技術 | 判定 | 根拠 | 確認が必要なこと |
|---|---|---|---|

## 不明点と人間への確認事項
- 実装だけでは判断できない事項
- 本番環境でのみ決まる事項
- 管理者に確認すべき事項

## Handbookへの反映案
次のMarkdown表を完成させてください。確認できた事実だけを記載してください。

| 項目 | 内容 |
|---|---|
| プロダクト | <プロダクト名> |
| プロダクト種別 |  |
| フロントエンド |  |
| バックエンド |  |
| データベース |  |
| 主なデータ形式 |  |
| 地図・位置情報 |  |
| 外部サービス・API |  |
| インフラ・ホスティング |  |
| テスト・品質管理 |  |
| CI/CD |  |
| 調査対象コミット |  |
| 最終確認日 |  |

最後に、Handbookへ反映してよい「確認済み」、人間の確認後に反映する「要確認」、現時点では反映しない「根拠不足」の3区分で技術名をまとめてください。

文書を保存した後の最終回答には、次の内容だけを簡潔に記載してください:
- 作成または更新した文書のパス
- 調査対象のコミットSHA
- 確認済み、要確認、根拠不足の件数
- 人間による確認が必要な重要事項
- 文書以外のファイルを変更していないこと
```

## 出力の確認基準

AIの出力をそのままHandbookへ転載せず、次の点を人間が確認します。

* 調査結果がリポジトリ内の文書ファイルとして保存されている
* 調査対象のコミットと調査日が記載されている
* 主要技術ごとに根拠ファイルが示されている
* 実行時と開発時の技術が区別されている
* 現在利用中の技術と、過去・候補の技術が区別されている
* READMEと実装の不一致が明示されている
* 本番環境だけで確認できる情報が推測されていない
* 秘密情報や非公開情報が含まれていない
* 「不明」や「該当なし」が無理に技術名で埋められていない

根拠が弱い技術は、Handbookの共通技術一覧へ追加しません。複数の根拠が矛盾する場合は、プロダクトの管理者による確認を優先します。

## Handbookへの反映方法

調査結果は、次の順序で反映します。

1. [プロダクト一覧](/engineering-handbook/riburoguno/2-products.md)で対象プロダクトと名称を確認する
2. プロダクト別ページがある場合は、主要技術、役割、調査対象コミット、最終確認日を記載する
3. 複数プロダクトで現在利用していることを確認できた技術は、[技術とアーキテクチャ](/engineering-handbook/riburoguno/3-technology-and-architecture.md)の全体像へ反映する
4. 特定のプロダクトだけで使う技術は、全体の標準技術と誤解されないようプロダクト別ページに記載する
5. 過去・移行中・候補の技術は、現在の技術スタックと分けて記載する
6. 技術構成が変わった場合は、再調査して最終確認日と根拠を更新する

Handbookの記述と調査結果が異なる場合は、直ちに一方を正しいと決めず、調査対象のブランチ、コミット、本番環境、移行状況を確認します。