chore: version packages

[github-actions]

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.11.2

Compare with v0.11.1

Patch Changes

• b8b6f32: Fixed reference stubs (.claude/, .agents/, etc.) freezing a stale,
  unpinned npx @taskless/cli invocation into their own frontmatter
  description forever, even on a nightly install whose canonical
  .taskless/skills/taskless/SKILL.md correctly names the pinned
  @taskless/cli-nightly@<version> package. A stub's description is copied
  verbatim from source and, unlike canonical content, is never rewritten for
  the current build target — so any CLI invocation baked into it would go
  stale on the very first release that changed. The invocation is removed from
  the skill and command description fields entirely: the canonical file
  already carries the correct, per-build invocation, and a stub always defers
  to it, so there is no longer a second copy that can drift.

• 2d088fa: info --json now includes install.onboarded, matching the field the
  onboard recipe already instructs agents to read from that command. Before
  this, the field was written to .taskless/taskless.json and enforced by
  onboard's own gate, but omitted from the info --json payload, so an agent
  following the recipe read undefined and re-ran a full discovery pass on a
  project that had already onboarded. A manifest that omits the field now
  reports onboarded: false, matching the strict-equality gate onboard
  itself applies, rather than null or leaving the key out.

• 548f268: init --json now writes only the parseable envelope to stdout. Previously,
  the non-interactive install path (also reached from init --no-interactive --json) unconditionally logged human-readable prose — the "no tools
  detected" fallback notice and the per-target skill/command summary — to
  stdout ahead of the JSON envelope, so taskless init --json | jq . failed
  with a JSON parse error. That prose now goes to stderr, where it stays
  visible to a person watching the terminal without corrupting a machine
  consumer's view of stdout, matching how verify/test and the migration
  notice already behave under --json.

• 54cd0c0: check no longer loses every finding in a run because one file's front
  matter could not be parsed. A Vale front-matter error used to abort the
  entire Vale invocation before any result was written, so results came back
  [] for the whole run regardless of how many other files had findings — and
  [] was indistinguishable from a genuinely clean pass.

  runVale now retries around a file Vale's own error attributes to one of the
  run's targets, excluding it and reporting it as a per-file finding
  (ruleId: "vale-parse-error", severity: "error") instead of failing the
  whole run. Every other file's findings are reported normally. A failure Vale
  does not attribute to a single target file — a malformed rule, a timeout, a
  crash — is unaffected and still fails the run exactly as before.

• 4626c20: Fixed check --json reporting a raw-scope Vale finding's range.start.line
  one line earlier than the flagged text (check --json reports Vale findings 1 line early, or 2 lines early for raw-scope rules #297). A raw pattern is
  conventionally anchored with a leading \n so it can require "start of line"
  against the unparsed document; that \n is part of Vale's reported match, and
  Vale attributes Line to the newline ending the previous line rather than to
  the line the flagged text is actually on. The mapper now counts a match's
  leading newlines and adds them back before converting to the 0-indexed
  CheckResult.range every source uses.

  default-scope findings were not affected: Vale already reports the correct
  1-based line for them, and range.start.line is 0-indexed by design (every
  source in CheckResult.range is — format.ts adds 1 back when it displays,
  and check --json reports Vale findings 1 line early, or 2 lines early for raw-scope rules #297's "off by one" for default-scope rules was this documented
  convention compared against a 1-based file line, not a bug).

Build Info

npx @taskless/cli-nightly@0.11.2-20260908181852x4929ad3

Built from: 4929ad3
Built at: 2026-09-08 18:18:52