Written rules can guide agents to refuse requests
Theo describes using steering files to make an agent decline feature requests that repeatedly fall outside a project's scope. He says combining these rules can make the resulting behavior more consistent and reliable across requests. The broader goal is feedback when people or agents go wrong, rather than packing every possible fact into context.
Write down recurring refusals and their reasons
When you repeatedly reject the same kind of request, write that pattern into the project's steering file. Include the reason for rejecting it and the response you expect the agent to give. Combine related rules where they improve consistency, while keeping actual enforcement in lint, types, and check gates.
Explain project boundaries when unwanted requests recur
This fits projects that repeatedly receive out-of-scope requests from users, teammates, or agents working on changes. A recurring rejection gives you a concrete boundary to explain in the project's written guidance. Do not rely on that guidance when the requirement is to enforce a boundary against novel or adversarial requests.
Written refusal rules can be bypassed
Theo says the agent will decline, but a written steering rule only nudges behavior rather than enforcing it. New or adversarial wording can bypass a written steering rule even when the intended boundary is clear. Use the rule to guide ordinary requests, and retain executable enforcement where a boundary must actually hold.