chore: version packages

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "taskless",
   "description": "Taskless skills for code quality rules, authentication, and project management",
-  "version": "0.11.1",
+  "version": "0.11.2",
   "author": {
     "name": "Taskless"
   },

package.json

@@ -1,7 +1,7 @@
 {
   "private": true,
   "name": "@taskless/skills",
-  "version": "0.11.1",
+  "version": "0.11.2",
   "license": "MIT",
   "repository": "taskless/cli.git",
   "scripts": {

packages/cli/CHANGELOG.md

@@ -1,5 +1,91 @@
 # @taskless/cli
 
+## 0.11.2
+
+[Compare with v0.11.1](https://github.com/taskless/cli/compare/v0.11.1...v0.11.2)
+
+### 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.
+
+- 3cfbe5b: `rule create --json` and `rule improve --json` now emit the standard `{ ok:
+false, code, message }` envelope on stdout when a file-set rule arrives with
+  a stray `tests` field, instead of throwing a bare, unreported `CLIError`.
+  Previously the guard threw from inside the command's own `try` without going
+  through the command's `fail()` helper, so under `--json` nothing was written
+  to stdout at all — prose landed on stderr and the process exited 1,
+  indistinguishable from a crash, and the `RULE_GENERATION_FAILED` code the
+  `create-remote-rule` recipe documents as a branch target was never actually
+  reachable for this guard. Both call sites now route through `fail()`, and the
+  duplicated guard itself was consolidated into one shared check so the two
+  copies cannot drift again silently.
+
+  Not addressed here: rules written to disk earlier in the same delivery loop
+  (before the guard fires) are still not named in the failure envelope. The
+  published envelope shape (`CLIErrorEnvelope`) has no field for a partial file
+  list, and adding one is a schema change out of scope for this fix.
+
+- b6668ea: Corrected the published `@taskless/cli/schemas` docstrings for
+  `verifyOutputSchema` and `valeVerifyOutputSchema`, which named a command form
+  — `taskless rule verify <id> --json` — that was removed when rule addressing
+  moved from id to path. No runtime behavior changes; the schemas themselves
+  are unchanged. A consumer reading these docstrings (e.g. via editor
+  tooltips or generated docs) would previously be pointed at a command that
+  does not exist.
+- 4626c20: Fixed `check --json` reporting a `raw`-scope Vale finding's `range.start.line`
+  one line earlier than the flagged text (#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 #297's "off by one" for default-scope rules was this documented
+  convention compared against a 1-based file line, not a bug).
+
 ## 0.11.1
 
 [Compare with v0.11.0](https://github.com/taskless/cli/compare/v0.11.0...v0.11.1)

packages/cli/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@taskless/cli",
-  "version": "0.11.1",
+  "version": "0.11.2",
   "license": "MIT",
   "repository": {
     "type": "git",

skills/taskless/SKILL.md

@@ -20,7 +20,7 @@ description: |
   `agent route`; it does NOT suppress the skill.
 metadata:
   author: taskless
-  version: 0.11.1
+  version: 0.11.2
   commandName: tskl
 compatibility: Designed for Agents implementing the Agent Skills specification.
 ---