@tryglen/cli 0.34.0 → 0.36.1

package/dist/jcode/skills/create-skill/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: create-skill
+description: Turn what you just did (or a markdown prompt the user provides) into a reusable skill — either a local SKILL.md on this machine or a shared Glen skill saved to the org's library. Use when the user says "make this a skill", "save this as a skill", "save this as a Glen skill", or wants to capture a repeatable workflow.
+---
+
+You are authoring a reusable **skill** — a focused markdown prompt another agent will follow later, with no memory of this session.
+
+1. **Pick the destination FIRST — local file or Glen skill.** A skill is either a **local `SKILL.md`** on this machine (a jcode skill, visible only to you) or a **Glen skill** saved to your Glen library (recorded; private to you by default, sharable with teammates or the whole org).
+   - **Check incognito before anything else:** run `glen status` via Bash. If it reports `incognito: ON`, a Glen skill is off the table — nothing is recorded off the record — so go straight to a **local skill** and tell the user that's why (e.g. "you're off the record, so I'll save this as a local skill").
+   - **Otherwise, ask the user which they want** before authoring anything: a local `SKILL.md` (a jcode skill on this machine) or a Glen skill (saved to your Glen library). Don't start writing until they answer.
+2. **Gather the real workflow.** Read this conversation for the steps that actually worked. For anything done in an earlier session, run `glen search "<topic>"` via Bash to pull the relevant memory. Ask one or two clarifying questions only if the goal or trigger is genuinely ambiguous.
+3. **Name + describe it.** A short imperative name and a one-sentence description that says *exactly when to trigger it* (this drives discovery).
+4. **Write a tight SKILL.md body.** Best practices:
+   - Lead with *when to use it* and the end goal.
+   - Give concrete, ordered steps — exact commands, file paths, gotchas — not vague advice.
+   - Keep it self-contained: assume zero prior context. Cut anything that isn't actionable.
+   - **Reference other skills** when a step is itself a saved skill: write a markdown link `[Display text](glen:<slug>)` (find the slug with `glen skill search`). Glen tracks the link automatically and the reader will get a runnable `glen skill use <slug>` command exactly there — keep each referenced skill focused and say *when* to reach for it. Reserve this for genuinely **shared** skills — ones that also get used on their own, independent of this one.
+   - **If the skill needs supporting material, bundle it in one skill directory, not separate subskills.** Put long reference material in `references/*.md` and executable helpers in `scripts/` alongside `SKILL.md`, and point to them from the body as `${GLEN_SKILL_DIR}/references/<name>.md` / `${GLEN_SKILL_DIR}/scripts/<name>` — `glen skill use` materializes the whole directory to disk and substitutes `${GLEN_SKILL_DIR}` with its real absolute path before printing, so the reader can run the script or open the reference exactly as written. This keeps one topic as one skill instead of splintering it into a root + subskills just to hold its own files.
+5. **Finish based on the destination chosen in step 1:**
+
+   **Local skill** (and always the incognito path) — nothing leaves the machine:
+   - Save it to `.jcode/skills/<name>/SKILL.md` in this project — or `~/.jcode/skills/<name>/SKILL.md` for a personal skill that follows you across every project.
+   - Start the file with YAML frontmatter (`name`, and the `description` from step 3), then the body.
+   - No `glen skill create`, no recording. Confirm the saved path to the user.
+
+   **Glen skill** (only when not incognito):
+   - **Declare its dependencies.** List the external tools/runtimes/MCPs the skill needs (node, an MCP, a CLI, …). For each: run `glen dependency search "<tool>"` via Bash — if a confident match exists, note its `[id]`; otherwise web-search the canonical source/install page and note `{ name, description, sourceUrl, kind }` (kind = mcp|cli|runtime|library|service). Write them to a JSON array file, e.g. `/tmp/glen-deps.json`, mixing `{ "dependencyId": "<id>" }` (reuse) and new objects.
+   - **Save it** via Bash. Text-only skill (no `references/`/`scripts/`): write the body to a file (e.g. `/tmp/glen-skill.md`), then run (add `--deps /tmp/glen-deps.json` if there are any):
+
+     ```
+     glen skill create --name "<name>" --description "<one-line>" --file /tmp/glen-skill.md --deps /tmp/glen-deps.json
+     ```
+
+     Skill with bundled files: build the package in a temp directory first — `SKILL.md` at its root, plus whichever of `scripts/`, `references/`, `assets/` it needs (only those three subdirs are uploaded; caps are 100 files, 1MB per text file, 2MB per binary file, 3MB total) — then run:
+
+     ```
+     glen skill create --name "<name>" --description "<one-line>" --dir /tmp/glen-skill-pkg --deps /tmp/glen-deps.json
+     ```
+
+     `--file` and `--dir` are mutually exclusive. On a name collision either form errors — pick a different name and retry, or pass `--update` to overwrite a skill you previously authored.
+   - The skill is **private to the user by default**. Ask the user whether to share it: with the whole org (add `--org` to `glen skill create`, or later `glen skill share <slug> --org`) or with specific teammates (`glen skill share <slug> --with <email>[,<email>…]`). Confirm the saved slug and its visibility back to the user.

package/dist/jcode/skills/feedback/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: feedback
+description: Send a bug report or product feedback about glen itself to the Glen team. Use when the user says things like "tell the glen team", "file a bug about glen", "glen search is useless — report it", "give feedback on glen", or when YOU hit a concrete, reproducible glen malfunction worth reporting.
+---
+
+This files a ticket about **glen itself** — the CLI, the memory, the search, the
+dashboard. It is NOT for bugs in the user's own project. If the user says "file a
+bug" about the code you are working on, that belongs in their issue tracker, not
+here.
+
+Tickets land in the same Slack channels the dashboard's feedback widget posts to,
+and carry the user's identity, the repo/branch, and a link to this conversation's
+transcript automatically. Never paste secrets, tokens, or file contents into a
+ticket — the transcript link already gives the team the context.
+
+## Filing on the user's behalf
+
+When the user asks you to report something, run one of these via Bash:
+
+```
+glen bug "<title>" --description "<what is wrong>" [--steps "<repro>"] [--severity low|medium|high|critical] --agent <agent>
+glen feedback "<title>" --wants "<the concrete change>" --why "<why it matters>" [--context "<extra>"] --agent <agent>
+```
+
+Severity defaults to `medium`. Write the description in the user's own words
+where you have them. Infer `--why` when the motivation is obvious rather than
+interrogating the user for it.
+
+## Filing on your own behalf
+
+When the observation is yours, not the user's, add `--from agent`. It renders
+differently for the team — "Claude Code noticed X" reads very differently from
+"Ada wants X", and both are useful.
+
+If you are filing **without being asked** — you hit the problem yourself and
+decided it was worth reporting — also pass `--proactive`. At most one proactive
+ticket is sent per session; further ones are skipped, so you never need to track
+whether you already filed. On an off-the-record (incognito) session the server
+refuses self-initiated tickets outright and the command tells you so — nothing
+the user didn't ask for leaves that session. Mention it and let them decide.
+
+Only file proactively for something concrete and attributable:
+
+- a glen CLI command failed or returned a malformed result
+- `glen search` returned results that clearly contradict the code you just read
+- a glen hook misfired, or injected context that was plainly wrong
+
+Do NOT file proactively for: a search that merely found nothing, a preference of
+yours about the output format, a hunch, or anything you cannot state as a
+specific observed behaviour. When in doubt, mention it to the user instead and
+let them decide.
+
+## After running
+
+On success it prints `✓ Bug report sent` / `✓ Feedback sent` — tell the user it
+went in. On failure it prints a `✗` line naming the cause and the fix (e.g. "no
+active organization" → `glen org switch`). Relay that to the user and stop.
+**Never retry a failed filing in a loop**, and never re-file the same ticket with
+different wording.

package/dist/jcode/skills/forget/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: forget
+description: Correct glen's memory — forget evidence that is wrong, outdated, or no longer relevant, so the team stops being told it. Use when the user says things like "that's wrong, forget it", "glen has the wrong X", "that memory is out of date", or "stop remembering that" — or when YOU verify that recalled evidence is contradicted by current code or state.
+---
+
+A stale memory gets caught two ways: the user points at it, or you verify it yourself.
+
+**User-initiated** — the user says a remembered fact is wrong or outdated:
+
+1. Identify the relevant source references. Glen search results end each source with
+   an exact `observation:<id>` or `message:<id>` reference. If the result is not
+   already in context, run `glen search "<topic>"` via Bash.
+2. Confirm which evidence is wrong. Do not automatically forget every source in a
+   synthesized answer. When several sources repeat the same stale claim, select all
+   of those references.
+3. Pass the returned references unchanged, in one command:
+   `glen forget observation:<id> message:<id>`.
+
+**Agent-detected** — recalled evidence is contradicted by current code or state:
+
+1. Verify the contradiction directly. Never forget on suspicion, a partial view, or
+   merely because two memories disagree; surface uncertain conflicts to the user.
+2. Run `glen forget <reference...>` with only the contradicted source references.
+3. Tell the user exactly what was forgotten and why.
+
+Then state the correct fact in the conversation so Glen can record the correction.
+
+Notes:
+
+- Observation and message references can be mixed in one atomic command.
+- Forgetting an observation hides that distilled memory from recall.
+- Forgetting a message removes it from future recall and hides derived observations
+  that have no other active supporting message. The raw message remains visible in
+  transcript history for audit.
+- Forget is idempotent; already-hidden references are reported as unchanged.
+- Undo with `glen restore <reference...>`. Automatic restore never revives an
+  observation that a user directly forgot.
+- Legacy `[m:<id>]` and bare observation ids remain accepted.
+- If a legacy suffix is ambiguous, retry with the full `observation:<id>` listed.
+- If the CLI reports no active organization, tell the user to run
+  `glen org switch`.

package/dist/jcode/skills/import-transcripts/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: import-transcripts
+description: Import the user's old local coding-agent transcripts (Claude Code, Codex, Cursor, or Pi sessions from before glen was installed) into glen's shared team memory. Use when the user asks to import, backfill, or migrate past sessions/conversations/chat history into glen.
+---
+
+Run `glen import <path…>` via Bash. It parses local transcripts, replays them
+into glen turn by turn, and is safe to re-run — already-imported turns are
+skipped automatically.
+
+Where old transcripts live:
+
+- Claude Code sessions: `~/.claude/projects` (one `<session-uuid>.jsonl` per
+  session, grouped by project directory)
+- Codex sessions: `~/.codex/sessions`
+- Pi sessions: `~/.pi/agent/sessions` (one `<timestamp>_<uuid>.jsonl` per session,
+  grouped by project directory)
+- Cursor chats: `~/.config/Cursor/User/globalStorage/state.vscdb` on Linux,
+  `~/Library/Application Support/Cursor/User/globalStorage/state.vscdb` on
+  macOS (needs Node 22.5+; close Cursor first for the freshest data)
+
+A path can be a single file or a directory (scanned recursively; formats are
+auto-detected per file). Preview with `glen import --dry-run <path…>` — it
+lists every conversation and turn count without writing anything. For large
+directories, offer the dry run first so the user can confirm the scope.
+
+If it prints "no active organization", tell the user to run `glen org switch`.
+If it prints "not connected", tell the user to run `glen login`.

package/dist/jcode/skills/invite/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: invite
+description: Invite a teammate to the user's glen organization by email, so the team's shared memory grows. Use when the user says things like "invite Alice", "add my teammate to glen", "get my team on glen", or asks how to bring coworkers in.
+---
+
+glen is shared team memory — it gets more useful with every teammate whose context
+lands in the pool. When the user wants to bring someone in:
+
+1. Get the teammate's email address. Ask if it isn't given.
+2. Run `glen invite <email>` via Bash. Invite several at once by passing more
+   emails: `glen invite alice@co.com bob@co.com`. To make someone an admin, add
+   `--role admin` (default is a regular member).
+3. Report the result. Each address prints one of:
+   - `✓ Invitation sent to <email>` — an email invite is on its way; they accept
+     at the link and join the org.
+   - `· <email> is already a member` — nothing to do.
+   - `✗ Could not invite <email>` — relay the reason.
+
+Or share a link instead of emailing: run `glen invite` with NO email to print a
+shareable join link for the org. Anyone who signs in with a verified email on the
+org's work-email domain joins automatically — good for dropping in a team channel.
+(Requires "Let teammates join with their work email" to be enabled in
+Settings → General.)
+
+Notes:
+- Invites are sent by email and expire after 48 hours; the teammate clicks the
+  link, signs in, and lands directly in the shared memory.
+- If it prints "no active organization", tell the user to run `glen org switch`.

package/dist/jcode/skills/search/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: search
+description: Search the team's shared glen memory for a SPECIFIC fact, decision, or past discussion that is not already in the auto-injected context. Do not use for things already recalled this turn.
+---
+
+For current or source-owned facts, use the available source-of-truth tool first (for example, Slack, GitHub, Notion, or logs), especially when the user names it. Use Glen only for durable history or to supplement that source; if the live source is unavailable, say so, and if it conflicts with Glen, prefer it for current state.
+
+Run `glen search "<query>"` via Bash — **start with ONE comprehensive query, not a
+fan-out of variants**.
+
+Each search takes ~10 seconds of real user-facing wait, and the server ranks results
+with an LLM that reads your query as free-text intent — so one detailed, self-contained
+query beats several keyword variants. Pack everything you know into a single query:
+who/what/where, the repo or system involved, and what kind of answer you need (a
+decision, an owner, a rationale, setup steps).
+
+- ✅ `glen search "Shams's recent work on the usage-page redesign in the dashboard repo — what was decided, current status, and who owns it"`
+- ❌ `glen search "Shams"` … `glen search "usage page redesign"` … `glen search "dashboard"`
+
+If a hook or reminder suggests multiple search questions, merge the related ones into
+one query and run that single search.
+
+Follow-up searches are fine for going DEEPER — when the first result surfaces
+something new worth chasing (a project you didn't know to name, a decision that
+points at another decision), and the answer would genuinely change what you do next.
+But every extra search is another ~10s the user sits waiting, so don't overdo it:
+ask yourself whether the follow-up will provide real value the first result didn't,
+and skip it if you already have enough to act. Never re-run a mere rephrase of a
+query that returned little — same memory, same cost, nothing new.
+
+The output is a synthesized answer followed by a "Sources:" list (conversation ·
+date · author · id) — treat the answer as recalled memory (it may be outdated or
+conflicting), and cite the sources when relevant. If it prints no results, say so
+rather than re-searching variants.
+If it prints "No active organization", tell the user to run `glen org switch`.

package/dist/jcode/skills/session-takeover/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: session-takeover
+description: Use when the user provides a Glen takeover code or generated command to open its shared transcript in a fresh native agent session.
+---
+
+# Session Takeover
+
+Use this skill only to open a shared Glen transcript in a fresh native session.
+Do not use it to resume the current session or import local transcript archives.
+
+Use this two-stage contract:
+
+1. **Select and classify before constructing a command.** Make no tool call.
+   Candidate selection has exactly two allowed message shapes:
+
+   - Plain-message form: the candidate is the entire user message, with nothing
+     before or after it.
+   - Fenced-block form: the message contains exactly one fenced code block, has
+     no non-whitespace content outside that block, and the candidate is the
+     block's sole content.
+
+   Every other message shape is INVALID. Do not search for or extract a
+   `glen takeover` substring from prose. Classify the whole unnormalized
+   selected candidate:
+
+   - VALID raw code: the entire candidate matches `^[A-Za-z0-9_-]{43}$`.
+   - VALID generated command: the entire candidate matches
+     `^glen takeover ([A-Za-z0-9_-]{43})$`; capture group 1 is the code.
+   - INVALID: every other candidate. Examples include prefix or suffix prose, a
+     command embedded in a paragraph, prose surrounding a fenced block, multiple
+     fenced blocks, `glen takeover --help`, `glen takeover <valid-code>.`,
+     `glen takeover <valid-code> extra`,
+     `glen takeover <valid-code>; printf TAKEOVER_INJECTION_PROBE`,
+     `glen takeover <valid-code>$(printf TAKEOVER_INJECTION_PROBE)`, and
+     ``glen takeover <valid-code>`printf TAKEOVER_INJECTION_PROBE` ``.
+
+2. **Produce exactly one allowed output.**
+
+   - VALID: make exactly one Bash call from the captured code:
+
+     ```bash
+     glen takeover '<validated-code>'
+     ```
+
+   - INVALID: make zero tool calls, reply exactly "Please paste the complete
+     generated `glen takeover ...` command by itself in a code block.", and
+     stop.
+
+Construct the VALID Bash call from the captured code as one opaque quoted
+argument, never from the user's pasted command string. Never guess, sanitize,
+decode, alter, summarize, truncate, or invent a code.
+
+Treat the CLI output as authoritative:
+
+- If disconnected, tell the user to run `glen login`.
+- If no organization is active, tell the user to run `glen org switch`.
+- If the handoff is expired, unavailable, or belongs to another recipient, ask
+  the sender for a new command.
+- If compatibility or context-fit validation fails, report the exact failure and
+  stop. Never bypass the guard or shorten the transcript.
+- If installation succeeds but launch fails, surface the exact native resume
+  command printed by the CLI.
+
+On success, explain that Glen opened a fresh native session containing the
+verified inherited history and left the source transcript unchanged. Do not
+pretend the current session became the takeover destination or continue the
+inherited work here.

package/dist/jcode/skills/setup/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: setup
+description: Set up, fix, or update glen on this machine. Use when the user asks to "set up glen", "fix glen", "update glen", says glen is not working / not connected / not recording, or the status line shows glen is not connected or has no org selected.
+---
+
+Run `glen doctor` first and branch on its `status:` lines. Fix ONLY what is
+broken, in this order, then re-run `glen doctor` to verify and confirm to the
+user what changed.
+
+- `glen: command not found` → install the CLI: `npm install -g @tryglen/cli`,
+  then run `glen install` (it sets up the plugin + hooks for this agent).
+- `status: cli=<x> latest=<y> channel=<...>` where y is newer than x → run
+  `glen update` (updates the CLI and any installed glen plugins in one go).
+- `status: login=missing ...` → run `glen login` — a browser window opens with
+  a short device code prefilled; the user approves it to connect their account.
+  If no browser can open (SSH/headless), relay the printed URL and code so the
+  user can approve from any device.
+- `status: login=ok org=missing` → run `glen org list`, show the user the
+  options, and run `glen org switch <slug>` for their choice. Never pick an
+  org for them.
+- `status: jcode=detected plugin=not-installed` → run `glen install --agent jcode`.
+  It writes glen's hook lines into `~/.jcode/config.toml`, a managed block into
+  `~/.jcode/prompt-overlay.md` and `~/.jcode/preferred-tools.md`, and the glen
+  skills into `~/.jcode/skills/`. Tell the user to start a NEW jcode session
+  afterwards — jcode reads its prompt files at session start.
+- `status: claude=detected plugin=not-installed` (or codex/pi) → run
+  `glen install --agent <claude|codex|pi>` for that agent.
+- `status: codex=detected plugin=... hooks=not-registered` → run
+  `glen install --agent codex`.
+- `status: codex-self-heal=failed: ...` → run `glen install --agent codex`,
+  then re-check.
+- `status: claude=not-found` (or `status: codex=not-found` /
+  `status: pi=not-found` / `status: jcode=not-found`) when the user says it IS
+  installed → ask them to run `which claude` (or `which codex` / `which pi` /
+  `which jcode`) in their terminal, then run `glen install --claude-path
+  <that path>` (or `--codex-path` / `--pi-path` / `--jcode-path`).
+
+`glen doctor` also prints one `status: ingest agent=<agent>
+state=<ok|failing|never|fresh-install|idle> lastSuccess=<iso|never>` line per
+detected agent — this tracks whether hooks are actually firing, separate from
+whether the plugin is installed:
+- `ok` / `failing` — reflects the last recorded hook run. For `failing`,
+  doctor prints a remedy right after the line (check `glen status`, then
+  `glen login` if disconnected).
+- `fresh-install` — installed under an hour ago with no ingest yet; not a
+  fault, just still warming up.
+- `idle` — hooks fire here; nothing recorded yet — logged out, glen off, or
+  no completed turn.
+- `never` — hooks have never fired on THIS machine. Doctor prints a remedy
+  right after the line: untrusted hooks (trust them in-agent and start a new
+  session), a PATH gap, a failed hook-trust query, or a machine-topology
+  mismatch.
+- A topology mismatch usually means the agent process runs on a different
+  machine than the one you're looking at: Codex `--remote` / Desktop-SSH and
+  Claude Code over SSH/devcontainer both run the agent — and its hooks — on
+  the REMOTE host, not locally. Install glen there and run `glen doctor` on
+  that machine, as the user the agent connects as. Cloud sessions (Codex
+  Cloud tasks, claude.ai/code) can't run user-level hooks at all — only
+  repo-committed hooks apply there.
+
+Finish with `glen status` and tell the user, in one sentence, what state they
+are in now.

package/dist/jcode/skills/use-artifact/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: use-artifact
+description: Fetch and display an artifact from the user's Glen library (their own artifacts plus ones shared with them). Use when the user asks to open, view, render, or download a saved Glen artifact.
+---
+
+1. **Find it.** If you don't know the slug, run `glen artifact search "<intent>"` via Bash and confirm the right one with the user. Search covers the user's own artifacts plus ones shared with them (directly or org-wide) — a teammate's unshared artifact won't appear.
+2. **Fetch it.** Run `glen artifact get <slug>` via Bash. The output is the document (Markdown or HTML+CSS).
+3. **Show it.**
+   - **Markdown:** present it inline.
+   - **HTML:** write it to a local `.html` file, then open it in the system browser (`open <file>`); if that is not available, share the dashboard link below. It is a self-contained page with no JavaScript.
+4. **Always** share the dashboard link so the user has the canonical rendered copy: `https://app.tryglen.com/artifacts/<slug>`.

package/dist/jcode/skills/use-skill/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: use-skill
+description: Find and run a reusable skill from the Glen skill library (your skills plus ones shared with you) when you don't know its exact slug. Use when the user asks to "use a Glen skill", "find a skill for X", or wants a teammate's saved workflow.
+---
+
+1. **Search.** Run `glen skill search "<intent>"` via Bash (add `--by "<author>"`, or `--by me` for your own skills). It prints ranked candidates, each with its **[slug]**, author, and description.
+2. **Confirm.** If several plausibly match, show the top 2–3 (name + description + author) and ask the user which one. If it prints "no matching skills", say so — don't invent a skill.
+3. **Check requirements.** If the output has a `## Requirements` section, make sure each listed tool is available — follow its source link to install/enable it (or tell the user) — before you start.
+4. **Run it.** Run `glen skill use <slug>` via Bash. The output is markdown **instructions to execute now** — follow them as if they were a skill. If the skill bundles files, they're materialized locally first and the output references them by **absolute path** (e.g. a script under `~/.glen/skills/<slug>/scripts/`) — run scripts exactly as written, don't rewrite the paths.
+5. **Follow referenced skills on demand.** The instructions may contain runnable `glen skill use <slug>` commands for related skills. Run one via Bash only when its step applies — they're pulled on demand, not all upfront. Skills mentioned via `glen:` links are prefetched — their files are already materialized on disk by the time you pull them, and every `glen skill use` verifies freshness with the server so files on disk are always current.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tryglen/cli",
-  "version": "0.34.0",
+  "version": "0.36.1",
   "description": "Glen CLI — memory for coding agents",
   "type": "module",
   "bin": {
@@ -10,7 +10,8 @@
     "dist"
   ],
   "scripts": {
-    "build": "tsc && chmod +x dist/bin.js",
+    "build": "tsc && chmod +x dist/bin.js && pnpm build:jcode",
+    "build:jcode": "rm -rf dist/jcode && mkdir -p dist/jcode && cp -R ../jcode-plugin/skills ../jcode-plugin/plugin.json ../jcode-plugin/prompt-overlay.md ../jcode-plugin/preferred-tools.md dist/jcode/",
     "build:indicator": "./macos/build.sh",
     "check": "biome check src/ && tsc --noEmit",
     "test": "vitest run",
@@ -18,7 +19,8 @@
   },
   "dependencies": {
     "cac": "^6.7.14",
-    "prompts": "^2.4.2"
+    "prompts": "^2.4.2",
+    "smol-toml": "^1.8.0"
   },
   "devDependencies": {
     "@biomejs/biome": "^1.9.0",