DEV Community

Nic Flemmer
Nic Flemmer

Posted on

Let the agent work out your test command once, then write it down

An agent can read a repo and work out how it checks itself: usually a typecheck, the tests and a linter, taken from the package scripts. It's good at that. It's a poor thing to depend on every time you want to merge.

So in the app I'm building, Styx, the agent does it once. The first time you land a task in a project whose checks aren't known, the task's agent gets a turn to work out the command, run it until it passes, and report it back through a remember_command tool. After that the same command runs before every landing, with no agent involved.

The answer is saved in the project's .styx/project.json as checks.command, not in some hidden app state. That matters for three reasons. A person can read it and see what 'passing' means here. Everyone on the project shares it. And if it's wrong, you fix it by editing one line, or clear it and the next landing asks the agent again.

One guard: a command that looks like it carries a secret is refused, because that file is committed.

When it doesn't apply: if the agent can't work the command out, the landing goes ahead without checks and says so ('no checks ran: none are known for this project'), rather than blocking you. And the stored command goes stale the day someone renames a script, so treat it like any other config.

The general version: let the agent discover, then write the result somewhere a human can read and edit. Do you cache what your agents work out, or let them rediscover it each time?

Top comments (0)