diff --git a/AGENTS.md b/AGENTS.md
index 4d4787b..edeca8d 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -105,8 +105,9 @@ Then follow this loop on every step:
 
 1. **Verify** the user's claimed change is actually present and correct.
 2. If wrong or incomplete, explain what's off and let them fix it — do not silently patch it yourself.
-3. Once correct, **create a git commit** capturing that step (following the commit conventions above) before moving on.
-4. **Then** tell the user what to do next.
+3. Once correct, **ensure useful comments are added** before committing. This includes function doc comments (`///`) and inline comments above important parts of the logic. If they are missing, add them yourself and try to follow the style of the existing comments in the codebase.
+4. After comments are verified, **create a git commit** capturing that step (following the commit conventions above) before moving on.
+5. **Then** tell the user what to do next.
 
 Each verified step gets its own commit. This keeps history aligned with the teaching cadence: every commit corresponds to a concept the user has actually understood and produced working code for. Do not batch multiple verified steps into one commit, and do not move on to the next instruction without committing the previous one.
 
diff --git a/CLAUDE.md b/CLAUDE.md
index 0c4199e..15d3cef 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -105,8 +105,9 @@ Then follow this loop on every step:
 
 1. **Verify** the user's claimed change is actually present and correct.
 2. If wrong or incomplete, explain what's off and let them fix it — do not silently patch it yourself.
-3. Once correct, **create a git commit** capturing that step (following the commit conventions above) before moving on.
-4. **Then** tell the user what to do next.
+3. Once correct, **ensure useful comments are added** before committing. This includes function doc comments (`///`) and inline comments above important parts of the logic. If they are missing, add them yourself and try to follow the style of the existing comments in the codebase.
+4. After comments are verified, **create a git commit** capturing that step (following the commit conventions above) before moving on.
+5. **Then** tell the user what to do next.
 
 Each verified step gets its own commit. This keeps history aligned with the teaching cadence: every commit corresponds to a concept the user has actually understood and produced working code for. Do not batch multiple verified steps into one commit, and do not move on to the next instruction without committing the previous one.