docs(openspec): export knowledge prompts as @taskless/cli/prompts

[thecodedrift]

Draft — not ready for review. Spec only; no implementation yet. Opened to keep the work on the remote.

Exposes the CLI's help/*.txt knowledge recipes as an importable @taskless/cli/prompts, so the generator can source routing guidance from the same text the CLI serves rather than a local copy that drifts.

Prompts are functions returning fully-rendered text, not raw strings. Every %(KEY)s resolves inside the package — CLI_VERSION from the build version, INPUT_SCHEMA from the Zod source, PACKAGE_MANAGER_DLX as an agent-fill marker — so no consumer handles a template dialect. PromptOptions carries anonymous, packageManagerDlx, and header; header: false drops the version-bearing first line, which would otherwise sit in an LLM consumer's prompt-cache key and be invalidated by every CLI publish. The help command shares both the embedded source and the render path, so the two surfaces cannot diverge.

TOPICS ships with static only. route, remote, detect, existing, and rule-meta are recorded as internal — each verified unreachable server-side, since route picks a pre-service authoring destination, remote.txt states the service owns rule-type selection, and detect documents a subprocess. Topic names are semver-tracked public API, so exporting one speculatively spends that promise for nothing. A completeness check fails CI when a recipe file is neither exported nor explicitly internal.

stack: openspec-archived will be red until the change is implemented and archived. That is expected: archiving now would delete the spec before anything is built against it.

Where this sits

Each change is independently landable: one OpenSpec change, one PR, archived on merge. The archive gate requires it — a tip PR must leave openspec/changes/ empty — so nothing here is stacked and none of these depend on a shared branch.

PR	Change	Prerequisites
#70 (this PR)	knowledge prompt export	none
#72	Vale binary packages	none
#73	partition rules by engine	none
#71	Vale engine + engine-selection topic	#73 (executes the vale/ directory it scaffolds) and #72 (needs a binary to resolve)

Only #71 has prerequisites. The other three can land in any order.

#70 and #71 are coupled by exactly one line: whichever lands second adds the engine-selection topic to TOPICS. Ordering between them doesn't matter.

Downstream, the generator's decision router (TSKL-279) needs a published release containing #70 and #71. It consumes a normal release — no prerelease, no path dependency — so it waits without blocking anything here.

Fixes OSS-20