add an AGENTS.md to the project#183
Conversation
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - name: Run cargo fmt | ||
| uses: actions-rs/cargo@v1 |
There was a problem hiding this comment.
This action is deprecated, unmaintained for like 6 years
https://github.com/actions-rs/cargo
There was a problem hiding this comment.
do we need this at all? The GH runners should have all of the rust toolchain already installed
| Shell::Posix => "2>/dev/null", | ||
| Shell::Powershell => "2> $null", | ||
| Shell::CmdExe => "2> NUL" | ||
| Shell::CmdExe => "2> NUL", |
There was a problem hiding this comment.
cargo fmt fixed this
acarl005
requested review from
kevinyang372
and removed request for
alokedesai
This stack of pull requests is managed by Graphite. Learn more about stacking. |
alokedesai
left a comment
alokedesai
left a comment
There was a problem hiding this comment.
Left a bunch of non-blocking comments.
My main question / thought is that I think we need to be more intentional about what goes into a skill and what goes into the top level agents.MD.
The current impl is better than nothing but I still think we have room to get even better results by giving the LLM some basic info about the repo and then a set of skills that have more information that it can read when it actually needs to.
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - name: Run cargo fmt | ||
| uses: actions-rs/cargo@v1 |
There was a problem hiding this comment.
do we need this at all? The GH runners should have all of the rust toolchain already installed
| ## Build and Test Commands | ||
|
|
||
| ```bash | ||
| # Build | ||
| cargo build | ||
|
|
||
| # Run tests | ||
| cargo test --verbose | ||
|
|
||
| # Lint (fmt + clippy) | ||
| cargo fmt -p warp-command-signatures -p warp-completion-metadata | ||
| cargo clippy -p warp-command-signatures -p warp-completion-metadata --all-targets --all-features -- -D warnings | ||
|
|
There was a problem hiding this comment.
I would consider ommitting this or turning it into a skill.
The reason is:
- Building and testing is pretty obvious for the LLM in this repo, there's no reason it needs to get injected in every system prompt
- We probably don't want the LLM to eagerly run fmt and clippy
| cargo clippy -p warp-command-signatures -p warp-completion-metadata --all-targets --all-features -- -D warnings | ||
|
|
||
| # Autogenerate PowerShell cmdlet specs (requires pwsh installed) | ||
| cargo run --bin autogenerate_powershell |
There was a problem hiding this comment.
This seems potentially errorprone, the LLM isn't going to understand what autogenerate powershell even means. Again, seems like a good use case for a skill instead of the top level agents.Md
|
|
||
| For autogenerated specs (currently PowerShell only), hand-written augmentations live in `json/overrides/`. Overrides are matched by option name or argument index and merged at generation time. Only `template` and `generatorName` fields are currently supported for overrides. | ||
|
|
||
| ## Adding a New Command Spec |
There was a problem hiding this comment.
Feels like a skill. I think the AGENTs.MD should be pretty high level and explain the semantics of what our completion system is and how it's inspired by Fig but a lot of the other things in this file (how to create a spec, examples, etc) can go in a skills.
The main advantage is the LLM can take advantage of progressive disclosure so it only reads this information in as needed
| @@ -1,5 +1,5 @@ | |||
| [toolchain] | |||
| channel = "1.82" | |||
| channel = "1.85" | |||
There was a problem hiding this comment.
we use 1.92 in warp-internal, why 1.85 here?
There was a problem hiding this comment.
There are new clippy lints in 1.92 which causes linting to fail. I updated to 1.85 b/c it's recent enough to fix the CI error but before these new lints. I do agree we should upgrade but I wanted to avoid scope-creeping this PR too much.
3 participants
The end goal is to set up this repo with oz to implement new completions specs and maintains existing ones autonomously.
Context: https://warpdev.slack.com/archives/C0A9ZAV8HM2/p1768933993596109
In order to do that, we need oz to one-shot the specs most of the time.
I first tried doing this locally with
timedatectlas a PoC. The agent failed to one-shot it. One example of a failure mode is that it used Fig-specific stuff that we don't have, not realizing our Rust based generator functions. I added stuff to AGENTS.md and attempted that task again and again, iterating on the file until it one-shotted it. This is what I ended up with.FYI CI was failing so I also fixed that. see the failures: https://github.com/warpdotdev/command-signatures/actions/runs/21985263695/job/63517749452