借 buildermethods/agent-os 的三層架構(Standards / Product / Specs),讓 AI 先掃你的 codebase 萃取既有慣例成文件化標準,之後每次寫 code 自動注入,不必每次重講一遍規則。
# 任務:建立並套用本專案的 Agent 標準庫(三層架構)
你要幫我把這個 codebase 的隱性慣例,萃取成 AI agent 可重複使用的明文標準。分三層,逐層產出檔案。
## 第 0 步|先掃描、別猜
- 實際讀取專案檔案(package.json / 設定檔 / 代表性原始碼 / 既有 README),不要憑印象。
- 條列你「觀察到」的事實 vs「推測」的慣例,分開標記。
## 第 1 層|Standards(跨專案通用的技術標準)
產出以下檔案到 `standards/`:
- `tech-stack.md`:語言、框架、套件管理器、資料庫、部署平台(只寫實際用到的)。
- `code-style.md`:命名規則(檔名/變數/元件)、格式化工具(Prettier/ESLint 等)、檔案放哪(例如元件放 {{COMPONENTS_DIR}})。
- `best-practices.md`:本專案實際遵守的工程原則(測試要求、錯誤處理、禁用模式、安全規則)。
## 第 2 層|Product(這個產品是什麼)
產出到 `product/`:
- `mission.md`:產品要解決的問題、目標使用者、價值主張。
- `roadmap.md`:已完成 / 進行中 / 規劃中的功能清單。
## 第 3 層|Specs(單一功能的規格)
每要做一個新功能,就在 `specs/{{FEATURE_SLUG}}/` 建:
- `spec.md`:這個功能的目標、範圍、不做什麼、驗收條件。
- `tasks.md`:拆成可驗證的小任務清單,每項含檔案路徑與驗證方式。
## 套用規則(之後每次寫 code)
- 動工前先讀 `standards/` 對齊風格與技術選型;讀 `product/mission.md` 確認方向。
- 產出的 code 必須符合 `code-style.md`;違反就修正,不要產生不一致的風格。
- 若發現 codebase 與標準文件不符,回報差異並建議更新哪份文件,不要默默照舊。
先從第 0 步掃描 + 產出第 1 層 `standards/` 三份檔案開始。技術棧若已知:{{TECH_STACK_HINT}}。把方括號 [ ] 內的變數換成你的內容,丟進 Claude Code。
不用離開網站,直接看這組 prompt 跑出來長怎樣(AI 即時生成,扣 1 點)。
不只複製貼上 — 下載後放到 ~/.claude/skills/agent-os-extract-codebase-standards-into-agent/SKILL.md,之後每個 session 自動可用(觸發時自動載入)。
mkdir -p ~/.claude/skills/agent-os-extract-codebase-standards-into-agent && mv ~/Downloads/SKILL.md ~/.claude/skills/agent-os-extract-codebase-standards-into-agent/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\agent-os-extract-codebase-standards-into-agent" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\agent-os-extract-codebase-standards-into-agent\SKILL.md"## 這是什麼/解決什麼痛點 Agent OS 是 Brian Casel(Builder Methods)開源的一套「定義與管理 AI 開發標準」的輕量系統。它針對的痛點是:**每次 prompt AI 編碼 agent,你都在重新教它本來就該知道的脈絡**——我們用什麼框架、什麼命名慣例、什麼程式風格、這產品在解決什麼問題。團隊同時用 Claude Code、Cursor、其他 AI 工具時,這個「重複教學」成本更被放大,而且各工具給的答案還可能彼此不一致。 Agent OS 的解法是把這些標準**集中、文件化、並在需要時自動注入**,讓所有 AI 工具對齊同一套規則。 ## 為什麼這來源值得用 它的四步驟很清楚:① **Discover standards**(掃 codebase 萃取既有慣例)② **Inject standards**(按當前工作脈絡注入相關標準)③ **Product planning**(產出對齊的規劃文件)④ **Shape spec**(建立符合標準的規格)。對應的三層架構也好懂:**Standards**(跨專案的技術標準,如 tech-stack.md / code-style.md / best-practices.md)、**Product**(產品層,如 mission.md / roadmap.md)、**Specs**(單一功能規格)。 它的官方定位是「Works alongside Claude Code, Cursor, Antigravity, and other AI tools. Any language, any framework.」——也就是不綁特定工具或語言,這讓它的概念很容易被任何專案借用。 ## 怎麼用(步驟/要點) 本篇 full_prompt 把這套三層架構改寫成一份可直接貼上的任務指令: 1. **先掃描、別猜**:要求 agent 實際讀檔,並把「觀察到的事實」與「推測的慣例」分開標記。 2. **產第 1 層 Standards**:tech-stack / code-style / best-practices 三份檔案,只寫專案實際用到的。 3. **產第 2 層 Product**:mission / roadmap,框住方向。 4. **每個新功能產第 3 層 Spec**:spec.md(範圍/驗收)+ tasks.md(可驗證任務)。 5. **套用規則**:之後每次寫 code 先讀 standards 對齊;發現 code 與標準不符時要回報、不要默默照舊。 把 {{COMPONENTS_DIR}}、{{FEATURE_SLUG}}、{{TECH_STACK_HINT}} 換成你的值即可。產出的這些 .md 文件,本身就是很好的 AGENTS.md / CLAUDE.md 素材來源。 ## 何時用 最適合「已經有一定規模、隱性慣例很多」的既有 codebase——讓 AI 先把規則挖出來文件化,後續協作就不會風格四分五裂。也適合多人 / 多 AI 工具的團隊統一基準。剛起步的空專案可以先只做 Standards 層,等功能長出來再補 Product / Specs。 ## 出處+授權 📎 來源:buildermethods/agent-os(作者 Brian Casel / CasJam Media LLC,MIT 授權)— 本篇為繁中改寫整理,原始內容見上方連結。完整安裝方式、profiles 機制與官方文件見 buildermethods.com/agent-os;本條目僅蒸餾其三層架構與標準萃取/注入的工作流為可直接套用的提示,未逐字搬運其指令檔。
[COMPONENTS_DIR]專案放元件/模組的目錄,例如 src/components、app/、packages/ui
[FEATURE_SLUG]目前要做的功能短名(kebab-case),會用作 specs/ 子資料夾名
[TECH_STACK_HINT](選填)已知的技術棧提示,幫 agent 加速掃描,例如 Next.js + TS + D1
填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
# 任務:建立並套用本專案的 Agent 標準庫(三層架構)
你要幫我把這個 codebase 的隱性慣例,萃取成 AI agent 可重複使用的明文標準。分三層,逐層產出檔案。
## 第 0 步|先掃描、別猜
- 實際讀取專案檔案(package.json / 設定檔 / 代表性原始碼 / 既有 README),不要憑印象。
- 條列你「觀察到」的事實 vs「推測」的慣例,分開標記。
## 第 1 層|Standards(跨專案通用的技術標準)
產出以下檔案到 `standards/`:
- `tech-stack.md`:語言、框架、套件管理器、資料庫、部署平台(只寫實際用到的)。
- `code-style.md`:命名規則(檔名/變數/元件)、格式化工具(Prettier/ESLint 等)、檔案放哪(例如元件放 {{COMPONENTS_DIR}})。
- `best-practices.md`:本專案實際遵守的工程原則(測試要求、錯誤處理、禁用模式、安全規則)。
## 第 2 層|Product(這個產品是什麼)
產出到 `product/`:
- `mission.md`:產品要解決的問題、目標使用者、價值主張。
- `roadmap.md`:已完成 / 進行中 / 規劃中的功能清單。
## 第 3 層|Specs(單一功能的規格)
每要做一個新功能,就在 `specs/{{FEATURE_SLUG}}/` 建:
- `spec.md`:這個功能的目標、範圍、不做什麼、驗收條件。
- `tasks.md`:拆成可驗證的小任務清單,每項含檔案路徑與驗證方式。
## 套用規則(之後每次寫 code)
- 動工前先讀 `standards/` 對齊風格與技術選型;讀 `product/mission.md` 確認方向。
- 產出的 code 必須符合 `code-style.md`;違反就修正,不要產生不一致的風格。
- 若發現 codebase 與標準文件不符,回報差異並建議更新哪份文件,不要默默照舊。
先從第 0 步掃描 + 產出第 1 層 `standards/` 三份檔案開始。技術棧若已知:{{TECH_STACK_HINT}}。這組 prompt 專為 Claude Code 設計。把 prompt 內 3 個方括號 [變數] 換成你自己的內容,貼進 Claude Code 執行即可。難度中等,照變數說明填好後即可上手。
完整 prompt 免費開放閱讀,不用註冊;登入後可一鍵複製、收藏與留言。
prompt 文字本身你可自由使用與修改。但 AI 生成物(圖/音樂/影片/文字)的商用授權,取決於你在 Claude Code 使用的方案與其官方服務條款,請以該工具的授權規範為準。
Studio engineer 視角拆解 Suno 致命弱點(油炸 vocals、高頻 artifact)+ 4 步驟 DAW workflow + Suno Studio 修音 prompt
提案產生器 / 會議處理器 / 內容再利用 / 週五回顧 / 收工 reset — 試了 40 個只有這 5 個沒被丟掉、各省 30+ 分鐘 / 次。
適合:部落格、Medium、Notion 公開頁、Substack — 任何支援 iframe / HTML 嵌入的地方。對方點「看完整」會回到本站、是 prompt 庫的免費 backlink。
<iframe src="https://prompt.luvai.net/embed/agent-os-extract-codebase-standards-into-agent" width="100%" height="380" frameborder="0" style="border:1px solid #e0dcd0;border-radius:4px;" loading="lazy" title="PromptCraft Embed"></iframe>
六個月在 Claude / GPT-4 / Gemini 上用人工 rater A/B 測 200+ prompt 後寫的。包含 persona+constraint stacking / anti-example / role reversal QA / cognitive scaffold / emotional priming / uncertainty CoT / steelman first。
一年的 role-play system prompt + 14-step framework 後總結:真正改變品質的是 5 個單行 prompt。沒有 role、沒有 markdown、沒有「you are an expert」。