Taskless

Awesome to hear! Looking forward to the cloud layer, so the enforcement can be guaranteed from a trust space outside of your repo as well!

Thank you Luis! I think there's still a lot of work to do in this space, but I can't imagine trying to get agentic code out the door now without a took like this.

Both. Rules are plain files in `.taskless/rules/`, committed with your code. When a convention changes, edit the rule by hand or have your agent improve it using the new correction as the example, and its fixtures rerun to prove the new version. Commits that already passed stay passed: `check` only looks at current files, and in CI only the files a PR touches. Old code that breaks the new rule shows up when someone next edits it, or run `taskless check` on the whole repo once to get the full list.

Both are fine. The rule is that ordinary files under `.taskless/rules/` are submitted together with the code. If the convention changes, you can manually modify it, or let the agent use the new correction record as an example to improve; the rule's built-in positive and negative examples will be re-run to verify the new version. Historical submissions that have already passed are not affected: `check` only checks the current files, and CI only checks the files changed in the PR. Old code that does not meet the new rules will be reported the next time someone modifies it, and you can also run `taskless check` across the entire repository to get a complete list.

Yes for the output, partly for tokens. For the output: `taskless check` has no model in it, so the same code against the same rules gives the same result on every run, for every customer. For tokens: Taskless doesn't make the model deterministic, so it can't promise the same token count. What it does is make the fix loop short and predictable. A failing rule gives the agent the file, the line and the exact message, so it fixes the thing in one pass instead of an LLM reviewer reading the whole diff and guessing. The more of your standards live in rules, the less of each run is spent on a model checking another model.

Thank you, this made my night. The crossOrigin one is the kind of rule nobody writes until it breaks every imported episode, and then it goes in the agent docs and comes back a week later anyway. That's the loop I wanted to close. I love that the report turned up the old `prisma migrate` docs too, since that kind of drift only shows up when everything's already going wrong. If you point your agent at those 34, I'd like to hear whether it cleared them in one pass.

The Taskless skill helps an agent check three things: does the correction keep coming up, does it matter when it's missed, and can you write a failing example of it? Onboarding ranks candidates on that frequency, severity, and how easy it is to enforce. If it looks like a one-off, we drop it to make sure your first rules do as much good as they can. Something that came up twice but takes prod down, like a missing tenant filter on a query, is worth a rule because a reviewer only has to miss it once. Those usually show up as PR review comments. (DevHunt only lets us do single line replies, so I'll add other bullets as replies)

On cost, a rule that never matches is cheap. ast-grep and Vale rules are pattern matches over the files you pass in, and in CI that's only the files the PR changed. Runtime rules only run their check when their capture pattern matches something, so a rare one mostly sits idle. IMO the bigger cost of a rule is a false positive that people learn to ignore, which is why every rule ships with fixtures and onboarding would rather write three rules than ten. Finally, on the time-side, I'd strongly recommend running this on diffs or via lint-staged so that you're only checking the changed files and not the whole repo.

The model writes the rule once. After that taskless check runs ast-grep, Vale and your runtime checks with no model involved, so the same code gives the same result every run. If you want a rule changed, you change the file or ask your agent to improve it, and the fixtures prove the new version.

Why not just ask Claude/Cursor to write me a custom ESLint rule?

You can, and if you already know the rule, that works! Taskless is mostly about knowing which rules to write. It also ships every rule with passing and failing fixtures and checks them, so you find out whether the rule is right before it's in CI. And when your agent writes a rule through Taskless, it follows the same routing, so it lands in ESLint when ESLint can express it. No reason to break a good thing!

Each generated rule includes its own pass/fail fixtures so you can see exactly what it checks before it runs on your code, ensuring it doesn’t produce false positives. The human in the loop part is super important! If the fixtures look wrong, then you change the fixtures. They're the real source of truth!

It runs a detect script first to see which linters you have, and prefers turning on a rule your linter already ships before writing anything new. Onboarding also filters out formatting your linter already handles. There's no automatic dedup against every rule in your config yet, so if you spot an overlap, delete the Taskless one with taskless' `rule delete <id>` skill.