Editor installs
Snipara has one activation doctrine across editor marketplaces, public docs, and README setup instructions: install Snipara, open your project, and give the agent live project context in under a minute.
create-snipara is the canonical agent bootstrap. Native editor extensions can expose a better UI, but they should activate the same Hosted MCP project context and avoid inventing a separate setup story.Doctrine checklist
- One shared activation engine, multiple editor entry points.
- Hosted MCP is the agent path; direct editor extensions are UI and command surfaces.
- First value should come from the user's current workspace, not a generic demo.
- Companion is the continuity layer after the first workspace brief, not the editor install itself.
- Marketplace copy, docs pages, and README setup instructions should point to the same next step for each editor.
Surface map
| Surface | Entry point | User action | Role |
|---|---|---|---|
| create-snipara | Terminal bootstrap | Run npx create-snipara from the repository root. | Canonical activation engine for agent setup, Hosted MCP config, local source scan, First Work Brief, and client-specific files. |
| VS Code | Native editor command | Install the extension, then run Snipara: Activate Workspace. | Editor-first activation for users who expect visible progress, source-backed briefing, and Copilot handoff inside VS Code. |
| Cursor | Extension plus Hosted MCP | Install the OpenVSX extension for UI, then use create-snipara for the agent MCP path. | Lightweight editor surface; Cursor chat should consume the same Hosted MCP project context instead of a separate activation model. |
Copy rules
Marketplace listings
Lead with the editor action users can take immediately. VS Code should say Install, then run Snipara: Activate Workspace. Cursor should say Install the OpenVSX extension for editor UI, then connect Cursor chat through Hosted MCP.
README setup sections
Keep README wording short and point back to this page plus the surface-specific docs. Avoid duplicating long MCP JSON snippets unless the reader is configuring a low-level client manually.
VS Code docs
Treat the extension as the native activation surface. The expected first success state is a source-backed First Work Brief in the editor, with Copilot handoff available after activation.
Cursor docs
Keep Cursor lightweight: extension for commands and UI, Hosted MCP for agent chat, and create-snipara for generated project guidance and validation.
Canonical wording
Snipara uses one shared activation engine across supported editors. The entry point can be a terminal installer, a VS Code command, or a Cursor extension flow, but the result should be the same: Hosted MCP connected to the project, local context indexed, and the next agent session grounded in the workspace the user actually opened.
Machine contract for editors
Editor extensions should call the activation engine and read the generated contract. They should not reimplement source scanning, First Work Brief generation, memory-candidate extraction, or Hosted MCP config semantics.
npx create-snipara@latest init --client vscode --starter --json.snipara/activation/activation-manifest.jsonartifacts.firstBriefPathlanes.*.status and nextActionsAfter activation
The editor install should create the first moment of value. Longer work moves into the same Companion continuity loop regardless of entry point.
snipara-companion session-bootstrap --include-session-context --max-context-tokens 1000snipara-companion source sync --jsonsnipara-companion code impact --changed-files src/app.ts --diff-summary "next edit"snipara-companion task-commit --summary "completed durable change" --files src/app.ts