Governance rules for coding agents
For one person letting agents change real code: at the end every agent reads the same rules, and a program checks the rules instead of memory.
- Skill areas
- Updated
- ·
Before you start
-
A repository with a check that runs locally: tests, types and the build.
-
A task queue in which every change is recorded before the code.
-
Recorded decisions: what was decided, when, and who may change it.
Steps
Write one entry file and a reading order
One file at the root of the repository is what every agent reads first. It names what to read next: the document that routes the whole repository, one task-specific instruction and then the current code and tests. The documentation folder is not read whole.
Say who outranks the documents
Documents, decisions and tests describe the situation; the person's current instruction comes first. The rule is written out so that an agent neither treats an old plan as final nor drops a rule on its own.
Write the safety limits that hold in every task
The working tree is never reset, restored or cleaned automatically. Infrastructure names are frozen. Production is written through one path, and scripts that change data are dry runs by default. Generated files are never edited by hand. Each limit names what it protects.
Make every change a task
A task is created and claimed before files change, its status follows the work, and the validation that was run is recorded on it. The commit message ends with the task's id.
Name the validation per class of change
A minimum check always runs; on top of it come the gates of the area, such as type, format, route and data checks. The commands are written down so that an agent runs them without asking.
Write what the product may claim
The interface shows only the facts the data supports, and the content claims only what has a source. The rule lives in the check, so a claim without a source fails at the gate, not in review.
Fix a found fault as part of the task
When an implementation, a test run or a review exposes a fault, it belongs to the task under way and is fixed before continuing whenever it fits. A fault that does not fit gets its own task at once.
When not to use this
-
A one-off script that will not be maintained: the rules cost more than they protect.
-
A rule no program checks: it is a wish, not a rule. Build the check or leave the rule out.
-
A team that already has a working contributor guide: add the agent's reading order to it instead of writing a second one.
Where it comes from
The rules are the ones the Hintapiste.fi and this site's repositories direct agents with: an entry file, a reading order, safety limits, a task for every change and a gate before the merge. The gates guide covers the route a task then takes.