docs(openspec): propose the agent command and the Vale authoring path

[thecodedrift]

Stack (root → tip):

• feat(cli): share the platform-binary resolver, add the Vale binary spec #71
  • feat(cli): verify Vale rules from per-rule fixture directories #93
    • feat(cli): dispatch the three engines concurrently and merge their findings #94
      • feat(cli): add the engine-selection topic and archive add-vale-rule-engine #95
        • test(cli): check a project both engines have work in, and fix what it found #100
          • ➡️ docs(openspec): propose the agent command and the Vale authoring path #102 (you are here)
            • feat: one directory per rule, and path-addressed verify/test #103
              • docs(openspec): make every spec pass validate --all --strict #106

Proposal only — no implementation. Draft so the archive gate stays quiet until the work is stacked beneath it.

add-vale-rule-engine shipped a chooser without a destination. engine-selection teaches an agent to conclude a rule belongs to vale, and then there is nowhere to go — static.txt is ast-grep authoring, and its only mention of Vale tells the reader to confirm sg was right. runtime dead-ends the same way. That exclusion was a recorded non-goal at the time, defensible while nothing chose Vale; the chooser is what made it reachable.

What it proposes

From	To
taskless help <topic>	taskless agent <topic>
taskless help rule create	taskless agent create-rule (single token, no positional join)
static	create-sg-rule
existing	create-legacy-rule
—	create-vale-rule, create-runtime-rule
route + engine-selection	one route

Plus a section-less scaffolded .vale.ini, so a project lints nothing until someone scopes it deliberately.

The two decisions worth reviewing

D1 — route and engine-selection merge. One decision, made once from one reading of the evidence. Whether a rule is expressible locally and which engine can express it are answered from the same signals, so splitting them cost a second fetch and a handoff without adding information.

The consequence needed solving rather than hand-waving: the platform generator consumes engine-selection through TOPICS and has no route step, so merging can't just delete what it reads. Exporting route instead is wrong — it's built on taskless detect --json and local authoring, neither of which a Worker can do. So the criterion distributes to the destinations: each create-*-rule states the evidence that makes its engine right, and route applies those same tests. That keeps every exported topic one a service-side consumer can actually act on, and removes the drift class where a chooser and its destinations disagree.

D4 — the section-less scaffold ships paired with surfacing Vale's stderr. Measured: with no section to copy, the natural first edit is rules.<id> = YES at top level, which Vale reports as W101 ... is ignoring it — on stderr, exit 0, valid {} on stdout. runVale reads stderr only on a non-zero exit, so today that's discarded and the author gets a rule that verifies, runs, and reports nothing. Shipping the scaffold alone would reintroduce the exact silent-disable class this engine's design exists to prevent, one level up. They are one requirement in the spec, not two.

Also settled

• No create-remote-rule. "Remote" names who generates, not an engine, and the one place it bites — the user is logged out — is where create-runtime-rule already has to speak. One topic, one gate explained once.
• Every backwards-incompatible item here is a MINOR bump. Pre-1.0.
• Found while writing it: cli-knowledge-prompts currently requires a topic rename be MAJOR. The delta corrects that to pre-1.0 semantics, keeping the obligation that actually matters — naming the rename in the changeset, since TOPICS crosses a deploy boundary and the generator breaks on upgrade rather than at our build time.

Open questions in the design

• remote.txt / rule-create.txt still implement service generation but are no longer named by route. Keep, fold into create-sg-rule's escalation path, or merge? Worth deciding before the cross-reference sweep.
• Does create-runtime-rule explain the login gate itself, or defer to auth?

Scope

~306 occurrences of taskless help across 77 files — but concentrated: only one skill file, the rest are recipe cross-references and tests. Delivery shape is a single PR stacked on #100, because recipes cross-reference each other by literal command string, so a half-renamed surface points at commands that don't exist.

pnpm openspec validate --strict passes.

Refs #100

Contains #103

Why

A rule is spread across locations today, and for Vale one of them is shared by every rule in the project. Five sandboxed harness runs against create-vale-rule (on #102) found silent failures in that shared .vale.ini and nowhere else — an assignment above the first matcher, a glob that missed the fixture's extension, three names that had to agree with nothing reporting when they didn't.

The same reasoning generalizes past Vale: sg and runtime rules are also split between a rules/ tree and a parallel rule-tests/ tree, so no engine has a single path meaning "this rule". Fixing Vale alone would leave three layouts instead of one.

What changes

One directory per rule, identical across engines:

.taskless/rules/sg/no-eval/
    no-eval.yml
    .tests/no-eval-20260101-test.yml

.taskless/rules/vale/no-simply/
    no-simply.yml
    .vale.ini            # this rule's matchers, excludes, tskl) metadata
    .tests/pass/ok.md
    .tests/fail/bad.md

.taskless/rules/runtime/unused-exports/
    check.ts
    captures/exported-symbol.yml
    .tests/…

check assembles the Vale and ast-grep configs from the per-rule tree and gitignores them. rule verify <id> is replaced by path-addressed verify <path> (required components) and test <path> (tests), with verify running as a prerequisite layer of test.

Adds example/ — a small real project so a reader can see an install rather than infer it from tests that build their own fixtures, with a check test so it can't drift.

The dot on .tests/ is load-bearing, and measured

Probe	ast-grep 0.41.0	Vale 3.17.1
tests/ inside the rule dir	fails — missing field 'language'	fine
__tests__/	fails	fine
.tests/	skipped by rule discovery ✓	fine, even containing a .yml
test runner reads it	testDir: …/.tests works; snapshots land inside	buckets lint when targeted

ruleDirs recurses and parses every .yml beneath as a rule, so a plain tests/ directory hard-fails the scan.

This is a dependency on undocumented behavior and D2 records it as one, with two mitigations: the failure is loud — a parse error naming the file, not a test silently reinterpreted as a rule — and a test pins it. The rejected alternative (materialize a rules-only tree for ast-grep, keeping a plain tests/) is written down as the fallback if the assumption breaks.

Other measured constraints

• <id>/<id>.yml resolves as check <id>.<id> only under a StylesPath naming its parent; under StylesPath = . it resolves to nothing. This reverses the note in migration 0004 — correct for the flat layout, backwards for this one — so the task list rewrites that docstring rather than deleting it.
• Vale rejects unknown keys in a style (E201), so scope cannot ride inside the style file. ast-grep can express scoping in the rule, which is why it gets no per-rule config — an empty file per rule is symmetry as decoration.

Delivery shape

Stacked, merging down on #102. 0005 layers on 0004; both are unreleased and both ship in this stack, so consumers run them as one upgrade and never observe the intermediate layout.

openspec validate --all --strict will flag the cli-agent-authoring delta until #102 archives — that capability is introduced there.

Spec-only. Implementation follows on approval.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3

Contains #106

Cleanup on top of the stack so pnpm openspec validate --all --strict is green and the gate in #105 can be turned on without landing red.

Two failures, and a third problem that wasn't failing

cli-update-engine — deleted. A tombstone: capability decommissioned, every requirement removed, file kept "for historical reference". --strict needs at least one requirement. specs/ describes what's true now, and the history is already in the 2026-03-30-remove-scaffold-dependency archive, including that change's own cli-update-engine delta. Nothing outside the archives referenced it.

cli-rules — 18 errors. Scenarios and SHALL keywords added to 15 requirements. The five specifying taskless rule verify are removed: this stack deleted that command in favour of the path-addressed verify and test, now owned by cli-rule-validation. A requirement stating the subcommand is gone replaces them. Two requirements named pre-layout paths (.taskless/rule-tests/<id>.yml, and deleting "rule and test files" rather than the rule directory); both repathed while being touched.

The one worth reading. A second ## inside a requirements section ends it, so every requirement below stops being parsed:

Spec	In file	Visible before	--strict before
cli-rules	33	23	failing
infrastructure	20	1	passing
skills	7	1	passing

infrastructure and skills passed throughout, because the single requirement each still exposed was well-formed. 35 requirements were unread while the validator reported success. This is the same shape as the cli-help defect repaired earlier in the stack, where a lost code fence turned a documentation template into real headings.

The topical groupings are kept as bold lead-in lines instead of headings. Un-nesting infrastructure immediately exposed a real requirement with no SHALL, now fixed.

skills also still told agents to fetch recipes via npx @taskless/cli help <topic>.

Result

23 specs, 0 failures, with every requirement actually visible to the parser. 594 tests, lint and typecheck unchanged: this PR touches only openspec/specs/.

Note that --strict alone would not have caught the hidden-requirement class. Detecting it needs a separate check that every ### Requirement: sits under ## Requirements — noted on #105 for whoever wires the gate.

Refs #105

🤖 Generated with Claude Code

https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3

[thecodedrift]

@claude /review

[claude]

Claude finished @thecodedrift's task in 5m 55s —— View job

---

Review: docs(openspec): propose the agent command and the Vale authoring path (#102)

• Gather context (PR diff vs. origin/openspec/add-vale-rule-engine-5-integration, OpenSpec proposal/spec/design/tasks, CLAUDE.md conventions)
• Review for correctness (line-by-line diff scan, removed-behavior audit, cross-file tracing)
• Review for consistency/architecture (engine dispatch vs. verify ownership)
• Review for reuse/duplication
• Review for efficiency
• Review for simplification
• Review against CLAUDE.md / STYLEGUIDE-CODE.md conventions
• Post inline comments and summary

Overall assessment

Despite the PR title/body framing this as "proposal only — no implementation," the diff ships real behavior changes: help → agent rename, single-positional-token enforcement, the Vale ownership/verify path, and the stderr-notice plumbing. Reviewed accordingly.

The core design (D1 merging route/engine-selection, D4 pairing the section-less scaffold with stderr surfacing) is sound and the rationale in the PR body is well-argued. The implementation has a few concrete gaps, the most important being that the rename this PR performs isn't fully propagated through the help-recipe corpus, which undercuts the PR's own stated goal (agents navigating a coherent, self-consistent recipe graph).

Correctness — dead cross-references left after the help → agent rename (highest priority)

taskless help <topic> (the old command form) still appears in 14 help recipe files after this PR: rule.txt, delete-rule.txt, improve-rule.txt, improve-rule.anonymous.txt, verify-rule.txt, check.txt, ci.txt, detect.txt, info.txt, init.txt, onboard.txt, rule-meta.txt, update.txt, auth.txt (verified via grep against the current tree). None of these files are in the PR's changed-files list, so they weren't touched by the rename.

Since help is no longer a registered subcommand (index.ts now registers only agent) and agent.ts rejects multi-token topics ("Too many arguments"), following any of these recipes verbatim either silently no-ops (hasPositional guard exits 0 with no output) or hard-errors. This bites on paths agents are actively steered down:

• onboard.txt (lines ~94, 120-122) — the very first action step of onboarding a fresh session.
• ci.txt (lines ~15, 69, 210-221) — the zero-rules fallback in CI mode.
• detect.txt (lines ~48-50, 62-64) — routing to existing/static, both renamed (create-legacy-rule/create-sg-rule) and never cross-referenced from here.
• verify-rule.txt / improve-rule.txt — self-referential "See Also" escalation paths broken by this PR's own renames.

Given the PR explicitly scopes itself around "~306 occurrences... concentrated" and calls out a "cross-reference sweep" as an open question, this looks like exactly the kind of half-swept surface the PR itself warns about (static.txt/remote.txt-style dangling references) — worth resolving before this lands, or explicitly deferring with a tracked follow-up.

Correctness — ownership/verify inconsistencies

• packages/cli/src/rules/owner.ts (inline comments posted):

  • rulefileOwners hardcodes a two-engine candidate list (sg, vale) instead of iterating ENGINES/ENGINE_LAYOUTS, silently omitting runtime. A runtime-owned rule id returns zero owners and falls through to the ast-grep verifier, which reports a bogus "missing rule file" under engine: "sg".
  • ruleFileLocation always reconstructs the canonical path from ENGINE_LAYOUTS, even though rulefileOwners matches against astGrepRuleFileCandidates, which also includes the legacy .taskless/rules/<id>.yml location. If the ambiguity is caused by a legacy-location file, the "exists for more than one engine" error names a path that doesn't exist and never mentions the real conflicting file. Since rulefileOwners already knows which candidate matched, returning {engine, path} pairs and dropping ruleFileLocation would fix this at the source rather than reconstructing (and risking a wrong reconstruction).

• packages/cli/src/rules/vale/verify.ts (verifyValeRule, ok branch, ~line 256): reads outcome.results but never outcome.notice. This directly undercuts D4's own rationale — the whole point of surfacing Vale's stderr notice is to catch a section-less scaffold silently going quiet, but rule verify <id> --json on a Vale rule drops that notice while taskless check on the identical repo state prints it via dispatch.ts → check.ts. Same underlying condition, visible through one entry point and invisible through the other. Not covered by the new rule-verify-dispatch.test.ts.

• dispatch.ts vs. owner.ts disagree on ambiguity: rulefileOwners (used by rule verify) treats a rule id existing under both sg and vale as a hard error. runAstGrepEngine/runValeEngine in dispatch.ts (used by check) never perform this cross-engine check — each just scans its own directory, so the same on-disk state that verify refuses outright runs silently through check, reporting findings from both engines under one id with no warning.

Reuse / duplication

• packages/cli/src/commands/rules.ts: the "build message → print JSON error envelope or console.error → set exitCode → return" shape is repeated at ~line 714, ~725-740, and ~852-860, all reimplementing writeJsonError (packages/cli/src/types/errors.ts), which is already used elsewhere (commands/auth.ts). Worth a small reportCLIError(json, code, message) helper.
• packages/cli/src/rules/owner.ts's isFile() re-implements the same ENOENT/ENOTDIR-as-absence check as isMissingDirectory (rules/vale/verify.ts) and pathExists (filesystem/migrations/0004-vale-engine.ts) — a third independent copy of "which errors mean not-here."

Simplification

• dispatch.ts:166 and rules/vale/run.ts:236-247,277: ...(outcome.notice === undefined ? {} : { notice: outcome.notice })-style conditional spreads exist only to hide an already-optional field; every reader treats absent/undefined identically and JSON.stringify drops undefined on its own. Simplifies to a plain notice property.
• commands/agent.ts:154,158: identical telemetry.capture("cli_help", { topic: key }) duplicated across both branches of the recipe-found/not-found if/else — hoist above the branch.

Efficiency (minor, non-blocking)

• owner.ts's rulefileOwners probes engines and candidate paths sequentially (for/await in a loop) where they're independent and could run via Promise.all; worst case is 3 sequential stat round-trips. Low-single-digit ms in practice, not worth blocking on.
• rulefileOwners stats a path, and shortly after verifyRule/verifyValeRule re-reads/re-probes the same candidate paths from scratch — a small amount of duplicated I/O that could be avoided by threading the resolved path through, but not a correctness issue.

Conventions

No CLAUDE.md / STYLEGUIDE-CODE.md violations found: imports are direct (no barrel exports), correctly grouped/ordered, exported types are properly exported, the new rule-verify-dispatch.test.ts exercises the built CLI's output rather than parsing generated artifacts (consistent with the "verify build output in the build" rule), and the changeset absence is consistent with this being a mid-stack PR per the root CLAUDE.md's stacked-PR rules (no skip-changeset label misuse observed).

Not flagged as bugs, but worth a deliberate answer before merge

• TOPICS (packages/cli/src/prompts/index.ts) drops static/engine-selection with no compatibility shim; the PR body already surfaces this as a known consequence for the platform generator's TOPICS consumption and proposes the MINOR-bump correction to cli-knowledge-prompts — flagging only because nothing in-repo currently guards against it besides the changeset discipline.
• Vale I/O errors (e.g. EACCES on an unreadable fixture directory) are reported as INVALID_INPUT in verifyValeRuleCommand's catch block, conflating a filesystem problem with a user-input problem.

[Copilot]

Pull request overview

This PR renames the CLI’s agent-facing knowledge surface from taskless help to taskless agent, switches topic addressing to single-token names, and fills the previously missing Vale authoring destination by adding new authoring recipes plus related CLI/test updates. It also adjusts Vale scaffolding and runtime behavior (stderr-on-success surfaced as a notice) and extends rule verify to dispatch by owning engine (ast-grep vs Vale) to make the authoring/verification loop reachable for both engines.

Changes:

• Replace the help subcommand with agent, remove positional-join topic resolution, and update telemetry/tests accordingly.
• Add/rename rule-authoring recipes (create-sg-rule, create-vale-rule, create-runtime-rule, create-remote-rule, create-legacy-rule) and merge engine-selection reasoning into route.
• Extend rule verification to route by engine ownership, add Vale verify output shape, and surface Vale stderr diagnostics as non-blocking notices; update OpenSpec change docs/specs.

Reviewed changes

Copilot reviewed 43 out of 47 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/cli/test/rule-verify-dispatch.test.ts	Adds coverage for rule verify dispatch by owning engine and Vale fixture validation behaviors.
packages/cli/test/prompts.test.ts	Updates prompt/topic typing and parity checks to the renamed topics and agent command.
packages/cli/test/onboard.test.ts	Updates onboarding test expectations to use taskless agent recipes.
packages/cli/test/help-telemetry.test.ts	Switches telemetry coverage from help command module to agent command module and updates topic capture expectations.
packages/cli/test/help-routing-telemetry.test.ts	Adjusts routing telemetry tests for the new command (but still referenced removed topics; flagged in comments).
packages/cli/test/help-extensions.test.ts	Updates behavioral tests for topic listing/resolution, removed-topic behavior, and new routing/authoring topics.
packages/cli/test/cli.test.ts	Updates “no args” behavior expectation to reflect agent index output.
packages/cli/test/cli-run.test.ts	Updates resolveCommandName coverage to treat agent like the old help (command name only).
packages/cli/test/anonymous-flag.test.ts	Updates anonymous-flag guidance strings to point to new taskless agent … topics.
packages/cli/src/types/errors.ts	Adds ENGINE_UNAVAILABLE error code to distinguish missing engine binaries from execution failures.
packages/cli/src/telemetry-run.ts	Updates command-name derivation docs/behavior from help to agent.
packages/cli/src/schemas/rules-verify.ts	Adds an engine discriminant to sg verify output and introduces a distinct Vale verify output schema.
packages/cli/src/rules/vale/run.ts	Captures Vale stderr on zero-exit runs and returns it as an optional notice on ok outcomes.
packages/cli/src/rules/owner.ts	New helper to determine rule ownership by rule file location and format actionable paths for errors.
packages/cli/src/rules/dispatch.ts	Forwards Vale “notice” (stderr diagnostics on success) through dispatch results without affecting exit codes.
packages/cli/src/prompts/recipes.ts	Renames schema-bearing topics (rule-create/rule-improve → create-remote-rule/improve-rule).
packages/cli/src/prompts/index.ts	Updates exported TOPICS/INTERNAL_TOPICS to match the renamed authoring surface and removed engine-selection export.
packages/cli/src/index.ts	Registers agent subcommand and updates non-interactive routing from help to agent.
packages/cli/src/help/verify-rule.txt	Adds a verify recipe (but needed updates to match single-token topic naming and new output shape; flagged in comments).
packages/cli/src/help/static.txt	Removes the old static authoring recipe (replaced by create-sg-rule).
packages/cli/src/help/rule-create.txt	Removes old service-generation recipe (merged into create-remote-rule).
packages/cli/src/help/rule-create.anonymous.txt	Removes old anonymous create recipe (folded into create-sg-rule guidance).
packages/cli/src/help/route.txt	Rewrites routing to classify into the new destinations and embeds engine reasoning directly.
packages/cli/src/help/remote.txt	Removes old “remote boundary” recipe (merged into create-remote-rule).
packages/cli/src/help/improve-rule.txt	Adds API-backed improve recipe (but had stale taskless help references/topic header; flagged in comments).
packages/cli/src/help/improve-rule.anonymous.txt	Adds anonymous/local improve recipe (but had stale taskless help references/topic header; flagged in comments).
packages/cli/src/help/engine-selection.txt	Removes standalone engine-selection recipe (merged into route).
packages/cli/src/help/delete-rule.txt	Adds delete recipe (but had stale taskless help references/topic header; flagged in comments).
packages/cli/src/help/create-vale-rule.txt	Adds comprehensive Vale authoring recipe (rule + .vale.ini scoping + fixtures).
packages/cli/src/help/create-sg-rule.txt	Adds renamed local ast-grep authoring recipe replacing static.
packages/cli/src/help/create-runtime-rule.txt	Adds logged-out runtime authoring/gate explanation recipe.
packages/cli/src/help/create-remote-rule.txt	Adds merged, single-procedure service-generation recipe.
packages/cli/src/help/create-legacy-rule.txt	Renames/retitles legacy-linter authoring recipe (was existing).
packages/cli/src/filesystem/migrations/0004-vale-engine.ts	Makes scaffolded .vale.ini section-less to avoid unscoped default linting.
packages/cli/src/commands/rules.ts	Dispatches rule verify by owning engine; adds Vale verification command path and JSON output support.
packages/cli/src/commands/agent.ts	Implements agent command (index + single-token topic resolution + telemetry), replacing old help behavior.
openspec/changes/agent-command-and-vale-authoring/tasks.md	Plan/checkboxes for this OpenSpec change set.
openspec/changes/agent-command-and-vale-authoring/specs/cli-vale-rule-engine/spec.md	Specifies section-less scaffold + stderr-on-success notice requirements for Vale.
openspec/changes/agent-command-and-vale-authoring/specs/cli-rule-routing/spec.md	Specifies merged routing+engine reasoning and renamed destinations.
openspec/changes/agent-command-and-vale-authoring/specs/cli-knowledge-prompts/spec.md	Specifies topic export surface stability and pre-1.0 MINOR semantics.
openspec/changes/agent-command-and-vale-authoring/specs/cli-help/spec.md	Updates spec to agent command semantics and no positional-join behavior.
openspec/changes/agent-command-and-vale-authoring/specs/cli-agent-authoring/spec.md	Adds requirements ensuring each engine has a reachable authoring recipe.
openspec/changes/agent-command-and-vale-authoring/resume.md	Handoff notes for continuing the change set work.
openspec/changes/agent-command-and-vale-authoring/proposal.md	Proposal narrative for the rename + Vale authoring destination.
openspec/changes/agent-command-and-vale-authoring/iteration-log.md	Execution log of recipe harness runs used to validate authoring prose.
openspec/changes/agent-command-and-vale-authoring/design.md	Design decisions (D1–D10) supporting the new command/topic model.
openspec/changes/agent-command-and-vale-authoring/.openspec.yaml	OpenSpec change metadata for the proposal directory.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[thecodedrift]

@claude /review

[claude]

Claude finished @thecodedrift's task in 5m 2s —— View job

---

Review: docs(openspec): propose the agent command and the Vale authoring path (#102)

• Gather context (diff vs origin/openspec/add-vale-rule-engine-5-integration, changed files, CLAUDE.md conventions)
• Correctness review (line-by-line diff scan, removed-behavior audit, cross-file tracing)
• Reuse / simplification / efficiency review
• Conventions (CLAUDE.md / STYLEGUIDE) review
• Post inline comments and top-level summary

Overall assessment

This is a second pass on #102 (a prior @claude /review ran on this PR). The good news: the biggest gap from that earlier pass — dangling taskless help cross-references left after the rename — is fixed, and fixed properly: packages/cli/test/recipe-cross-references.test.ts now scans the shipped recipe corpus itself (no taskless help occurrences, no dangling taskless agent <topic> citations, header/filename agreement) rather than relying on a manual sweep. I confirmed grep -rn "taskless help" packages/cli/src/help/ returns nothing, and spot-checked onboard.txt, detect.txt, ci.txt — all correctly point at the new single-token topics.

However, most of the substantive findings from the earlier review pass are still open in the current diff — they weren't stylistic, and re-checking them against the current owner.ts/verify.ts/dispatch.ts shows the same code:

1. Vale's stderr notice still doesn't reach rule verify (inline comment on packages/cli/src/schemas/rules-verify.ts). D4's stated rationale is that surfacing Vale's stderr is what makes the section-less scaffold safe — but that only holds for taskless check. verifyValeRule (packages/cli/src/rules/vale/verify.ts:262, not touched by this PR) reads outcome.results and never outcome.notice, and valeVerifyOutputSchema has no field to carry it even if it were read. Same repo state (misplaced rules.<id> = YES) reports the W101 warning through check and silently passes through rule verify. Not covered by the new rule-verify-dispatch.test.ts.

2. rulefileOwners still hardcodes ["sg", "vale"], omitting runtime from ENGINES = ["sg", "vale", "runtime"] (inline comment on packages/cli/src/rules/owner.ts:30). A runtime-owned rule id returns zero owners and falls through to the ast-grep verifier, reporting a bogus "missing rule file" under engine: "sg".

3. verify-rule.txt wasn't updated for multi-engine dispatch (inline comment). Its Goal/Preconditions/Steps/Errors/JSON example are still ast-grep-only, despite the topic version bump to v2 and commands/rules.ts now dispatching rule verify by ownership with a divergent Vale output shape. create-vale-rule.txt treats verify-rule as authoritative for Vale verification, so the two recipes now disagree.

4. The changeset's rename table is factually wrong (inline comment on .changeset/vale-rule-engine.md:28). It states static, existing → route; the actual mapping is static → create-sg-rule (now exported via TOPICS) and existing → create-legacy-rule (internal), with only engine-selection merging into route. This is public breaking-change documentation for @taskless/cli/prompts consumers, worth getting right.

5. help-routing-telemetry.test.ts still iterates the removed topics (inline comment) — it passes today only because agent.ts fires the same cli_help telemetry event on both the found and not-found paths, so the test now silently validates the unknown-topic path instead of routing topics.

Lower-priority, unaddressed since the last pass (not re-flagged inline to keep this focused, but worth a look before merge):

• owner.ts's ruleFileLocation still reconstructs only the canonical path, while rulefileOwners also matches the legacy ast-grep location — an ambiguity error can name a path that doesn't exist.
• commands/rules.ts's new verifyValeRuleCommand and the owners.length > 1 branch still hand-roll the JSON error envelope instead of using writeJsonError (packages/cli/src/types/errors.ts), now three sites in this file diverging from the shared helper.
• commands/agent.ts:154,158 duplicates telemetry.capture("cli_help", { topic: key }) across both branches of the found/not-found if/else.
• dispatch.ts (used by check) still never performs the cross-engine ambiguity check that owner.ts (used by rule verify) hard-errors on — the same on-disk state (a rule id under both sg and vale) is refused by one entry point and silently merged by the other.

Conventions

No new CLAUDE.md/STYLEGUIDE-CODE.md violations found beyond what's noted above (imports direct and correctly grouped, exported types properly exported, recipe-cross-references.test.ts reads recipe source rather than parsing built output, consistent with the "verify build output in the build" rule).
(branch: openspec/agent-command-and-vale-authoring)