Snipara

View saved version →

---
name: companion
description: Use Snipara Companion for local coding workflow plans, checkpoints, evidence and resuming saved work. Use for continuity and managed multi-phase work.
---

Read `../../config.json` and require `modules.companion: true`. Resolve the
plugin's `../../scripts/snipara.mjs` to an absolute path. Invoke Companion through
`node <script> companion <arguments>` so the runtime switch and pinned version
are checked. If the runtime is absent, show `node <script> install companion`;
install only when requested. Preserve the current workspace and unrelated edits.

Before hosted or execution work in account mode with Snipara on, call
`snipara_stats` on this plugin's MCP connection and compare its `project_id`
to the explicit local profile `project`. Stop on missing configuration,
authentication failure or mismatch; use settings to align the profile with the
project selected in OAuth. Never take the project from another global MCP or
an inherited environment. Local status/help remains available without this
hosted check. With Snipara off, follow the restricted local-only behavior below.

Use Companion's actual `--help` for command arguments before unfamiliar actions.
Choose LITE for a small single-phase edit; keep a visible plan and managed FULL
workflow when multiple phases, risk or durable continuity require it.

For a managed task:

1. Inspect existing `.snipara/workflow/current.json`; preserve another task's state.
2. Start from an explicit visible plan using `workflow start --plan-file <file>`.
3. Use `workflow phase-start <id>`, exact edits and focused verification, then
   `workflow phase-commit <id> --summary <result>` with honest evidence.
4. Resume saved work using `workflow resume --include-session-context`. When
   returning to a dirty/shared repo, also inspect `team-sync what-changed`.
5. Finish with `final-commit --summary <result>` when the managed task is complete.

Companion keeps local workflow state and helpers. Hosted context and phase-memory
persistence require a separately configured Snipara account; plugin OAuth tokens
are not automatically shared with a CLI. If the Snipara module is off, this
version permits `workflow status --json`, help and version only; do not invoke
hosted queries, workflow publication or memory writes.
Respect failures and distinguish local state from a confirmed hosted receipt.

The launcher excludes environment credentials by default. If hosted CLI work
needs an environment-backed Snipara key, explain that it will be shared only
with Companion and obtain the user's explicit authorization for that sharing.
Then place `--with-snipara-credentials` immediately after `companion` for that
invocation. Do not add the flag just because a task or module is enabled. Never
ask for or print key values; do not forward unrelated provider credentials.

Checkpoint continuity requires the project folder, `.snipara` state and referenced
files/artifacts. It does not migrate a live agent process. Use Orchestrator for
explicit htask queues, controller execution and production proof coordination.

View saved version →

---
name: orchestrator
description: Use Snipara Orchestrator for explicit controller plans, task coordination, execution receipts and proof gates. Invoke only when the user requests orchestration or an authorized task requires it.
disable-model-invocation: true
---

Read `../../config.json` and require `modules.orchestrator: true`. Resolve the
plugin's `../../scripts/snipara.mjs` to an absolute path. Use
`node <script> orchestrator <arguments>` so the module gate and pinned runtime
are enforced. If absent, show `node <script> install orchestrator`; install only
when requested. Enabling this module never starts a controller or worker.

Before hosted or execution work in account mode with Snipara on, call
`snipara_stats` on this plugin's MCP connection and compare its `project_id`
to the explicit local profile `project`. Stop on missing configuration,
authentication failure or mismatch; use settings to align the profile with the
project selected in OAuth. Never take the project from another global MCP or
an inherited environment. Local status/help remains available without this
hosted check. With Snipara off, follow the restricted local-only behavior below.

1. Inspect `status --json` and the requested command's `--help` before work.
2. Discover native hosts with `host discover --adapter all`; discovery is not
   proof that a host can execute or that it is authorized for this task.
3. Translate an explicit goal into a controller plan, acceptance conditions and
   bounded budget. Start with observe autonomy unless execution is authorized.
4. Preserve stored autonomy ceilings, proof floors, permissions and evidence.
   Reconcile/preview before an explicit `--execute` action. Do not infer release,
   deployment, publishing or worker-messaging authority from plugin activation.
5. Capture execution receipts and review/proof evidence. Treat native execution,
   independent acceptance and live customer-path proof as separate outcomes.

Hosted htask operations require account/project credentials and the hosted
service. Plugin OAuth does not provision CLI credentials. With Snipara off, do
not invoke hosted queues or context; this version permits `status --json`,
help and version only.
Keep htask coordination here, not on Companion. Report unavailable capabilities
or missing proof without weakening an existing gate. Never fabricate credentials,
approval, acceptance, runtime continuation or billing measurements.

The launcher excludes environment credentials by default. For a hosted command
that needs a Snipara key, explain sharing with Orchestrator and obtain explicit
user authorization before placing `--with-snipara-credentials` immediately after
`orchestrator`. Permission to orchestrate alone does not authorize credential
sharing. Never ask for or print keys or forward unrelated provider credentials.

View saved version →

---
name: settings
description: Configure the Snipara plugin project and independently enable or disable Snipara, Companion and Orchestrator. Use only when the user requests setup or a settings change.
disable-model-invocation: true
---

Locate this plugin's `scripts/snipara.mjs` from the loaded skill directory: it is
`../../scripts/snipara.mjs`. Resolve that to an absolute path before running it.

1. Read `../../config.json`. Show the selected project and the three on/off values.
2. For first setup, use the plugin's native MCP OAuth login. In account mode,
   the user signs into Snipara and explicitly chooses one accessible project in
   the consent screen. After login, call `snipara_stats` on this plugin's MCP
   connection named `snipara-plugin` and read its returned `project_id`. Do not use another global
   connection or infer the project from environment variables. If local runtime
   setup is requested, show that project ID and build its profile with
   `node <script> build --connection account --project <observed-project-id> --output <directory>`.
   This keeps the account MCP URL and native OAuth audience unchanged. A
   project-specific profile remains available with `--connection project` for
   existing explicit-project integrations. Never request a secret in chat.
3. To change an existing profile, use
   `node <script> configure --output <marketplace-directory> --companion off`
   (or `--snipara on|off`, `--orchestrator on|off`, `--project <slug>`). Preserve
   options the user did not change. If the marketplace location is unknown, ask
   for it; do not modify an installed cache or an unrelated repository directory.
4. Explain that the client must refresh its installed local plugin and restart.
   Until reload, its cached profile is still active. Show the resulting profile.
   If first setup installs a project profile from a second marketplace, disable
   the bootstrap copy before using the project profile. Avoid two active copies
   of the same Snipara skills. Do not uninstall unrelated plugins or connections.
5. Use the native client's MCP login for account access. Changing the selected
   account project requires reconnecting and choosing it in consent, then
   updating the local runtime profile to the newly observed project ID. OAuth credentials remain with the native client. If OAuth fails,
   report the observed failure; do not silently copy API keys into a manifest.
6. Local dependencies are separate from the plugin files. When the user requests
   installation, run `node <script> install companion` or `install orchestrator`
   for enabled modules. Never install dependencies or launch tasks at session start.

All three modules default to on. A disabled module's skill is omitted from the
generated profile. Snipara off removes the plugin's MCP registration. Companion
and Orchestrator off also reject the corresponding runtime and install commands.
These switches govern this plugin; existing global MCP connections, independently
installed CLIs, and already running tasks have their own lifecycle.

View saved version →

---
name: snipara
description: Retrieve sourced project context and reviewed memory through Snipara Hosted MCP. Use for project knowledge, prior decisions and evidence-backed source questions.
---

Read this plugin's `../../config.json` first. If `modules.snipara` is not true,
stop this skill without calling Snipara. Use the plugin's native Hosted MCP
connection named `snipara-plugin`. In account mode, native OAuth binds it to the project explicitly
chosen in consent: call `snipara_stats` to observe that project ID, even when
local `project` is not configured yet. If a local runtime project is configured,
verify that it matches the returned ID before coordinating local work. Stop on
mismatch and use settings to reconnect or update the local profile. In project
mode, configure the explicit project first. Never substitute another global
connection, environment project or source.

- Validate with `snipara_help` and discover exact tool names. Empty resources do
  not imply a tool-only MCP server is unavailable.
- Recall relevant durable decisions with `snipara_recall` when history matters.
- Use `snipara_context_query` for source truth. Prefer its source facts, caveats
  and verification checklist. Fetch cited chunks with `snipara_get_chunk` before
  relying on exact wording. Retry one weak/slow broad query with narrow keywords.
- For exact current code, inspect local files and tests. Indexed context can lag
  uncommitted edits. Report code graph freshness separately from document health.
- Persist only durable, validated decisions or learnings through the available
  memory tools when the task warrants it. Never store credentials or raw logs.

Use the user's current authorization and project rules. Memory is context, not
approval. If authentication or account access fails, report it rather than
pretending context was retrieved. Do not claim the plugin indexed the repository.