Conversation
|
|
||
| ## Code style | ||
| 1. Do not eagerly add `#[derive(...)]` implementations like a `Debug` or `Clone`. Only add them when needed. | ||
| 2. Try to keep line lengths at max 110 characters. |
There was a problem hiding this comment.
better just run cargo fmt after the edit is done
| cargo fmt --all && cargo clippy --workspace | ||
|
|
||
| test: | ||
| cargo test --workspace --no-fail-fast && ./scripts/build.sh --lit |
There was a problem hiding this comment.
I often notice the agent running the tests twice because first it executes and then sees it's too much output to parse and then add a grep command. Let us also add the instructions to the agent on how to execute tests and see the failures in one go, by either piping the result or saving output files or grepping.
| make lint # Run the formatter and linter | ||
| ``` | ||
|
|
||
| Use `make test` when fixing bugs or adding new features, `make lint` before committing changes. |
There was a problem hiding this comment.
I think it makes sense to make it establish baselines before the start to avoid the issues where it thinks there are pre-existing failing tests.
Also I usually start my session with compare this branch to master so that if it's a continuation of an implementation or if it's addressing comments it gathers the context quiker.
| lint: | ||
| cargo fmt --all && cargo clippy --workspace | ||
|
|
||
| test: |
There was a problem hiding this comment.
should we add skills to let the agent test single lit files?
| ``` | ||
|
|
||
| Use `make test` when fixing bugs or adding new features, `make lint` before committing changes. | ||
|
|
There was a problem hiding this comment.
I would add instructions on how to debug in the project
- run cargo r -- --help to see options
- use --ast-lowered and --ast and --ir flags
- use --check flag..
I find myself often repeating these instructions
2 participants
No description provided.