Summary
Make the PromptKit version visible to users the moment the composition engine starts, so users can tell which release of PromptKit they are running and so session logs carry provenance that is useful when debugging or reporting issues.
Motivation
Today, when bootstrap.md is loaded — either manually by pointing an LLM at the repo, or through the promptkit interactive (npx) flow that stages content into a temp dir — the LLM begins composing prompts without identifying which version of PromptKit is actually in play. That makes it hard for users and maintainers to:
- confirm which release is active in a given session,
- correlate bug reports or unexpected template behavior with a specific version,
- tell apart drift between local edits, a pinned
npx install, and the upstream main branch.
Proposed change
Add a one-line version banner at the start of every PromptKit session:
- After step 1 of
How to Begin in bootstrap.md, the composition engine reads the top-level version: field from manifest.yaml and emits PromptKit v<version> loaded. before any other output.
- If the field is missing or unreadable, emit
PromptKit (version unknown) loaded. — do not fabricate a version number.
- Re-announce when
bootstrap.md or manifest.yaml is re-read later in the same session.
Because all three entry-point skills (/promptkit, /bootstrap, /boot) and the promptkit interactive CLI all converge on bootstrap.md, one edit covers every activation path — manual load, slash command, and npx.
Tracked work
Benefits
- Provenance: every session self-identifies its PromptKit version, making bug reports actionable without users having to dig for it.
- Debugging: when a template behaves differently than expected, the banner immediately confirms whether the user is on the expected release.
- Consistency: manual load and
npx users get the same signal, since both paths read the same staged bootstrap.md + manifest.yaml.
Notes
- No change to
cli/bin/cli.js is needed for this feature; promptkit --version already reports the CLI package version. The banner is the session-side counterpart.
manifest.yaml.version and cli/package.json are already kept aligned per cli/specs/design.md v0.6.1.
Summary
Make the PromptKit version visible to users the moment the composition engine starts, so users can tell which release of PromptKit they are running and so session logs carry provenance that is useful when debugging or reporting issues.
Motivation
Today, when
bootstrap.mdis loaded — either manually by pointing an LLM at the repo, or through thepromptkit interactive(npx) flow that stages content into a temp dir — the LLM begins composing prompts without identifying which version of PromptKit is actually in play. That makes it hard for users and maintainers to:npxinstall, and the upstream main branch.Proposed change
Add a one-line version banner at the start of every PromptKit session:
How to Begininbootstrap.md, the composition engine reads the top-levelversion:field frommanifest.yamland emitsPromptKit v<version> loaded.before any other output.PromptKit (version unknown) loaded.— do not fabricate a version number.bootstrap.mdormanifest.yamlis re-read later in the same session.Because all three entry-point skills (
/promptkit,/bootstrap,/boot) and thepromptkit interactiveCLI all converge onbootstrap.md, one edit covers every activation path — manual load, slash command, and npx.Tracked work
bootstrap.mdstep 1 to announce the manifest version (branch:announce-promptkit-version-on-load)maintests/validate-manifest.pyto assertmanifest.yaml.versionmatchescli/package.json.versionso the in-session banner andpromptkit --versioncan never driftBenefits
npxusers get the same signal, since both paths read the same stagedbootstrap.md+manifest.yaml.Notes
cli/bin/cli.jsis needed for this feature;promptkit --versionalready reports the CLI package version. The banner is the session-side counterpart.manifest.yaml.versionandcli/package.jsonare already kept aligned percli/specs/design.mdv0.6.1.