解釋一個陌生的程式庫
目標：為新手提供一份可信賴的地圖，附上檔案參考，僅需幾頁篇幅。每個論述必須指向你實際讀取過的檔案。
按此順序探索
- 目的與使用者：README、套件描述、文件索引。這個專案解決什麼問題？為誰解決？
- 執行它：從清單檔案、Makefile 和 CI 配置中的安裝、執行、測試指令。執行那些成本較低的指令（測試、語法檢查）以確認它們能運作；標註哪些你沒有執行。
- 結構：兩層深度的目錄樹（忽略
node_modules、建置輸出、.git）。記錄語言、框架、monorepo 佈局。 - 進入點：
main、伺服器啟動檔案、CLI 進入點、路由定義、排程工作、事件處理器、bin和scripts條目。 - 追蹤一個完整的實際流程：挑選最核心的請求、指令或事件，從進入點一路追蹤到儲存或輸出，依序列出每個檔案與函式。
- 資料：綱要、模型、遷移檔案、配置檔、程式碼讀取的環境變數（僅變數名稱，絕不包含值）。
- 外部接觸點：資料庫、佇列、第三方 API、驗證提供者。
- 品質訊號：測試放在哪裡、涵蓋範圍、CI 檢查、語法檢查規則、有 TODO 的區域、過大的檔案、近期變更（
git log --since="3 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head）。
輸出
# <repo> 一頁摘要
目的：...
如何執行：<指令，已驗證或未驗證>
地圖：<目錄 -> 職責，一行一個>
一個流程，逐步說明：<檔案:函式 ...>
資料與配置：...
外部服務：...
從哪裡開始閱讀：<3 個檔案，附順序與原因>
風險或困惑的區域：<檔案，原因>
待確認的問題：<你無法確定的事項>
規則
- 每個論述必須引用
path:line或至少path。如果是推斷的結論，請標註為「推斷」。 - 不要描述你未曾開啟的程式碼。不要猜測業務上下文；將其列入待確認的問題。
- 絕不從
.env檔案或配置中印出機密值；僅列出變數名稱。 - 保持簡潔：是一張地圖，而非每個檔案的導覽。