Codex AGENTS.md Generator: Turn Project Rules into an Instruction File Codex Understands
Have the agent interview you about your project, then produce a structured, no-fluff AGENTS.md that spells out build/test commands, code style, commit conventions, and off-limits areas in one shot — auto-loaded every time work starts.
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 ~/.codex/prompts/agents-md-author.md then invoke it with /agents-md-author.
mkdir -p ~/.codex/prompts && mv ~/Downloads/agents-md-author.md ~/.codex/prompts/agents-md-author.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.codex\prompts" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\agents-md-author.md" "$env:USERPROFILE\.codex\prompts\agents-md-author.md"When to use it: right after you've hooked Codex up to an existing repo, or when a team wants to standardize 'what Codex should know before it starts working.' Why it works: on every startup Codex concatenates every AGENTS.md from the git root down to the current directory into its system instructions — this prompt forces it to 'read your repo before writing anything' instead of hallucinating a pretty-but-wrong config file, since a wrong build command is worse than no file at all. Techniques: (1) have it investigate package.json / CI / lockfiles for the real commands first, then only ask you about what it couldn't find, saving round trips; (2) require it to leave a TODO(owner) for uncertain commands rather than making one up, in line with 'honesty over polish'; (3) writing the commit format into AGENTS.md is one of the most effective moves (it's the primary thing Codex bases its commit style on). Advanced: when subdirectories have different rules, have it build nested AGENTS.md files and keep the root one lean (default cap is roughly 32 KiB).
# AGENTS.md ## Project overview luvai-stock-app — a Taiwan-equities analytics site (technical + institutional flow + AI). Next.js 15 (App Router) + TypeScript, deployed to Cloudflare Workers via OpenNext, data in D1. ## Setup & commands | Task | Command | |------|---------| | Install | `npm ci` | | Dev | `npm run dev` | | Build | `npm run build` | | Typecheck | `npx tsc --noEmit` | | Lint | `npm run lint` | | Deploy | `npm run deploy` | ## Commit & PR rules - Conventional Commits: `feat(scope): ...`, `fix(scope): ...`, `chore: ...`. - Before opening a PR: `npx tsc --noEmit` and `npm run lint` must pass. ## Guardrails / do-not-touch - Never edit `migrations/` files that are already applied to prod — add a new one. - Do not touch credit/entitlement logic in `lib/entitlements.ts` without asking. TODO(owner): confirm whether `npm test` or `npm run test:ci` is the canonical suite — both exist in package.json.
[PROJECT_NAME]專案名稱,例如 luvai-stock-app
[STACK]主要技術棧/語言,例如 Next.js 15 + TypeScript on Cloudflare Workers
[PROJECT_PURPOSE]專案一兩句話用途,例如 台股技術+籌碼+AI 分析網站
[MAX_QUESTIONS]允許 Codex 反問的最多題數,建議 3-5,避免它一直問
[COMMIT_STYLE]你要的 commit 格式,例如 Conventional Commits(feat/fix/chore…)或團隊自訂格式
填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
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.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.