Codex AGENTS.md 產生器：把專案規則寫成 Codex 看得懂的指引檔

You are helping me author an `AGENTS.md` file for this repository so that Codex loads consistent project guidance at the start of every session.

Context you already know about how AGENTS.md works (do NOT lecture me on this, just apply it):
- Codex reads AGENTS.md from the git root down to the current directory, concatenated, closest file wins. Keep the root file focused and lean.
- Content should be operational instructions for an agent, not marketing prose. Think "what would I tell a competent new contributor on day one".

Project: {{PROJECT_NAME}}
Primary stack / language: {{STACK}}
What the project does (1-2 lines): {{PROJECT_PURPOSE}}

STEP 1 — Investigate the repo yourself before writing anything. Read package manifests, lockfiles, CI config, existing README, scripts, and any existing AGENTS.md / CLAUDE.md. From the actual files, determine:
- the real install / build / test / lint / typecheck commands (quote them exactly — do not guess)
- the package manager and runtime version in use
- the directory layout and where the important code lives
- existing conventions (formatter, lint rules, commit style, branch naming)

STEP 2 — Ask me at most {{MAX_QUESTIONS}} sharp clarifying questions ONLY about things you genuinely could not determine from the repo (e.g. which test command is the canonical one, what must never be touched, deployment gotchas). Skip anything you already found. If you found everything, say so and skip straight to STEP 3.

STEP 3 — Write `AGENTS.md` at the repo root with these sections, in this order. Omit any section that does not apply rather than padding it:
1. **Project overview** — 2-3 sentences max: what it is, the stack.
2. **Setup & commands** — exact commands to install, run, build, test, lint, typecheck. Use a table or code blocks. These must be copy-pasteable and correct.
3. **Project layout** — a short map of the key directories and what lives where.
4. **Conventions** — code style, naming, formatting/lint rules to follow, language/framework idioms specific to this repo.
5. **Commit & PR rules** — the commit message format ({{COMMIT_STYLE}}), branch naming, and anything required before opening a PR (e.g. tests green, changelog entry).
6. **Guardrails / do-not-touch** — files, dirs, secrets, generated code, or behaviors Codex must not modify without asking. Be specific.
7. **Verification checklist** — the exact steps Codex should run to self-verify a change before declaring it done.

Writing rules:
- Be terse and imperative. Bullet points over paragraphs. No "you are an expert" filler.
- Only state things you actually confirmed from the repo or from my answers. If something is genuinely unknown, leave a clearly-marked `TODO(owner): ...` line instead of inventing a command — a wrong build command is worse than a flagged gap.
- Keep the root file lean; if a subdirectory has materially different rules, tell me to create a nested `AGENTS.md` there instead of bloating the root.

After writing the file, output a 5-line summary of what you put in it and list any `TODO(owner)` gaps I still need to fill in.

把方括號 [ ] 內的變數換成你的內容，丟進 OpenAI Codex。

You are helping me author an `AGENTS.md` file for this repository so that Codex loads consistent project guidance at the start of every session.

Context you already know about how AGENTS.md works (do NOT lecture me on this, just apply it):
- Codex reads AGENTS.md from the git root down to the current directory, concatenated, closest file wins. Keep the root file focused and lean.
- Content should be operational instructions for an agent, not marketing prose. Think "what would I tell a competent new contributor on day one".

Project: {{PROJECT_NAME}}
Primary stack / language: {{STACK}}
What the project does (1-2 lines): {{PROJECT_PURPOSE}}

STEP 1 — Investigate the repo yourself before writing anything. Read package manifests, lockfiles, CI config, existing README, scripts, and any existing AGENTS.md / CLAUDE.md. From the actual files, determine:
- the real install / build / test / lint / typecheck commands (quote them exactly — do not guess)
- the package manager and runtime version in use
- the directory layout and where the important code lives
- existing conventions (formatter, lint rules, commit style, branch naming)

STEP 2 — Ask me at most {{MAX_QUESTIONS}} sharp clarifying questions ONLY about things you genuinely could not determine from the repo (e.g. which test command is the canonical one, what must never be touched, deployment gotchas). Skip anything you already found. If you found everything, say so and skip straight to STEP 3.

STEP 3 — Write `AGENTS.md` at the repo root with these sections, in this order. Omit any section that does not apply rather than padding it:
1. **Project overview** — 2-3 sentences max: what it is, the stack.
2. **Setup & commands** — exact commands to install, run, build, test, lint, typecheck. Use a table or code blocks. These must be copy-pasteable and correct.
3. **Project layout** — a short map of the key directories and what lives where.
4. **Conventions** — code style, naming, formatting/lint rules to follow, language/framework idioms specific to this repo.
5. **Commit & PR rules** — the commit message format ({{COMMIT_STYLE}}), branch naming, and anything required before opening a PR (e.g. tests green, changelog entry).
6. **Guardrails / do-not-touch** — files, dirs, secrets, generated code, or behaviors Codex must not modify without asking. Be specific.
7. **Verification checklist** — the exact steps Codex should run to self-verify a change before declaring it done.

Writing rules:
- Be terse and imperative. Bullet points over paragraphs. No "you are an expert" filler.
- Only state things you actually confirmed from the repo or from my answers. If something is genuinely unknown, leave a clearly-marked `TODO(owner): ...` line instead of inventing a command — a wrong build command is worse than a flagged gap.
- Keep the root file lean; if a subdirectory has materially different rules, tell me to create a nested `AGENTS.md` there instead of bloating the root.

After writing the file, output a 5-line summary of what you put in it and list any `TODO(owner)` gaps I still need to fill in.