You own the code
The AI writes it. You own it.
If the code is good, that is your work. If it breaks something or deletes data, that is also your work. “The AI did it” is not an answer.
Read every line before you commit it.
Understand the problem first
Do not give an issue to the AI before you understand it yourself.
Read the issue. Find the cause. Know what “fixed” looks like. Then ask the AI.
If you do not understand the problem, you cannot tell if the answer is right.
Understand what it built
When the work is done, you must be able to explain it. If you cannot answer these, you are not finished:
- Which libraries did it use, and why those?
- Where does the data go? Which table, which folder, which bucket?
- Is it automatic or manual? If automatic, what starts it? A schedule, an event, or an interval?
For example, if you add an SQLite backup, you should know if it runs on a schedule or after each write, where the file goes, how long it is kept, and how to restore it.
If you add photo upload, you should know where the photos are stored, what the file names are, and what happens when two people upload the same name.
Keep the codebase clean
Delete the reasoning comments. The AI explains itself in comments. Lines like “we use a Map here for fast lookup” belong in the chat, not in the file. Keep a comment only when it explains why a strange choice was made.
Do not let it rebuild solved problems. The AI will happily write its own date formatter, its own migration runner, or its own retry logic. Use the library the project already has. If the project has none, pick a known one. Do not write your own.
Check that it followed our patterns. New code should look like the code next to it.
Before you integrate anything
Before you add a library, an API, or a service, look at its official documentation for an MCP server or an agent skill.
Most serious projects ship one now. It gives the AI the real, current documentation instead of whatever it remembers, and the difference in output is large.
If there is none, pull the docs with find-docs before you write the code. Never
let the AI work from memory on an API you have not used recently.
The list of what we already have on is on the skills and plugins page.
Protect production data
Read every command before you run it. Stop and check when you see:
DROP,TRUNCATE, orDELETEandUPDATEwith noWHERE- A migration that drops or renames a column
rm -rf, a force push, or a hard reset- Anything pointing at a production database or bucket
If you are not sure what a command does, do not run it. Ask first.
Test it before you say it is done
“The AI said it works” is not testing.
Run it yourself. Try the normal case. Try the broken case. Check that the data really changed. If there are tests, run them.
Run a code review
When you have fixed the issue or finished the feature, run /code-review
before you open the pull request. This is required, not a suggestion.
Install it with /plugin if you do not have it.
It reads your changes and looks for bugs, security holes, and code that does not match the rest of the project. Passing tests only prove that the case you thought of works. The review is what catches the case you did not think of.
For a release, or for anything touching money, login, or customer data, run
/code-review ultra instead. It is slower and much more thorough.
Fix what it finds, or write down why you disagree. Do not ignore it silently.
Examples
The AI wrote a 12-line comment explaining its approach above a function.
Delete it. Keep one line only if it explains why a strange choice was made. The reasoning belongs in the pull request, not in the file.
You asked for date formatting and the AI wrote its own formatDate() with a list of month names.
Reject it. Check what the project already uses and use that. Custom date code breaks on time zones and month ends.
The AI wrote its own migration runner.
Reject it. Use the migration tool the project already has. If there is none, choose a known tool and agree it with your lead.
The AI suggests a migration that drops a column to fix a type error.
Do not run it. Dropping a column deletes data and you cannot get it back.
Ask how to change the type without dropping. If the column really must go, take a backup and agree it with your lead first.
The AI says the photo upload is finished and working.
It is not finished. Upload a photo yourself. Find the file where it was saved. Reload the page and check it still shows. Then try a file that is too big.
You fixed the bug, the tests are green, and you are ready to push.
Run /code-review first. Then push.
Green tests mean the case you thought of works. They say nothing about the case you missed.
You are adding a payment provider you have never used.
Check their official docs for an MCP server or an agent skill before you write anything. Most large providers ship one.
If there is none, run find-docs for the API. Do not let the AI guess at a payments API from memory.
Your lead asks how the nightly backup works and you say the AI set it up.
That is not an answer. You should be able to say what starts it, when it runs, where the file goes, how long it is kept, and how to restore it.
If something here is wrong
If this does not match how we really work, or you think it should change, email support@dawloom.com.