Repository navigation
Conversation
# Conflicts: # src/bin.ts # src/run.ts
offerSightmapSetup only checked --mock before running the CLI provision + agent launch, so a --print-prompt run fell straight into the launch path (or, before the run.ts fix in the next commit, was skipped entirely by a stale printPrompt guard meant for plugin setup). Either way the authoring prompt never got printed, unlike the snippet and enrich prompts. Build the prompt up front and add a --print-prompt branch, checked ahead of --mock, that prints it the same way STEP 1/2 do and returns before touching the CLI install or agent launch.
offerSightmapSetup ran immediately after the snippet install (before the demo guide), independent of whether the user wanted to continue into the optional enrichment phase at all. That put it ahead of the first-ASR moment it's meant to build on, and made it an implicit fourth opt-in outside the "Step 2 of 2" framing. Moved the call in all three handoff paths (manual, GUI app, terminal) to run after the phase-2 enrichment prompt/follow-up, inside the same confirmContinueEnriching gate — so declining phase 2 also skips the sightmap offer, and accepting it runs as the last of four enrichment items instead of a standalone step. Updated the phase-2 note to list sightmap as item 4.
…ess run A real test run showed the sightmap authoring prompt getting stuck: every sightmap invocation (bare name and full path, version/--help/ validate) came back as an approval-required response with no way to grant it non-interactively, so the agent could never run validate or lint. Claude Code's headless launch runs with --permission-mode acceptEdits plus a hard --allowedTools list; anything off that list falls back to its normal approval prompt, which a -p run can never answer. sightmap wasn't on the list at all. Added scoped Bash entries for exactly the subcommands the authoring prompt uses: version, --help, validate, lint, browser start, snapshot, sel-probe. Left out a blanket `sightmap:*` on purpose — sightmap also has a `push` command that POSTs a corpus to an arbitrary URL and a `browser eval` that runs arbitrary JS in the page, which would hand a prompt injection the same exfiltration path the WebFetch domain scope above is already guarding against. Also switched the prompt's tooling check from `sightmap --version` to `sightmap version`, matching the CLI's own documented subcommand (and what the agent actually ran in testing), and updated the autonomy string shown at the pre-launch confirmation to mention it.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 1620af3. Configure here.
| 'Bash(sightmap lint:*)', | ||
| 'Bash(sightmap browser start:*)', | ||
| 'Bash(sightmap snapshot:*)', | ||
| 'Bash(sightmap sel-probe:*)', |
There was a problem hiding this comment.
Sightmap docs fetch is blocked
Medium Severity
The authoring prompt tells Claude Code to fetch https://docs.sightmap.org/start/quickstart when the sightmap-authoring skill is missing, but ALLOWED_TOOLS still scopes WebFetch to the two Fullstory domains. That fallback cannot run, so a failed skills install leaves the agent without the format reference the prompt calls the source of truth.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 1620af3. Configure here.
…ide effects Testing a wizard change meant a tradeoff between --print-prompt (skips the agent, but dumps the whole prompt to stdout every time) and a real run (exercises everything, but spawns a real autonomous agent for minutes on real tokens) or --mock (fast, but also skips real provisioning like the sightmap CLI install, so it can't catch install regressions). --stub-agent fills the gap: it skips launching the coding agent for every prompt (install, enrich, sightmap authoring) and logs a short "<step>: prompt ran!" instead of printing the prompt, but leaves real side effects alone — auth, snippet fetch, plugin CLI install, and notably the sightmap CLI provisioning (npm install -g + skills install), which now runs for real even under --mock. Wired into all three driveLaunch/launch call sites in run.ts and into offerSightmapSetup, which skips --mock's summary-only branch whenever --stub-agent is set so the real install still happens. src/test/helpers.ts gets the new required WizardOptions field.
Lead with what Sightmap is and why it helps, so people who don't know the term are less likely to decline.


What
Adds an optional sightmap step to the wizard: after the capture snippet install, offer to build a
.sightmap/component corpus so future Subtext session reviews name the app's UI components ("add-to-cart button") instead of showing raw CSS selectors.Follows the same handoff model as the main install — no bundled agent, the corpus is authored by the user's own coding agent — and mirrors the existing
offerPluginSetuppost-install pattern.Design choices
offerSightmapSetup), keeping the core snippet prompt lean and treating sightmap as a clearly-optional upsell.@sightmap/sightmapCLI (npm i -g+sightmap skills install), per the quickstart. The global install is deliberate — the agent's later skill calls invoke a baresightmap, so the binary has to be resolvable outside the wizard process.Changes
src/sightmap.ts—offerSightmapSetup(): confirm → optional dev-server URL → provision CLI → hand the chosen terminal agent a focused authoring prompt. Manual/GUI paths get an instructions note instead of a second launch. Never throws; mock mode prints "would run…".src/prompt/sightmap.ts+templates/sightmap-prompt.md— the authoring prompt. Live pass renders only when a URL is given; uses thesightmap-authoring/sightmap-browserskills when present, falls back to the docs.src/run.ts: wired into all three exit branches (terminal success, manual, GUI handoff) as the last item of the phase-2 "enrich your setup" offer, after identify/link-analytics/mask-PII rather than right after install.--sightmapflag (bin.ts/config.ts) — sightmap is offered interactively by default; this opts in for unattended--yesruns (off otherwise, since it installs a global and the live pass wants a running app).Notes / worth a look
seedcommand), so the terminal path fires a second, confirm-gated agent run. Heavier than a plugin-only path would be.npm i -gcan needsudoon some setups — handled with a fallback instructions note rather than an abort.Fixed after a real test run
--print-promptsilently skipped the sightmap step.offerSightmapSetuponly special-cased--mock, and the terminal path also had it nested inside a!printPromptguard meant for plugin setup, so a dry run never showed the authoring prompt at all. It now builds and prints the prompt the same way phase 1/2 do, then skips the CLI install and agent launch.sightmapinvocation (version,--help,validate) coming back as an unresolvable approval prompt, since Claude Code's headless launch only allowlistsnpm/pnpm/yarn/bun installand Subtext doc fetches for auto-approved Bash use. Added scoped allowlist entries for exactly the sightmap subcommands the authoring prompt uses (version,--help,validate,lint,browser start,snapshot,sel-probe): deliberately not a blanketsightmap:*, sincepushandbrowser evalcould otherwise become a prompt-injection exfiltration path the same way an unscoped WebFetch would.Sightmap support by install option
Whether the corpus actually gets authored and validated non-interactively depends on the install path; support isn't uniform:
validate/lint/live-coverage run headlessly?--full-autoauto-approves every command inside its workspace sandbox, so no extra allowlisting was needed.--approval-mode auto_editnever auto-approves shell commands, by design (not something this PR changes). The corpus YAML still gets written since file edits are auto-approved, butvalidate/lintand the live-coverage pass can't run non-interactively; the agent records what it couldn't finish insightmap-setup-report.md.isAutoDrivablerequires a terminal-kind agent with a binary), so the wizard shows copy-paste install and authoring instructions instead of launching anything. The user pastes this into their own interactive session and approves commands themselves, so this sidesteps the headless-approval problem entirely.Testing
npm run typecheck,npm run build, andnpx vitest run(53/53) clean.--mock --print-prompt --yes --sightmapconfirms the sightmap prompt now prints after the phase-2 enrichment prompt, and that its tooling check readssightmap version.Note
Medium Risk
Introduces global npm installs and a second autonomous agent run with scoped CLI permissions; core capture install is unchanged and sightmap errors are non-fatal.
Overview
Adds an optional post-enrichment step that offers to install
@sightmap/sightmap, provision authoring skills, and have the user’s coding agent seed a.sightmap/corpus so session reviews use semantic component names instead of raw selectors. Interactive runs get a confirm prompt (and optional dev-server URL for live coverage);--sightmapopts in when--yesskips prompts.The step runs after identify/link-analytics/mask-PII on terminal, GUI, and manual paths via
offerSightmapSetup; failures fall back to copy-paste instructions and never abort the wizard.Also adds
--stub-agentto exercise wizard flow without launching agents (still runs real sightmap CLI install when applicable), extends--print-promptto include the sightmap authoring prompt, and scopes Claude Code’s Bash allowlist to specific sightmap subcommands (not blanketsightmap:*) for headless authoring without openingpush/browser evalexfil paths.Reviewed by Cursor Bugbot for commit 055cbd6. Bugbot is set up for automated code reviews on this repo. Configure here.