讓 Claude Code 掃描你的 repo,產出一份精煉、可驗證、200 行內的 CLAUDE.md 專案記憶檔——含 build/test/lint 指令、目錄結構、慣例、禁止事項,並把不該塞進來的東西改放到 skills 或 path-scoped rules。
不用離開網站,直接看這組 prompt 跑出來長怎樣(AI 即時生成,扣 1 點)。
不只複製貼上 — 下載後放到 ~/.claude/skills/claude-md-architect/SKILL.md,之後每個 session 自動可用(觸發時自動載入)。
mkdir -p ~/.claude/skills/claude-md-architect && mv ~/Downloads/SKILL.md ~/.claude/skills/claude-md-architect/SKILL.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.claude\skills\claude-md-architect" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\SKILL.md" "$env:USERPROFILE\.claude\skills\claude-md-architect\SKILL.md"【何時用】導入 Claude Code 到一個既有 repo 的第一件事,或你發現每次開新 session 都在重講同樣的 build 指令/目錄/禁區時。【為何有效】(1) 它逼模型先「掃 repo 找真實指令」再下筆,避免它憑記憶寫 npm test 結果你專案是 pnpm;(2) 三段式 DISCOVER→TRIAGE→WRITE 把『該進 CLAUDE.md vs 該進 rules/ vs 該進 skill』分清楚,這正是官方建議——CLAUDE.md 只放每次都要的事實,多步驟流程放 skill,只對某類檔案生效的規則放 .claude/rules/ 並用 paths frontmatter 限定;(3) 強制 200 行上限與『每條都可驗證』,因為 CLAUDE.md 越長、adherence 越差。【技巧】跑完先別急著用,翻一遍 Do NOT 段落確認它沒幻想出不存在的禁區;之後可隨時用 /init 做互動式重整、用 /memory 確認檔案有被載入。若已有 AGENTS.md,prompt 會自動改用 @AGENTS.md import 而非重複寫一份。
# CLAUDE.md — LUVAI 股票分析後端 ## Commands - Install: `pnpm install` - Dev: `pnpm dev` - Typecheck (run before declaring done): `pnpm tsc --noEmit` - Test: `pnpm vitest run` # CI uses this exact command - Deploy: `pnpm run deploy` # wrangler; ask before running ## Project layout - `src/routes/` — API route handlers - `src/lib/` — shared logic (credits, entitlements) - `migrations/` — D1 SQL, append-only, numbered ## Do NOT - Never edit files under `.open-next/` (generated) - Never run a migration without confirming with the user first - Never use `POWER()` in D1 SQL — use `EXP(LN(x)*y)` ## Workflow 1. Make the change 2. `pnpm tsc --noEmit` must pass 3. Summarize what changed before committing --- not placed in CLAUDE.md --- - Multi-step deploy verification → move to .claude/skills/deploy/ - API input-validation rules → .claude/rules/api.md (paths: src/routes/**)
以上為此 Prompt 丟進 Claude Code 後可得到的描述性成果,實際畫面會因填入的變數而有差異。
[PROJECT_NAME]專案名稱,例如「LUVAI 股票分析後端」或「行銷官網」
[STACK]主要技術棧,例如「Next.js 15 + TypeScript + Cloudflare Workers」或「Python FastAPI」
[PACKAGE_MANAGER]套件管理器/執行器,例如 pnpm、npm、uv、poetry、cargo、go
[KNOWN_PITFALLS](可選)你已知 Claude 在這專案常踩的雷,例如「會用 npm 但專案是 pnpm」「會亂改 migrations」;沒有就留白
填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
You are setting up the project memory file (CLAUDE.md) for this repository so that every future Claude Code session starts already knowing how to work here. CLAUDE.md is loaded into context at the start of every session, so it is a behavioral contract, not documentation — every line must change how the agent acts.
Project: {{PROJECT_NAME}}
Primary language / stack: {{STACK}}
Package manager / runtime: {{PACKAGE_MANAGER}}
Things you already know Claude tends to get wrong here (optional): {{KNOWN_PITFALLS}}
Work in these phases. Do NOT write the file until Phase 3.
PHASE 1 — DISCOVER (read-only, no edits)
1. Detect the real build/test/lint/format/typecheck commands. Read package.json scripts, Makefile, justfile, pyproject.toml, Cargo.toml, go.mod, composer.json, or CI config — whichever exist. Record the EXACT command string (e.g. `pnpm vitest run`, not `npm test`). If multiple are plausible, note which one CI actually runs.
2. Map the directory layout: where source, tests, config, and entry points live. Note any non-obvious folders (generated code, vendored deps).
3. Detect conventions that are decisions, not defaults: indentation, import style, error-handling pattern, naming, how new modules/endpoints/components are added.
4. Detect an existing AGENTS.md, .cursorrules, .windsurfrules, or CLAUDE.md. If a CLAUDE.md already exists, you will IMPROVE it, not overwrite it.
PHASE 2 — TRIAGE (decide what belongs where)
For each candidate instruction, classify it:
- BELONGS IN CLAUDE.md: a fact true in every session — build commands, layout, "always do X" rules, hard prohibitions.
- BELONGS IN A path-scoped rule (.claude/rules/<topic>.md with a `paths:` frontmatter glob): only matters for one file type or subtree (e.g. API-handler rules, test rules).
- BELONGS IN A SKILL (.claude/skills/): a multi-step procedure (deploy, release, migration), not a fact.
State the triage table before writing anything. Reject anything that could be copy-pasted into any random repo unchanged — generic advice wastes context and lowers adherence.
PHASE 3 — WRITE
Write (or, if one exists, propose a diff to) `./CLAUDE.md` with this structure and these rules:
- Target UNDER 200 lines. Shorter = better adherence. If it grows past that, push detail into rules/ or skills/ and reference them.
- Use markdown headers + bullets, not paragraphs.
- Every instruction must be concrete and verifiable: "Run `{{PACKAGE_MANAGER}} test` before committing" not "test your changes"; "API handlers live in src/api/handlers/" not "keep files organized".
- Sections to include (drop any that don't apply, don't pad):
## Commands — the exact build / test / lint / typecheck / dev / format commands. This is the single most valuable section.
## Project layout — where things live, one line each.
## Conventions — only real team decisions (style, patterns, naming).
## Do NOT — explicit prohibitions (e.g. never edit generated files, never commit to main, never bump deps without asking). Be specific about paths.
## Workflow — required steps Claude must follow (e.g. run typecheck before declaring done).
- If an AGENTS.md exists, do not duplicate it: start CLAUDE.md with `@AGENTS.md` to import it, then add only Claude-specific lines below.
- Do not invent commands, paths, or conventions. If you cannot verify a command actually works, mark it `# unverified — confirm` rather than guessing.
- Use a block-level HTML comment `<!-- ... -->` for any note meant for human maintainers (it is stripped from Claude's context).
AFTER WRITING
- List which items you deliberately did NOT put in CLAUDE.md and where they should go instead (rules/ or skills/), so the human can follow up.
- Note that they can run `/memory` to confirm the file is being loaded, and `/init` for an interactive re-pass later.
- Remind them: CLAUDE.md is guidance the model tries to follow, not hard enforcement. Anything that MUST happen at a fixed moment (e.g. lint on every save) should be a hook instead.這組 prompt 專為 Claude Code 設計。把 prompt 內 4 個方括號 [變數] 換成你自己的內容,貼進 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/claude-code-claude-md-architect" width="100%" height="380" frameborder="0" style="border:1px solid #e0dcd0;border-radius:4px;" loading="lazy" title="PromptCraft Embed"></iframe>
You are setting up the project memory file (CLAUDE.md) for this repository so that every future Claude Code session starts already knowing how to work here. CLAUDE.md is loaded into context at the start of every session, so it is a behavioral contract, not documentation — every line must change how the agent acts.
Project: {{PROJECT_NAME}}
Primary language / stack: {{STACK}}
Package manager / runtime: {{PACKAGE_MANAGER}}
Things you already know Claude tends to get wrong here (optional): {{KNOWN_PITFALLS}}
Work in these phases. Do NOT write the file until Phase 3.
PHASE 1 — DISCOVER (read-only, no edits)
1. Detect the real build/test/lint/format/typecheck commands. Read package.json scripts, Makefile, justfile, pyproject.toml, Cargo.toml, go.mod, composer.json, or CI config — whichever exist. Record the EXACT command string (e.g. `pnpm vitest run`, not `npm test`). If multiple are plausible, note which one CI actually runs.
2. Map the directory layout: where source, tests, config, and entry points live. Note any non-obvious folders (generated code, vendored deps).
3. Detect conventions that are decisions, not defaults: indentation, import style, error-handling pattern, naming, how new modules/endpoints/components are added.
4. Detect an existing AGENTS.md, .cursorrules, .windsurfrules, or CLAUDE.md. If a CLAUDE.md already exists, you will IMPROVE it, not overwrite it.
PHASE 2 — TRIAGE (decide what belongs where)
For each candidate instruction, classify it:
- BELONGS IN CLAUDE.md: a fact true in every session — build commands, layout, "always do X" rules, hard prohibitions.
- BELONGS IN A path-scoped rule (.claude/rules/<topic>.md with a `paths:` frontmatter glob): only matters for one file type or subtree (e.g. API-handler rules, test rules).
- BELONGS IN A SKILL (.claude/skills/): a multi-step procedure (deploy, release, migration), not a fact.
State the triage table before writing anything. Reject anything that could be copy-pasted into any random repo unchanged — generic advice wastes context and lowers adherence.
PHASE 3 — WRITE
Write (or, if one exists, propose a diff to) `./CLAUDE.md` with this structure and these rules:
- Target UNDER 200 lines. Shorter = better adherence. If it grows past that, push detail into rules/ or skills/ and reference them.
- Use markdown headers + bullets, not paragraphs.
- Every instruction must be concrete and verifiable: "Run `{{PACKAGE_MANAGER}} test` before committing" not "test your changes"; "API handlers live in src/api/handlers/" not "keep files organized".
- Sections to include (drop any that don't apply, don't pad):
## Commands — the exact build / test / lint / typecheck / dev / format commands. This is the single most valuable section.
## Project layout — where things live, one line each.
## Conventions — only real team decisions (style, patterns, naming).
## Do NOT — explicit prohibitions (e.g. never edit generated files, never commit to main, never bump deps without asking). Be specific about paths.
## Workflow — required steps Claude must follow (e.g. run typecheck before declaring done).
- If an AGENTS.md exists, do not duplicate it: start CLAUDE.md with `@AGENTS.md` to import it, then add only Claude-specific lines below.
- Do not invent commands, paths, or conventions. If you cannot verify a command actually works, mark it `# unverified — confirm` rather than guessing.
- Use a block-level HTML comment `<!-- ... -->` for any note meant for human maintainers (it is stripped from Claude's context).
AFTER WRITING
- List which items you deliberately did NOT put in CLAUDE.md and where they should go instead (rules/ or skills/), so the human can follow up.
- Note that they can run `/memory` to confirm the file is being loaded, and `/init` for an interactive re-pass later.
- Remind them: CLAUDE.md is guidance the model tries to follow, not hard enforcement. Anything that MUST happen at a fixed moment (e.g. lint on every save) should be a hook instead.把方括號 [ ] 內的變數換成你的內容,丟進 Claude Code。
六個月在 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」。