chatgpt-team
AGENTS.md0 starsChanged 2 months agoMITView on GitHub
This is a public capability-research repository for ChatGPT and Codex engineering workflows. Before adding or changing a claim about ChatGPT or Codex behavior, verify it against current official OpenAI documentation. Prefer developers.openai.com, learn.chatgpt.com, help.openai.com, and official OpenAI GitHub repositories. Do not infer a capability from an API feature when this repository is describing subscription-backed ChatGPT/Codex products. API-only capabilities must be identified as excluded from the primary architecture. Everything in this repository must be safe to publish. Never add project names,…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,700 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository18 other files it gives its agents.
- elixir-docsSkill
- feature-planSkill
- independent-reviewSkill
- multi-repo-changeSkill
- package-readinessSkill
- parallel-deliverySkill
- safe-refactorSkill
- security-reviewSkill
- stack-elixirSkill
- stack-nextjsSkill
- stack-phoenix-liveviewSkill
- stack-rustSkill
- stack-svelteSkill
- systematic-debuggingSkill
- technical-writingSkill
- ui-validationSkill
- unslopSkill
- worktree-integrationSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
13 rules. About 1 is common, 9 are distinctive, and 3 are very specific to this project.
≈1
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 7
Before adding or changing a claim about ChatGPT or Codex behavior, verify it against current official OpenAI documentation.
- Distinctive: line 9
Do not infer a capability from an API feature when this repository is describing subscription-backed ChatGPT/Codex products.
- Common: line 15
Never add project names, organization names, private URLs, credentials, account identifiers, proprietary architecture, business rules, …
- Distinctive: line 23
Keep instructions concise and operational.
- Distinctive: line 24
Prefer explicit validation steps over aspirational wording.
- Distinctive: line 26
Do not hard-code transient model names unless a capability truly depends on one.
- Distinctive: line 27
Do not claim validation that was not performed.
- Very specific: line 28
Keep stack guidance limited to Elixir/Phoenix/LiveView, Rust, Svelte, and optional Next.js unless a contribution has a clear reason to …
- Distinctive: line 36
Verify the relevant OpenAI capability first.
- Distinctive: line 37
Keep the least-privilege default.
- Distinctive: line 38
Check that examples contain no private identifiers.
- Very specific: line 39
Update docs/capabilities.md when a product assumption changes.
- Distinctive: line 40
Prefer one coherent commit per conceptual change.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Repository instructions
This is a public capability-research repository for ChatGPT and Codex engineering workflows.
Authority
Before adding or changing a claim about ChatGPT or Codex behavior, verify it against current official OpenAI documentation. Prefer developers.openai.com, learn.chatgpt.com, help.openai.com, and official OpenAI GitHub repositories.
Do not infer a capability from an API feature when this repository is describing subscription-backed ChatGPT/Codex products. API-only capabilities must be identified as excluded from the primary architecture.
Public-safety rule
Everything in this repository must be safe to publish.
Never add project names, organization names, private URLs, credentials, account identifiers, proprietary architecture, business rules, private schemas, internal prompts, copied private source code, or text copied from private repositories.
Private code may be inspected only to identify general engineering needs. Any material contributed here must be independently written and generalized so that its source cannot be reconstructed.
Keep run-specific research reports, audit findings, repository inventories, experiment logs, and generated evaluation evidence outside version control, even when sanitized. Reusable instructions, tooling, source-backed capability notes, and independently authored fixture inputs may be retained. Never include information that exposes another repository's private contents or identity.
Engineering style
- Keep instructions concise and operational.
- Prefer explicit validation steps over aspirational wording.
- Separate product facts from local conventions.
- Do not hard-code transient model names unless a capability truly depends on one.
- Do not claim validation that was not performed.
- Keep stack guidance limited to Elixir/Phoenix/LiveView, Rust, Svelte, and optional Next.js unless a contribution has a clear reason to extend scope.
Change requirements
For delegated work, use parallel-delivery and its bounded-coordination reference. One coordinator owns the plan; set finite dispatch/correction allowances and deadlines before starting. Keep run records outside Git and verify worker termination before replacement.
For changes to agents, skills, permissions, or workflows:
- Verify the relevant OpenAI capability first.
- Keep the least-privilege default.
- Check that examples contain no private identifiers.
- Update
docs/capabilities.mdwhen a product assumption changes. - Prefer one coherent commit per conceptual change.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.