STANDARDS AND CONVENTIONS

EXAMPLES Example 1: An agent instructions file. A project places a file at its root with the headings Build, Test, Layout, Conventions, and Pitfalls. Under Build it says: Build command: npm run build. Under Test it says: Testing command: npm test. Under Pitfalls it says: Important: never modify files in the generated folder, because they are produced automatically and your edits will be lost. Any compliant coding agent reads this automatically before starting work, so it builds, tests, and avoids the protected folder without being reminded. Example 2: Documenting pitfalls. A team once lost an afternoon because an agent rewrote date handling using the usual month-first format. Their project actually uses a custom day-month-year format. They add a pitfall line: this project uses DD-MM-YYYY dates, so double-check any date-handling code. The next agent that touches a date function reads the warning first and avoids the mistake. The line cost one sentence to write and saved the team from repeating the problem. Example 3: Competing convention files. A team has developers using three different coding agent products, and each product looks for a differently named file. At first they copy the same content into all three, and within two months the copies disagree about the test command. They fix this by keeping one complete shared file and turning the others into short pointers, or by configuring the tools to read the shared file where supported. Now there is one place to edit, and the agents agree. Example 4: Interoperability. A developer who used one coding agent product for a year decides to try another. Because the project already has a shared instructions file that the new tool also reads, the new agent follows the team's conventions on its first day. The developer does not have to rewrite the project's agent-facing documentation. The shared convention turned a painful migration into a small change.