ref(cli): move the recipe glob and renderer into src/prompts

[thecodedrift]

Stack (root → tip):

• ➡️ ref(cli): move the recipe glob and renderer into src/prompts #70 (you are here)
  • feat(cli): export the knowledge prompts as @taskless/cli/prompts #87

Carries unit 1 of the knowledge-prompt export: a pure refactor that moves the recipe source and its renderer out from behind the help command.

commands/help.ts owned the import.meta.glob over help/*.txt, the canonical/anonymous map build, the TOPIC_INPUT_SCHEMAS table, and renderRecipe. All of it now lives in src/prompts/recipes.ts, which help and onboard consume via getRecipe. The module carries no CLI runtime: embedded text, sprintf-js, applyCliInvocation, and the two leaf Zod input schemas.

Parity evidence. help output is byte-identical. It was captured across all 18 canonical topics plus their --anonymous variants, the topic index, and the unknown-topic error path, 38 captures in total, with a zero-byte diff before and after.

Nothing observable changes, so this ships no release note and keeps the skip-changeset label.

Where the export lives

The public surface is unit 2, #87: the ./prompts subpath export, the Vite entry, the TOPICS/PromptOptions API, and the completeness check. That PR carries the changeset and archives the change.

stack: openspec-archived skips this PR, because #87 targets this branch and so this is no longer the tip of its stack. The change is archived exactly once, on #87.

Where this sits

PR	Change	Prerequisites
#70 (this PR)	knowledge prompts: shared module (unit 1)	none
#87	knowledge prompts: @taskless/cli/prompts export (unit 2)	#70 (stacked on it)
#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)

This change is delivered as a two-PR stack, merging forward: unit 1 is independently safe in production because it changes no observable behavior, and unit 2 only adds a new export. Each lands on main in turn.

#87 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 #87 and #71. It consumes a normal release, with no prerelease and no path dependency, so it waits without blocking anything here.

Refs OSS-20

[Copilot]

Pull request overview

Refactors the CLI’s embedded help “recipes” so the glob, lookup maps, and rendering logic live in a shared src/prompts/recipes.ts module, which is then consumed by both help and onboard. This is unit 1 of the stacked change to later export prompts via @taskless/cli/prompts, and is intended to preserve byte-identical help output while de-coupling prompt rendering from the help command implementation.

Changes:

• Introduces packages/cli/src/prompts/recipes.ts to own recipe embedding (import.meta.glob), canonical/anonymous maps, and rendering.
• Updates packages/cli/src/commands/help.ts to use the shared getRecipe implementation (removing its local glob/renderer).
• Updates packages/cli/src/commands/onboard.ts to import getRecipe from the shared prompts module.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
packages/cli/src/prompts/recipes.ts	New shared module that embeds and renders help recipe text and exposes getRecipe.
packages/cli/src/commands/help.ts	Removes local recipe embedding/rendering and delegates to getRecipe.
packages/cli/src/commands/onboard.ts	Switches recipe lookup import to the shared prompts module.
openspec/changes/export-knowledge-prompts/.openspec.yaml	Adds OpenSpec change metadata for the prompts-export effort.
openspec/changes/export-knowledge-prompts/tasks.md	Adds task checklist for the change (currently has path/status inconsistencies vs this PR).
openspec/changes/export-knowledge-prompts/specs/cli-knowledge-prompts/spec.md	Adds spec requirements for the prompts export and behavior.
openspec/changes/export-knowledge-prompts/proposal.md	Adds proposal describing the prompts export change (currently references outdated module path).
openspec/changes/export-knowledge-prompts/design.md	Adds design decisions for the prompts export (currently references outdated module path).

Suppressed comments (1)

openspec/changes/export-knowledge-prompts/design.md:24

• Design doc D2 references src/prompts/index.ts, but the implementation module is src/prompts/recipes.ts in this PR. Keeping this consistent helps validate the “no CLI runtime deps” constraint against the correct file.

`src/prompts/index.ts` imports nothing from the CLI runtime — no `citty`/command tree, no telemetry, no filesystem or network. It may import `sprintf-js` and the two Zod input schemas (`schemas/rules-create`, `schemas/rules-improve`), which are leaf modules whose only dependency is `zod`; both are already dependencies of the intended consumer. The subpath export `@taskless/cli/prompts` maps to a dedicated `dist/prompts.js` so importing it never loads `dist/index.js`.

[thecodedrift]

@claude /review

[claude]

Claude finished @thecodedrift's task in 4m 54s —— View job

---

Review: unit 1 of the knowledge-prompt export

Tasks

• Gather context (diff, repo conventions, CLAUDE.md files)
• Review packages/cli/src/prompts/recipes.ts (new module)
• Review packages/cli/src/commands/help.ts changes
• Review packages/cli/src/commands/onboard.ts changes
• Review OpenSpec docs for internal consistency
• Post inline comments for concrete issues
• Post final summary

Summary

This is a clean, well-contained refactor. I traced every deleted line in help.ts to its new home in src/prompts/recipes.ts and confirmed the moved logic (buildHelpMaps, TOPIC_INPUT_SCHEMAS, renderRecipe, getRecipe) is behavior-preserving:

• getRecipe's canonical/anonymous lookup logic is byte-for-byte the same.
• help.ts's run() handler used to duplicate the lookup+render inline (parallel to the exported getRecipe) — this PR collapses that duplication into a single getRecipe(key, { anonymous }) call, which is a nice incidental cleanup, not just a move.
• onboard.ts now imports getRecipe from the shared module instead of reaching into a sibling command file (./help) — removes a command-to-command import that no longer makes sense architecturally.
• No circular imports introduced; prompts/recipes.ts stays free of CLI runtime deps (citty, telemetry, fs, network) as the design requires.
• Verified all 20 help/*.txt files share the exact # Topic: ... first-line format stripHeader() assumes, so the header-stripping logic is at least consistent with today's recipe files.

Two things worth a look (posted inline)

1. packages/cli/src/prompts/recipes.ts:69-124 — RecipeOptions.header/packageManagerDlx and the stripHeader() branch are new behavior, not moved code, and are unreachable from any caller in this PR (help.ts only ever passes { anonymous }). They ship with zero test coverage here. This sits in tension with the proposal's own rationale for the two-unit split ("the risky part … is reviewed apart from the new API surface") — this is new API surface, landing in the unit that's supposed to be a no-op move.
2. packages/cli/src/prompts/recipes.ts:53 — canonicalRecipeTopics() is exported but has no callers or tests anywhere in the repo; looks like groundwork for unit 2's completeness check landing early.

Neither is a correctness bug — the reachable help/onboard code paths are unaffected, consistent with the PR's byte-identical parity claim. They're scope/test-coverage observations: either add tests for the new RecipeOptions fields now, or defer them to #87 where they'll actually be exercised.

Also noted (already flagged by the other automated review, so not re-posted inline)

The openspec/changes/export-knowledge-prompts/{design,proposal,tasks}.md docs still reference src/prompts/index.ts, but the implementation is src/prompts/recipes.ts. Worth a fixup pass before this stack archives, since #87 (unit 2) will build on these docs.

No security, correctness, or test-adequacy issues found in the help.ts/onboard.ts changes themselves. I did not run the build/lint/test suite locally per instructions — CI will report that separately.

[thecodedrift]

Re: @claude[bot] — "Claude finished @thecodedrift's task in 4m 54s — Review: unit 1 of the knowledge-prompt export…"
#70 (comment)

Both inline findings are confirmed and answered on their threads. I checked the reachability claims rather than taking them as read, and they hold: canonicalRecipeTopics, packageManagerDlx, and header: false have zero consumers on this branch, and all three gain consumers and tests in #87 (test/prompts.test.ts).

They stay in this PR by decision, not oversight. The unit's contract — byte-identical help output — holds exactly because those paths are unreachable from help, which only ever passes { anonymous }. Moving them to #87 would require rewriting this branch and restacking an already-green #87 to close a gap the next merge closes anyway. The residual risk is stated on the threads: if #87 stalls, main carries three unreachable, untested exports until it lands.

For context on this PR's current state: it has been rebased onto main (1d75681) since your review, picking up the repository rename and the Vale platform pins. All four checks are green, and #87 is restacked on top and green as well.

— AI Coding Agent