前五天把需求和架構說清楚了，現在要把共識放進 Repository。只留在聊天紀錄裡的決策，下一次開新任務時很容易消失；寫成文件，才有機會讓人和 Codex 在同一個起點工作。今天的目標是做一份能用的 README，以及一份短到願意維護的 AGENTS.md。

README 回答「這個專案怎麼跑」

README 的讀者是第一次接觸專案的人。開頭說明任務追蹤 App 的使用情境與 MVP 範圍，接著列出前置工具、安裝與啟動步驟、環境變數範例、測試指令、主要目錄，以及目前尚未完成的功能。每條指令都應在乾淨環境中照順序執行過，再寫成確定可用的步驟。

我會把「預定技術」和「已實作」分開。Day 5 暫選 Next.js、TypeScript 與 PostgreSQL，但如果 Repository 尚未建立，README 不能假裝安裝指令或資料庫連線已通過驗證。實作後再補上真實指令、版本與輸出，並在修改啟動方式時同步更新文件。

AGENTS.md 回答「修改時要守什麼規則」

AGENTS.md 不需要把整本開發手冊再抄一次。第一版只放會直接影響代理行為的規則：先閱讀相關程式與測試；修改範圍限於任務需要；不要寫入或回報憑證；對不存在的指令與檔案不要猜；完成時列出修改、驗證結果與尚未解決的限制。涉及資料刪除或部署的動作，先把影響與回復方式講清楚。

這些規則不能互相打架。例如一邊要求「每次都跑完整測試」，一邊又要求「小修只做最快檢查」，代理很難知道優先順序。我會寫成：「先跑與改動最相關的檢查；若變動跨模組或涉及資料層，再擴大驗證；無法執行時說明原因。」規則要能幫助決策，而不是增加儀式。

用一個反例測試文件是否有效

假設下一個任務是修正新增任務表單，而代理看完 README 後仍找不到測試入口，只好問「我要跑哪個指令？」這表示文件並沒有完成它的工作。另一個反例是 AGENTS.md 寫了「不要改不相關檔案」，卻沒有說如何回報原本就存在的失敗測試；代理可能為了讓輸出好看，順手修了範圍外的問題。規則應要求把既有失敗列出，交由任務擁有人決定是否擴大範圍。

第一版 AGENTS.md 可以控制在幾個短段落：專案入口、修改邊界、驗證、回報格式、敏感資料處理。只有遇到重複失誤時才增加規則，並附上它要防止的情境。若一條規則需要長篇解釋，通常代表它應該放進一般文件，或拆成更清楚的任務驗收條件。

今天的 Prompt 與驗收

交給 Codex 的任務描述可以是：「先只讀目前 Repository，列出 README 和 AGENTS.md 已有內容、與 Day 4 PRD／Day 5 架構不一致的地方。提出最小修訂清單；不要先改程式。修訂後請指出每一條新增規則要避免哪種具體錯誤，並確認文件中的指令實際可執行。」

驗收不是文件字數，而是讓新任務能少問重複問題。我會用 Day 7 的第一個小功能回頭檢查：Codex 是否找到正確入口、是否照文件跑檢查、是否仍需要我重述相同限制。若某條規則從未派上用場，或造成誤解，就刪掉或改寫。

今天的結果與限制

目前形成的是兩份文件的內容規格與可驗收標準，尚未在真實 Repository 寫入或跑通，因此不能宣稱環境已可重現。這個限制會延續到後續文章的實測欄位，直到實際專案建立並留存證據。

今天學到什麼？

好的協作規則不是替 AI 預先寫出所有答案，而是讓它知道去哪裡查、什麼能改、怎麼證明改對。明天會用第一個小功能檢驗這些文件是否真的有幫助。