Conversation
janniklasrose
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
janniklasrose
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
janniklasrose
requested review from
andrewnester,
anton-107,
denik,
pietern,
shreyas-goenka and
simonfaltum
as code owners
janniklasrose
had a problem deploying
to
test-trigger-is
GitHub Actions
Failure
Suggested reviewersBased on git history of the changed files, these people are best suited to review:
Confidence: low Eligible reviewersBased on CODEOWNERS, these people or teams could also review: @andrewnester, @anton-107, @denik, @shreyas-goenka, @simonfaltum Suggestions based on git history of 7 changed files (1 scored). See CODEOWNERS for path-specific ownership rules. |
| - `make docs` | ||
| - Validation generated code: | ||
| - `make generate-validation` | ||
| - Mock files: |
| - `make test-update` | ||
| - `make test-update-templates` (templates only) | ||
| - `make generate-out-test-toml` (only `out.test.toml`) |
There was a problem hiding this comment.
make test-updatemake test-update-templates(templates only)make generate-out-test-toml(onlyout.test.toml)
It looks like additive, but 1st one actually includes two other.
And we need generate-out-test-toml less now as running the tests (even without -update) updates out files automatically.
There was a problem hiding this comment.
will update Makefile and agent guidance in follow-up
| ```go | ||
| package mutator_test | ||
|
|
||
| func TestApplySomeChangeReturnsDiagnostics(t *testing.T) { |
There was a problem hiding this comment.
I believe we can drop or significantly reduce this section this with current models. I don't think models will get it wrong, this is how unit tests are written in go in general.
There was a problem hiding this comment.
+1. follow-up PR - now it's just a cut-paste
|
|
||
| Use table-driven tests when testing multiple similar cases (e.g., different inputs producing different outputs). Reviewers prefer this pattern over repeating near-identical test functions. | ||
|
|
||
| ## Acceptance Tests |
There was a problem hiding this comment.
What's the relationship between this file and acceptance/README.md? Are they complementary or duplicative? Should we reference README.md there and keep only agent-specific things here while general manual in README?
There was a problem hiding this comment.
+1 for mostly maintaining READMEs and referring to them in agent instructions
| description: Checklist to run before submitting a PR | ||
| --- | ||
|
|
||
| Before submitting a PR, run these commands to match what CI checks. CI uses the **full** variants (not the diff-only wrappers), so `make lint` alone is insufficient. |
There was a problem hiding this comment.
make lint is intended to work 99% of the time though, have you seen where it's not?
There was a problem hiding this comment.
This is cut-paste from the old AGENTS.md. But I can take this opportunity to tidy this up
| # 3. Tests (CI runs with both deployment engines) | ||
| make test | ||
|
|
||
| # 4. If you changed bundle config structs or schema-related code: |
There was a problem hiding this comment.
schema-related sounds to general, this is only about jsonschema. (We should probably rename the make target to reflect it).
| description: Checklist to run before submitting a PR | ||
| --- | ||
|
|
||
| Before submitting a PR, run these commands to match what CI checks. CI uses the **full** variants (not the diff-only wrappers), so `make lint` alone is insufficient. |
There was a problem hiding this comment.
This is cut-paste from the old AGENTS.md. But I can take this opportunity to tidy this up
There was a problem hiding this comment.
just dropping it here for now for one that works manually (copy-pasted this into Claude and it corrected missing symlinks and paths), but we can look into automating this on PRs
| - `make test-update` | ||
| - `make test-update-templates` (templates only) | ||
| - `make generate-out-test-toml` (only `out.test.toml`) |
There was a problem hiding this comment.
will update Makefile and agent guidance in follow-up
| ```go | ||
| package mutator_test | ||
|
|
||
| func TestApplySomeChangeReturnsDiagnostics(t *testing.T) { |
There was a problem hiding this comment.
+1. follow-up PR - now it's just a cut-paste
|
|
||
| Use table-driven tests when testing multiple similar cases (e.g., different inputs producing different outputs). Reviewers prefer this pattern over repeating near-identical test functions. | ||
|
|
||
| ## Acceptance Tests |
There was a problem hiding this comment.
+1 for mostly maintaining READMEs and referring to them in agent instructions
parthban-db
left a comment
parthban-db
left a comment
There was a problem hiding this comment.
Thanks @janniklasrose!
4 participants
Changes
Split AGENTS.md into
.agent/rules/*.mdand.agent/skills/*.This is just a cut-paste - follow-up PR to slim down the rules are coming, for now it just helps with intelligent context management.
Why
Allow agents to intelligently manage context. AGENTS.md is always kept in context, whereas .agent/ files can be loaded on demand.
Tests
Claude: Python rule does not pollute context
/memorybefore a task related to Python files:Auto-loaded rule during task &
/memoryafter:Cursor: auto-application of rules
Skills auto-loading
Cursor:
Claude:
