Nightly init leaves .claude/ stub files referencing stale @taskless/cli instead of @taskless/cli-nightly

[thecodedrift]

npx @taskless/cli-nightly@latest init correctly updates the canonical .taskless/ files (skill + command) to reference the current pinned nightly version, but the .claude/ reference stubs it generates never get their CLI-package reference updated to match.

Repro

1. Run npx @taskless/cli-nightly@latest init in a project.
2. Run it again later. A new nightly version gets pinned each time, for example 0.11.1-20260831132610x088fa7c to 0.11.1-20260907181107x9edb1f0.
3. Compare .taskless/skills/taskless/SKILL.md (and .taskless/commands/tskl/tskl.md) against .claude/skills/taskless/SKILL.md (and .claude/commands/tskl/tskl.md).

Observed

• Canonical .taskless/ files correctly say npx @taskless/cli-nightly@<current pinned version> agent route / agent <topic> throughout.
• .claude/ stub files: the frontmatter description: field and inline body prose still say npx @taskless/cli agent route / npx @taskless/cli agent <topic>, the plain stable package name, unpinned, left over from before the nightly channel was ever installed.

This has been reproduced across two separate init runs, each pinning a different target version, so it isn't a one-off. The stub's description and body text never get regenerated by init.

The only part of the .claude/ stub that does update correctly is the fallback line: "if .taskless/.../SKILL.md doesn't exist, run npx @taskless/cli-nightly@<version> init to restore it."

Why it matters

The .claude/ stub's description: frontmatter is what an AI agent's skill listing gets built from, and it's surfaced before the agent ever opens the canonical file. So an agent sees "use @taskless/cli" from the skill listing, then gets redirected to a different, pinned @taskless/cli-nightly version once it actually opens the canonical file. Two different CLI invocations depending on which layer gets consulted.

The "RESTART YOUR AGENTS" banner added to init output is a good partial mitigation: it correctly warns that an open agent session's skill listing is stale. But it doesn't fix the underlying problem, because even a freshly reloaded skill listing still reads the stale, unpinned @taskless/cli string from the stub.

Suggested fix

Stop duplicating the CLI invocation string into the stub's own description/body. Either:

• Omit it there entirely ("see canonical file for current invocation"), or
• Have init regenerate the entire stub from taskless.json's cliVersion/channel, frontmatter description included, rather than only the fallback-restore line.

Tracked internally as TSKL-295.