build-the-gate-before-the-content
A check added after the thing it guards is a check somebody switches off to ship. Wire it shut while there is nothing to block.
Conferred by a reviewer who read the card, not claimed by the file about itself. A card the agent distils during a run that consumed untrusted content is born tainted and is held for review before it is ever retrieved.
When it comes to mind
- planning a migration
- starting a new surface
- we will add the lint later
- ordering the work
Avoid and Check are where the value usually is. Do is the section everybody writes.
Trigger
You are about to build something that will need a rule enforced across it — a style constraint, a freshness check, a schema, a link validator, a budget. The natural order is to build the thing and add the check once there is something to check.
It does not apply to a check you are adding to code that already exists; that is a different and harder job, and the answer there is a ratchet, not a wall.
Do
- Add the check in the first commit, before there is any content for it to fail on. It passes trivially, which is the point: it starts life green.
- Give it a failure message that says what to run. A gate whose output is
assert Falsegets deleted by the next person who hits it at 2am. - Write the check so it fails on the first violation, not the hundredth. Ratchets are for legacy; greenfield starts at zero.
- When the check does fire, fix the content. Every time you change the check instead, note in the commit message which case forced it.
Avoid
"We will turn this on once the pages are written." By then the check has a backlog, turning it on
means a day of unrelated fixes, and the cheapest path is a skip list that never shrinks.
Avoid also loosening a gate in the same commit as the feature that tripped it. The loosening is invisible in a large diff, and it is the exact moment a gate stops being one — so it belongs in its own commit with its own explanation.
Check
Introduce a violation on purpose and confirm the build goes red — then remove it. Do this on the day you write the gate, not later.
A gate nobody has watched fail is not a gate; it is a file that claims to be one.
Risk
A gate written before the content encodes an assumption about content that does not exist yet, and some of those assumptions turn out wrong. Expect to narrow it once or twice early on.
That narrowing is the dangerous moment. Each one makes the rule weaker, and a rule narrowed three times without anybody noticing is a rule that no longer covers the case it was written for. Pin every narrowing with the failing example that caused it.
Use it
The card is data. Clone the repository and import it by path — anything that arrives over the network is treated as tainted and held for approval, which is the behaviour you want and the reason there is no one-line installer here.
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/build-the-gate-before-the-content/SKILL.mdIntegrity
SHA-256 of the file as published. An importer can check that what it received is what this page showed.
e5e6f40afb2b2a2becc776d7f6bf2ed78cc40d7333de4b4cb201d52dc48a0dc5