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

docs(workspace): include Lua linting/formatting in agent guidelines

Browse source
This commit is contained in:
Serkyo 2026-05-12 18:57:47 +02:00
parent d30834e14f
commit 28a6b63611
2 changed files with 12 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
AGENTS.md
View file

@ -105,9 +105,10 @@ 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, **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 follow the documention style specified in the relevant section below. 3. Once correct, **run the linter and formatter** (`cargo clippy --all-targets`, `cargo fmt --all`, `selene .`, and `stylua .`) to ensure no regressions or style issues were introduced.
4. After comments are verified, **create a git commit** capturing that step (following the commit conventions above) before moving on. 4. **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 follow the documention style specified in the relevant section below.
5. **Then** tell the user what to do next. 5. After comments and lints are verified, **create a git commit** capturing that step (following the commit conventions above) before moving on.
6. **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.
@ -226,4 +227,6 @@ cargo test -p renderer it_works # run a single test by name
cargo check -p <crate> # fast type-check one crate cargo check -p <crate> # fast type-check one crate
cargo clippy --all-targets cargo clippy --all-targets
cargo fmt cargo fmt
selene .
stylua .
``` ```

9
CLAUDE.md
View file

@ -105,9 +105,10 @@ 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, **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 follow the documention style specified in the relevant section below. 3. Once correct, **run the linter and formatter** (`cargo clippy --all-targets`, `cargo fmt --all`, `selene .`, and `stylua .`) to ensure no regressions or style issues were introduced.
4. After comments are verified, **create a git commit** capturing that step (following the commit conventions above) before moving on. 4. **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 follow the documention style specified in the relevant section below.
5. **Then** tell the user what to do next. 5. After comments and lints are verified, **create a git commit** capturing that step (following the commit conventions above) before moving on.
6. **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.
@ -226,4 +227,6 @@ cargo test -p renderer it_works # run a single test by name
cargo check -p <crate> # fast type-check one crate cargo check -p <crate> # fast type-check one crate
cargo clippy --all-targets cargo clippy --all-targets
cargo fmt cargo fmt
selene .
stylua .
``` ```