Specs still describe the removed taskless help command

[thecodedrift]

What

taskless help <topic> was replaced by taskless agent <topic> with single-token topic addressing. The CLI is done. Eleven references in live specs under openspec/specs/ still name the old command.

This is spec lag, not a code bug

packages/cli/src/index.ts already prints "For agent recipes, run `taskless agent` (no args) for the topic index". openspec/specs/cli-init/spec.md still quotes the old wording. The specs describe a command that doesn't exist. The code is correct.

Where

File	Count	Note
openspec/specs/cli-onboard/spec.md	4	Lines 11, 116, 127 are taskless help onboard. Line 174 says a recipe must reference taskless help rule create, which should now be taskless agent route.
openspec/specs/analytics/spec.md	2	Only the command name in the WHEN clauses is stale. See the note below.
openspec/specs/cli-init/spec.md	2	The non-interactive preamble wording, already correct in code.
openspec/specs/cli-knowledge-prompts/spec.md	1	Prose in the Purpose section.
openspec/specs/cli/spec.md	1	A taskless help scenario.
openspec/specs/skill-taskless/spec.md	1	Uses the tskl help <topic> short form.

Don't touch three references in openspec/specs/cli-help/spec.md

They're deliberate and must keep the literal string:

• Line 37: the scenario asserting the former command name no longer prints a recipe.
• Lines 237 and 242: the requirement that no shipped recipe may contain the string taskless help, plus its scenario.

One extra thing in analytics

Its telemetry shape is right and should be preserved: a single cli_help event carrying a topic property, not per-topic help_<topic> events. But one scenario expects topic: "rule create", and multi-positional topics now exit non-zero instead of resolving. That expected value needs rewriting too, not just the command name.

Suggested approach

Route this through an OpenSpec change with MODIFIED deltas rather than editing openspec/specs/ directly. Changing what a requirement says about the command surface is a content change. Direct spec edits were used recently only to repair structural corruption (a lost code fence, and ## headings that truncated a requirements section), which is a different thing.

Priority

Not urgent. No user-visible impact. The specs are just behind.