Agent OS: Extract Codebase Standards and Auto-Inject into AI Agents
Borrowing the three-layer architecture from buildermethods/agent-os (Standards / Product / Specs): have AI first scan your codebase to extract existing conventions into documented standards, then auto-inject them every time it writes code — so you never have to re-explain the rules.
# 任務:建立並套用本專案的 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}}。Swap the variables inside the [ ] brackets for your own content, then paste into Claude Code.
See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.claude/skills/agent-os-extract-codebase-standards-into-agent/SKILL.md and every future session can use it automatically.
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"## What it is / what pain point it solves Agent OS is a lightweight system for 'defining and managing AI development standards,' open-sourced by Brian Casel (Builder Methods). The pain point it targets: every time you prompt an AI coding agent, you're re-teaching it context it should already know — what framework you use, what naming conventions, what code style, what problem this product solves. When a team uses Claude Code, Cursor, and other AI tools simultaneously, this 'repeated teaching' cost is amplified further, and different tools may even give inconsistent answers. Agent OS's solution is to centralize, document, and automatically inject these standards as needed, so all AI tools align to the same set of rules. ## Why this source is worth using Its four steps are clear: (1) Discover standards (scan the codebase to extract existing conventions), (2) Inject standards (inject relevant standards based on current work context), (3) Product planning (produce aligned planning documents), (4) Shape spec (create specs that conform to the standards). The corresponding three-layer architecture is equally easy to grasp: Standards (cross-project technical standards, e.g. tech-stack.md / code-style.md / best-practices.md), Product (the product layer, e.g. mission.md / roadmap.md), and Specs (single-feature specifications). Its official positioning is 'Works alongside Claude Code, Cursor, Antigravity, and other AI tools. Any language, any framework.' — meaning it isn't tied to a specific tool or language, which makes its concept easy to borrow for any project. ## How to use it (steps / key points) This entry's full_prompt rewrites the three-layer architecture into a task instruction you can paste directly: 1. Scan first, don't guess: have the agent actually read the files, and clearly separate 'observed facts' from 'inferred conventions.' 2. Produce Layer 1, Standards: three files — tech-stack, code-style, best-practices — covering only what the project actually uses. 3. Produce Layer 2, Product: mission and roadmap, framing the direction. 4. Produce a Layer 3 Spec for each new feature: spec.md (scope/acceptance criteria) plus tasks.md (verifiable tasks). 5. Apply the rules: from then on, read the standards before writing any code to stay aligned; if code doesn't match the standards, flag it — don't silently leave it as-is. Swap in {{COMPONENTS_DIR}}, {{FEATURE_SLUG}}, and {{TECH_STACK_HINT}} with your own values. These generated .md documents are themselves excellent source material for an AGENTS.md / CLAUDE.md. ## When to use it Best suited to an existing codebase that already has some scale and a lot of implicit conventions — let AI dig out the rules and document them first, so subsequent collaboration doesn't fragment into different styles. Also good for teams with multiple people or multiple AI tools who need a shared baseline. For a brand-new, empty project, you can start with just the Standards layer and add Product/Specs once features start to grow. Source: buildermethods/agent-os (by Brian Casel / CasJam Media LLC, MIT License) — this entry is a Traditional Chinese rewrite/summary; see the source link for the original. Full installation instructions, the profiles mechanism, and official docs are at buildermethods.com/agent-os; this entry only distills its three-layer architecture and standards extraction/injection workflow into a directly usable prompt, without copying its instruction files verbatim.
[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}}。Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.