Synvael/synvael
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

docs(workspace): require useful comments before committing

Browse source 
Updated the Verify-then-commit loop to mandate that function doc comments and important inline comments are present before any code is committed to the repository.
This commit is contained in:
Serkyo 2026-04-30 12:03:00 +02:00
parent 83dde5a794
commit e20126fea5
2 changed files with 6 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
AGENTS.md
View file

@ -105,8 +105,9 @@ Then follow this loop on every step:
1. **Verify** the user's claimed change is actually present and correct. 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. 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. 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. **Then** tell the user what to do next. 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. 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.

5
CLAUDE.md
View file

@ -105,8 +105,9 @@ Then follow this loop on every step:
1. **Verify** the user's claimed change is actually present and correct. 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. 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. 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. **Then** tell the user what to do next. 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. 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.