chore: version packages

[github-actions]

Build Info

npx @taskless/cli-nightly@0.13.0-20261016183405x082100b

Built from: 082100b
Committed at: 2026-10-16 18:34:05

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@taskless/cli@0.13.0

Compare with v0.12.0

Minor Changes

• 55b82fe: The /tskl slash command is removed. taskless init no longer installs it, and upgrading removes the copies an earlier install wrote, from .taskless/commands/ and from each tool's commands/tskl/. Other files in a tool's commands/ directory are left alone.

  What to do: ask your agent in plain language instead, such as "set up taskless" or "add taskless to CI". The Taskless skill picks that up the same way /tskl did. The init --json envelope drops commandsInstalled and each target's writtenCommands, and keeps removedCommands, which is where the removal shows up.

• 6c661e9: Breaking: the two rule-checking commands are renamed for the question each one answers.

  0.13	before 0.13	question
  validate	verify	Is the rule well formed? Decided from its files alone.
  verify	test	Does the rule check what you want? Runs validate, then the fixtures.

  What to change:

  • A call to taskless test fails as an unknown command. Call taskless verify. The output is the same.
  • A call to taskless verify still runs, but it now runs the rule's fixtures as well, so it is stricter and slower. For the old quick check, call taskless validate. The JSON envelope is unchanged.
  • A pre-commit hook installed from the hooks recipe runs taskless test and fails after the upgrade until it says taskless verify.
  • The verify-rule agent topic is now validate-rule.
  • The ./schemas export verifyTestOutputSchema is renamed ruleCheckOutputSchema, with no alias. The schema itself is unchanged.
  • @taskless/cli/reference.json moves to version 3. Its shape is unchanged, but enforcedBy now reads "validate" or "verify", so each value names a different command than it did in version 2. The corpus's own version is the signal a consumer should refuse on, not the package version.

  validate also catches more on an ast-grep rule:

  • It has ast-grep load the rule on its own, so a kind the grammar does not have (a keyword such as readonly, a Markdown inline construct such as link) is rejected under that rule's name, in ast-grep's own words. Before, it passed and then broke every sg rule's report in check.
  • A top-level strictness: is rejected under the new constraint sg-no-top-level-strictness. ast-grep ignores the key there, so the pattern stayed narrowed while the rule read as fixed.
  • It reports three silent authoring traps from create-sg-rule as notices, which never fail a rule: $$$ beside a comma, follows/precedes without stopBy: end, and a callee regex that misses awaited generic calls in TypeScript and Tsx.

  verify runs an ast-grep rule's fixtures against a config holding only that rule, so another rule ast-grep refuses no longer fails it under the wrong name.

  Installed skills pin their CLI version, so a project keeps the old names until it upgrades, and the upgrade rewrites the skill with the new ones.

Patch Changes

• ec8ea7a: New taskless agent ok topic: it prints one line confirming the CLI can run, through the invocation it was launched with, and does nothing else. The Taskless skill now runs it once per session before any other Taskless command, so a harness that blocks download-and-run commands (Claude Code's auto mode, for one) stops the agent before it starts work rather than partway through. On a blocked command the agent names the exact command in one message and offers three ways forward: it adds an allow rule for exactly that invocation (handing the user the change when the harness blocks the agent's own edit), the user approves it through their agent's permissions command such as /permissions, or the user approves every Taskless command by hand in chat. It never proposes an allow rule that wildcards the package name or version, and never asks what the user wants while blocked. A request that names no task, such as "let's use taskless", goes straight to onboarding, so its one question is the only one the user sees.

• 7140552: check no longer reports a clean result for paths it never scanned. A path outside the project, existing or not, is refused with INVALID_INPUT and exit 1. A path that does not exist is still skipped with exit 0, so raw git diff --name-only output can still be piped in, but the skipped paths are now named in a notice (notices under --json).

• eaa4061: An agent can now send the Taskless team general feedback (taskless agent feedback) or a bug report (taskless agent bug-report) on the user's behalf, without a GitHub account. Both show the user the exact payload and send only on their explicit yes, and both appear in the taskless agent index. A bug report's version information is filled in by the CLI from local state. The invited rule-authoring survey's recipe is renamed to taskless agent rule-feedback; its questions, invite, and cadence are unchanged. feedback send payloads now carry a required kind (rule, general, or bug). With telemetry disabled, nothing is sent and the CLI points to https://github.com/taskless/cli/issues instead.

• 1339697: The rule-authoring recipes now tell the agent where a rule's test cases should come from. create-sg-rule, create-vale-rule, create-runtime-rule, and improve-rule --anonymous have it copy cases from real code in the repository before inventing any, and name the cases it invented in its report. They also have it read the linters detect --json finds and write cases those linters would accept. Apart from the construct the rule checks, cases stay in the repository's idiom, with no placeholder types such as Record<string, never> and no nesting a reviewer would send back. create-remote-rule and improve-rule apply the same standard to the cases and references they send to the generator. verify is unchanged and does not judge fixture style.

• aceb1b9: Claude Code's auto mode can refuse a Taskless command even when the project allows that exact version, because its classifier overrules project allow rules for downloaded code and reads its own exceptions only from your user settings. The setup wizard (npx @taskless/cli with no arguments) now lists every settings edit together, as aligned ALLOW (project):, REMOVE (project):, and ALLOW (global): statements, each naming the command and the file, under one question, "Make these changes to your settings?", and on yes adds one entry to the top-level autoMode.allow list in ~/.claude/settings.json (or under CLAUDE_CONFIG_DIR). The entry starts Taskless CLI:, names no version, and covers a Taskless call only when it names an exact version; it is added once, after "$defaults" when init creates the list, a later install that finds it leaves it alone, and one that does not offers it again. Only the interactive wizard writes it: the batch init never writes outside the project, and instead warns when the entry is missing, naming the file, the key, and the text to add. init --json reports it under globalTrust. When a classifier does refuse a Taskless command, the skill now tells the agent to stop without retrying and hand you that entry, rather than offering a project allow rule that cannot help.

• 60763fb: The line taskless init prints after a successful install now points only at the Taskless skill: ask your AI tool to onboard with Taskless. It no longer mentions /tskl onboard or a terminal onboard command.

• ff6d75b: Released builds now pin their own version. The installed skill and the agent recipes name npx @taskless/cli@<version> instead of the unpinned npx @taskless/cli or @latest, as nightlies already did, so an agent runs exactly the version the project installed. Commands the CLI prints for you, such as an authentication remedy, are pinned the same way. Upgrading is unchanged: re-run init. Two places stay unpinned: a reference stub's reinstall line, so stubs do not change on every release, and .taskless/README.md, which is written once and read across upgrades.

  init now also reports stale Taskless pins in CI and git-hook files (GitHub Actions, GitLab CI, CircleCI, husky, lefthook, pre-commit, and the rest of the files detect recognizes) by file and line, through the same notice and pinnedCli JSON field as package.json pins. It recommends the version to move to and never edits the file.

  init now also allows exactly the installed CLI in each agent it installs for, so a harness that gates download-and-run commands lets Taskless through without a prompt: Claude Code (.claude/settings.json), Cursor (.cursor/permissions.json and .cursor/cli.json), OpenCode (opencode.json[c]), and Codex (.codex/rules/taskless.rules, when Codex is present). Each rule names one version and cannot match another. Every edit is announced, as Edited <file> with a green ALLOW: line, and the wizard shows it and asks before writing. Each file ends up with exactly one Taskless rule, the installed version's: any other allow rule for @taskless/cli or @taskless/cli-nightly, whatever version it names and however it got there, is removed and shown as a red REMOVE: line. Deny rules and rules for anything else are never touched, and a file that denies the command or does not parse is left alone and reported. init --json carries the same edits under permissions. Agents Taskless does not install into use per-command approval through the skill.

  The setup wizard's tool list now has one .agents/ row, labelled with the detected harnesses that read it, such as OpenCode, Codex, and other .agents harnesses (.agents/), instead of separate Codex and Agent Skills rows. Gemini CLI and Crush are now detected, and install the skill into .agents/.

• bf27a23: taskless report now assumes 15 minutes and $110 an hour per prevented review comment, replacing 4 minutes and $120. The new figures match the example tskl.es publishes: 15 minutes covers reading the change before writing a comment, and $110 is a $210k engineer's hourly base plus a little overhead. Both remain sliders on the published report.

• 100c1e6: Onboarding now mines commit history for fixes that recur, alongside review comments. In a repository reviewed before its pull requests open, or written mostly by agents, the commits are often the only place a rule-shaped pattern shows up. The report recipe states that only review comments count toward surfaced. A fix-up commit, a blame date, or a finding today does not.

  taskless report follows the current tskl.es ReportV1 schema, which prices reviewer time, agent tokens, and dollars on the server. The payload no longer carries projection or a rule's complexity, and the facts file no longer accepts estimates. Each Taskless Cloud candidate in the facts now requires estimatedViolations, the agent's estimate of how many instances of its pattern are in the code today.

• a36bab1: taskless verify (formerly taskless test) now says when an ast-grep rule's files:/ignores: globs match no file in the project. A fixture snippet has no path, so the globs never apply to it, and a rule scoped to lib/** in a project that keeps its code in src/ used to pass taskless test while check never ran it. The rule still passes; the result carries a notice naming the globs, on the human output and in notices under --json. Rules scoped by language: alone are not checked, since a project with no code in that language is honestly clean.

• 7f66001: taskless agent create-sg-rule now collects its ast-grep authoring traps into one Quirks section, and the recipe moves to topic v7. Each entry gives the symptom (a config error that aborts the scan, or a rule that silently matches nothing), a minimal repro, and the workaround, and the table says which ones validate reports. Two new entries: a keyword such as readonly is not a valid kind (read kinds from --debug-query=ast, not the CST dump), and in TypeScript and Tsx await f<T>(...) parses as a call of the await expression, so a rule keyed on the callee silently skips every awaited generic call. Both workarounds cover the common shapes (private readonly x, optional and decorated parameters, method callees) and pass verify.

• c50b899: taskless detect --json now reports ast-grep and Vale configurations as linters (Taskless's own configuration under .taskless/ excluded), the command-line tools on the host's PATH (gh, git, jq, and now glab for GitLab repositories) under hostTools, and an agent section of commands an agent may choose to run to check whether a source is usable, such as gh auth status. Detection still runs nothing and stays offline. taskless info lists glab among its tools too.

  New taskless report publishes an unlisted Taskless report to tskl.es: a page showing the rules in this repository, what they find in the code today, and how often review raised each one's pattern. The CLI counts what the rules find itself, by running the same scan as check --anonymous, and an agent cannot supply or change those numbers. When the CLI could not run every rule (a rule written into another linter, a runtime rule, or a scan that failed), it publishes no counts rather than a partial total. With no flags it prints a draft of what the CLI knows, including those counts, and the facts an agent still has to supply; --from <facts.json> checks there are at least three working Taskless rules, withholds any fixture that looks like it holds a secret or contact detail, validates against the tskl.es schema, publishes, and records the report in .taskless/reports/ (gitignored, since each record holds the URL that deletes it); --delete <record> takes a report down. Every rule on the page carries the agent's one- or two-sentence explanation of why it is worth holding in this codebase, screened like the titles. The new report agent topic walks an agent through it. Migration 11 creates .taskless/reports/.

  Onboarding now asks one question, "Do you want me to set up Taskless for you?", and does the rest: it mines every source it can reach, writes every rule the repository can enforce locally (always logged out), marks onboarding complete, publishes a report, sends Taskless onboarding feedback, and ends by strongly encouraging running the rules in CI. It asks anything else only when it cannot find enough rules for a report. GitLab merge requests are mined through glab the way GitHub pull requests are through gh.