Install — Rosetta plugins + graph content

Welcome. This guide gets the Rosetta plugin set running on your machine. The whole thing is two steps: get your free API key from your rosetta-design.com account (about two minutes — §2.1 walks you through it), then run one install command (§3). The install bundle ships all seven plugins, the canonical graph content, and the evidence manifest in a single tarball.

Prefer a guided version with OS-specific tabs (macOS / Windows, Claude Desktop and claude.ai wiring included)? Once you're signed in, the same walkthrough lives at rosetta-design.com/help.

Producer-side contract: contracts/install-bundle.md. Release runbook (operator-facing): docs/runbooks/release-cut.md. Driving DTs: the RATIFIED files under docs/decision-traces/install-bundle-*.md. The no-flag default is a project-scoped install per docs/decision-traces/install-bundle-project-scope-default.md (RATIFIED 2026-06-03, Option C).

1. What you get

Seven plugins for Claude Code or Cowork, plus the graph content they reference:

Plugin	Slash-command surface	Purpose
rosetta-research	/rosetta-research:* (six stages + /rosetta-research:run-all)	Canonical content pipeline. Takes an uploaded rosetta-platform snapshot + a target product family; produces graph-ready Cypher seeds for ContextPattern, BusinessIntent, VocabularyTerm, SemanticEntity, PlatformObject, EngineFunction.
rosetta-archaeology	/rosetta-archaeology:* (four phases)	Engagement archaeology pipeline. Takes a discovery dossier + a repo snapshot; produces an engagement-scoped Digital Twin with Context Artifacts, DecisionTraces, and a PromotionCandidate analysis.
rosetta-agent	/rosetta-agent:* (query, record, engagement, twin, govern, canvas)	Live retrieval-grounded answers from the Rosetta Data-360 graph at api.rosetta-design.com. Additional runtime setup required beyond what this installer provides — see §2.5.
engagement-codex	/engagement-codex:* (tone variants)	Renders a Solution Thesis from engagement graph state across four tones: audit, seller, customer, leadership.
engagement-rehearsal	/engagement-rehearsal:* (rehearse / eval / run-all)	Persona conversation simulator for engagement gap-filling. Read-only against the graph; live mode reuses rosetta-agent's MCP server, with an offline-deterministic fallback.
engagement-authoring	/engagement-authoring:*	Authoring-reference skills that teach an agent to correctly hand-construct the engagement-scoped payloads (engagement creation, twin documents) before writing them.
d360-distiller	/d360-distiller:* (bind / audit / render / validate / run-all)	Seed-to-skill distillation pipeline. Compiles the governed Data 360 knowledge into task-level builder skills on the Salesforce d360_* MCP surface.

Plus:

• db/seeds/ — canonical Cypher seeds the plugins reference (ContextPattern corpus, ADR projections, BusinessIntent vocabulary, etc.).
• docs/evidence/document-inventory.csv — manifest of source documents the plugins consume during authoring runs. The documents themselves live in a Drive corpus accessed via Cowork's Drive integration (per docs/decision-traces/evidence-corpus-location.md) — the install bundle ships the manifest, not the binaries.
• MANIFEST.txt — pinned per-plugin versions for the release you installed.

2. Prerequisites

2.1 Your Rosetta API key (required)

The install bundle ships behind authentication, and your key comes from your own rosetta-design.com account. Here's the whole journey:

1. Create your account. Go to rosetta-design.com and click Sign in → Register. Complete the enrollment (you'll verify your email address), then sign in.
2. Generate your key. Open Settings, find the API Keys card, and click Generate New Key. Give it a name you'll recognize later (e.g. laptop install) and click Generate.
3. Copy it immediately. The full rsk_… key is shown once — use Copy or Download JSON before closing the dialog. If you miss it, no harm done: just generate another.

Then export it in your shell startup file:

# in ~/.bashrc or ~/.zshrc
export ROSETTA_API_KEY=rsk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Do not commit the key. Do not paste it into chat with Claude. The install script reads it from your environment; the model never sees it.

2.2 Runtime

You need Claude Code OR Cowork installed. The plugins load into either runtime via that runtime's plugin loader; both runtimes read the same flat plugin layout.

• Claude Code: install per the upstream Anthropic docs.
• Cowork: install via the standard Cowork onboarding.

2.3 (Optional) Neo4j for the graph content

The db/seeds/ payload is canonical Cypher you load into a Neo4j instance. If you don't have one, the seeds sit on disk unused until you do — the plugins themselves run without a local graph (they accept uploaded snapshots and produce Cypher; loading the output is a downstream step).

Compatible Neo4j substrates:

• Neo4j Aura (free tier works for evaluation).
• Local Docker via docker run neo4j:5-community or the neo4j image of your choice.
• The rosetta-platform repo's own make neo4j-up if you've cloned the producer repo for other reasons.

Loading the seeds requires cypher-shell or an equivalent client; the install bundle does not ship a loader. If you want a turnkey loader, clone the producer repo and use make seed-load — but for an install-bundle-only install, the seeds are reference material until you wire your own loader.

If you don't want the graph content at all, install with --no-data and skip this section.

2.4 (Optional) Cowork Drive integration for the evidence corpus

The plugins reference source documents in their authoring outputs (evidenceSources fields on every canonical node). The documents themselves are in the operator's Drive; Cowork's Drive integration authenticates plugin sessions to fetch them.

If you're running Claude Code (not Cowork), the evidenceSources references work as provenance but you can't dereference them to the underlying documents. This is intentional and matches the producer-only contract — the plugins are usable without Drive access; the documents are upstream input.

2.5 rosetta-agent runtime setup (if you'll use rosetta-agent)

The rosetta-agent plugin shipped in the bundle is not self-contained. It spawns a local rosetta-mcp-server binary that holds a bearer token and talks HTTPS to api.rosetta-design.com. None of these are installed by this bundle. If you intend to use /rosetta-agent:query or /rosetta-agent:record, follow util/plugins/rosetta-agent/references/install-guide.md §2.2–§2.3 for:

• Installing the rosetta-mcp-server binary from github.com/vernonkeenan/rosetta-mcp-server.
• Obtaining a bearer token under the agent-harness scope (distinct from your plugin-install scope; same KMS issuer).
• Exporting ROSETTA_AGENT_TOKEN in your shell.

If you don't intend to use rosetta-agent, the plugin files install harmlessly and the slash commands fail closed with [ConfigurationError] until the runtime prereqs land.

2.6 Network

Outbound HTTPS to:

• rosetta-design.com — to fetch the install tarball + script.
• api.rosetta-design.com — (rosetta-agent only) the upstream graph API.

If you're behind a corporate proxy, confirm both hostnames are reachable before proceeding.

3. Install

Two install shapes are supported. Both pull from rosetta-design.com behind KMS auth (Shape A reads its script from a local checkout; Shape B fetches it from the route). Pick whichever fits your context.

3.0 Scope — where the install lands

The no-flag default is a project-scoped install into the current directory's ./.claude/ tree (per docs/decision-traces/install-bundle-project-scope-default.md). Two scopes are available:

Scope	How to select	Plugins land at	Data lands at	settings.json merged
project (default)	nothing, or --project / SCOPE=project	./.claude/plugins/	./.claude/rosetta/	./.claude/settings.json
user (machine-wide)	--user (alias --global) / SCOPE=user	~/.claude/plugins/	~/.claude/rosetta/	~/.claude/settings.json

The installer merges the rosetta marketplace and enables the seven plugins in the scope's settings.json so the plugins load on the next runtime restart — no manual /plugin marketplace add + enable step. The merge is non-destructive (every other key in the file is preserved) and idempotent (re-running is a no-op). See §4 for the resulting tree and §6 for re-run behavior.

The wizard. On an interactive first-touch run (a readable /dev/tty and no --yes), the installer prints a short orientation — it is installing into this project at ./.claude/, and you can pass --user for a machine-wide install at ~/.claude/ instead — then runs a brief wizard (confirm scope, offer to skip the graph content). Because the wizard reads from /dev/tty rather than stdin, it works under curl … | bash (where stdin is the script source). A non-interactive run (no readable /dev/tty, or --yes) skips the wizard and uses project scope silently unless you passed --user/--global.

Override anything. --target, --data-target, and --settings each override the scope-derived default independently; an explicit flag always wins over the scope default.

3.1 Shape A — make install-plugins (cloned-repo users)

If you've cloned rosetta-platform for any reason, run (from the project directory you want the install to land in):

make install-plugins VERSION=v0.18.0

Make reads $ROSETTA_API_KEY from your environment and threads it through to the install script. With no SCOPE, this is a project-scoped install into ./.claude/:

• TARGET=./.claude/plugins/ (plugin extraction parent)
• DATA_TARGET=./.claude/rosetta/ (seed/evidence/manifest parent)
• SETTINGS=./.claude/settings.json (merged in place)

For a machine-wide install, pass SCOPE=user (the knob threads through to the installer as --user):

make install-plugins VERSION=v0.18.0 SCOPE=user
   # → ~/.claude/plugins/, ~/.claude/rosetta/, ~/.claude/settings.json

SCOPE=project (the default) and SCOPE=global (alias for user) are also accepted.

Override individual paths independently. Extra installer flags pass through via INSTALL_PLUGINS_FLAGS (Make consumes positional arguments itself, so flags need that envelope):

make install-plugins VERSION=v0.18.0 TARGET=/somewhere/plugins/
make install-plugins VERSION=v0.18.0 DATA_TARGET=/somewhere/data/
make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--no-data"        # plugins only
make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--no-plugins"     # data only
make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--no-register"    # copy files only; skip settings.json merge
make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--settings /path/to/settings.json"  # explicit settings path
make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--yes"            # non-interactive (project scope, no wizard)
make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--dry-run"        # preview only

For the latest release (alias for whatever was most recently published), omit VERSION:

make install-plugins   # → /install/latest/install.tar.gz

3.2 Shape B — curl … | bash (no clone required)

Fetch the tag-pinned install script directly from the KMS-protected route. Run it from the project directory you want the install to land in — the no-flag default is project scope (./.claude/), and the wizard reads from /dev/tty so it still prompts under the pipe:

# Pinned to a specific tag — project-scoped into ./.claude/
curl -fsSL -H "Authorization: Bearer ${ROSETTA_API_KEY}" \
  https://rosetta-design.com/install/v0.18.0/install-plugins.sh \
  | bash -s -- --version v0.18.0

For a machine-wide install, add --user:

curl -fsSL -H "Authorization: Bearer ${ROSETTA_API_KEY}" \
  https://rosetta-design.com/install/v0.18.0/install-plugins.sh \
  | bash -s -- --version v0.18.0 --user

For the latest release:

curl -fsSL -H "Authorization: Bearer ${ROSETTA_API_KEY}" \
  https://rosetta-design.com/install/latest/install-plugins.sh \
  | bash

Same scopes, defaults, and flags as Shape A (--project / --user / --global, --target, --data-target, --settings, --no-register, --no-data, --no-plugins, --yes/--force, --dry-run, --verbose). The script served from /install/<tag>/install-plugins.sh is byte-identical to scripts/release/install-plugins.sh at the tagged tree (CI asserts the SHA match) — fetch it, audit it before piping if you prefer:

# audit-before-pipe variant
curl -fsSL -H "Authorization: Bearer ${ROSETTA_API_KEY}" \
  https://rosetta-design.com/install/v0.18.0/install-plugins.sh -o install.sh
less install.sh                # read it
bash install.sh --version v0.18.0

Both shapes verify the install tarball's SHA-256 sidecar before extracting; neither will silently install a tampered payload.

3.3 Docker production builds

Pin a tag explicitly — never /install/latest/ — in any production Dockerfile, or your image rebuilds are not reproducible across time:

# syntax=docker/dockerfile:1
RUN --mount=type=secret,id=rosetta_api_key \
    curl -fsSL -H "Authorization: Bearer $(cat /run/secrets/rosetta_api_key)" \
    https://rosetta-design.com/install/v0.18.0/install.tar.gz \
    | tar -xz -C /opt/rosetta/

The rosetta-design.com routes set Cache-Control: immutable on /install/<tag>/* and Cache-Control: no-cache on /install/latest/* so the immutability contract is enforced at the HTTP layer too.

4. What lands where

After a successful default (project-scoped) install, run from your project root:

<project-root>/.claude/
├── settings.json               (created or merged: rosetta-plugins
│                                 marketplace + enabledPlugins for the
│                                 seven plugins; all other keys preserved)
├── plugins/
│   ├── .claude-plugin/
│   │   └── marketplace.json     (all seven plugin entries; name 'rosetta-plugins')
│   ├── rosetta-research/        (full plugin tree)
│   ├── rosetta-archaeology/     (full plugin tree)
│   ├── rosetta-agent/           (full plugin tree; runtime setup per §2.5)
│   ├── engagement-codex/        (full plugin tree)
│   ├── engagement-rehearsal/    (full plugin tree)
│   ├── engagement-authoring/    (full plugin tree)
│   └── d360-distiller/          (full plugin tree)
└── rosetta/
    ├── db/seeds/                (canonical Cypher seeds)
    ├── docs/evidence/
    │   └── document-inventory.csv
    └── MANIFEST.txt             (per-plugin version pins)

With --user (Make: SCOPE=user) the same tree lands under your home directory instead, machine-wide:

~/.claude/
├── settings.json               (created or merged, as above)
├── plugins/
│   └── …                        (same seven-plugin layout)
└── rosetta/
    └── …                        (db/seeds/, docs/evidence/, MANIFEST.txt)

settings.json is created or merged, not just copied. The installer writes the rosetta-plugins marketplace into .extraKnownMarketplaces and sets .enabledPlugins["<plugin>@rosetta-plugins"] = true for each of the seven plugins, so the runtime loads them on the next restart with no manual /plugin marketplace add step. Every other key in your settings.json is left untouched. In the pure project default (no explicit --target/--settings) the marketplace path is written relative (./.claude/plugins); otherwise it is written as the absolute realpath of the resolved plugin target. If you passed --no-register (or --no-plugins), the merge is skipped and you wire up the marketplace manually (see §8). If jq is not installed, the installer warns, skips the merge, and prints the exact JSON snippet to paste into your settings.json by hand.

MANIFEST.txt records the per-plugin versions pinned by this release:

platform-tag:      v0.18.0
generated-at:      2026-05-30T12:34:56Z
plugins:
  d360-distiller: v0.1.0
  engagement-authoring: v0.1.0
  engagement-codex: v0.10.2
  engagement-rehearsal: v0.1.1
  rosetta-agent: v0.6.3
  rosetta-archaeology: v0.9.1
  rosetta-research: v0.14.2
seed-corpus-sha:   sha256:abc123…
evidence-csv-rows: 106

If you need to confirm what you installed (e.g., for a bug report), cat ./.claude/rosetta/MANIFEST.txt (project scope) or cat ~/.claude/rosetta/MANIFEST.txt (--user scope) is the answer.

5. First-run verification

Restart your runtime (Claude Code: exit + relaunch; Cowork: relaunch the client) so the plugin loader picks up the new plugin directories. For a project-scoped install, relaunch Claude Code in the project directory you installed into — the merged ./.claude/settings.json is what registers the rosetta-plugins marketplace and enables the seven plugins, so no manual /plugin marketplace add step is needed.

Each plugin has a simple verification path:

rosetta-research:

/rosetta-research:product-family-research

The command's intake skill prompts you for a rosetta-platform snapshot zip and a target product family. If the command is listed in your runtime's slash-command palette, the plugin is loaded.

rosetta-archaeology:

/rosetta-archaeology:survey

Same shape — prompts for a repo snapshot and discovery dossier.

engagement-codex:

/engagement-codex:render-solution-thesis

Prompts for engagement context + tone. The four supported tones are audit, seller, customer, leadership.

rosetta-agent:

/rosetta-agent:query What patterns exist for Customer 360?

Expect a response that names one or more ContextPatterns with the [Pattern: <displayId>] citation shape. If you see [ConfigurationError] missing ROSETTA_AGENT_TOKEN or mcp-server binary not found, the runtime prereqs in §2.5 aren't done yet — the plugin file install is fine; finish §2.5 and re-test.

engagement-rehearsal:

/engagement-rehearsal:rehearse

Prompts for an engagement key, then role-plays the six personas to propose gap closures. Read-only against the graph — it proposes, you apply. Live mode reuses rosetta-agent's MCP server (§2.5); without it the plugin degrades to an offline-deterministic run behind a loud degradation banner, so it still loads on the install bundle alone.

engagement-authoring:

/engagement-authoring:engagement-creation

Loads the authoring-reference skill for hand-constructing engagement-creation payloads. Its sibling is /engagement-authoring:twin-authoring.

d360-distiller:

/d360-distiller:run-all

Prompts for the distillation inputs (the bind / audit / render / validate stages are also individually addressable).

What success looks like. Each command appears in your runtime's slash-command palette / /help. Invoking it triggers the plugin's intake skill; you don't have to complete an end-to-end run to confirm the install — the command being present is the install-success signal.

What failure looks like. The slash commands don't appear in /help. See §8 (troubleshooting) below.

6. Updating

For a specific release (substitute the tag you want):

make install-plugins VERSION=v0.18.0

For whatever is current right now:

make install-plugins                # → /install/latest/

The installer overwrites the existing plugin directories and data files in place by default, printing a warning that names the affected entries (pass --yes/--force to suppress that warning in scripted runs). There is no prompt and no flag required to refresh an existing install (see docs/decision-traces/install-bundle-default-overwrite.md). Re-run in the same scope you installed into (project by default, or SCOPE=user / --user for a machine-wide install) so the update lands where the existing install lives.

The settings.json merge is idempotent: re-running updates the rosetta-plugins marketplace entry and the seven enabledPlugins keys in place and leaves every other key untouched, so a second run produces a byte-identical file. Re-running an update is always safe.

If you've hand-edited any installed plugin or data file, back it up first — the installer is a copy mechanism for files (not a merge tool). The copy-not-merge rule applies to the plugin trees and db/seeds/; only settings.json is merged.

7. Uninstalling

The installer doesn't ship an uninstall target; the install layout is plain directories that you remove with standard tools. Substitute the scope root you installed into — ./.claude for a project install (the default), ~/.claude for a --user install:

# project scope (default) — run from the project root:
rm -rf ./.claude/plugins/rosetta-research
rm -rf ./.claude/plugins/rosetta-archaeology
rm -rf ./.claude/plugins/rosetta-agent
rm -rf ./.claude/plugins/engagement-codex
rm -rf ./.claude/plugins/engagement-rehearsal
rm -rf ./.claude/plugins/engagement-authoring
rm -rf ./.claude/plugins/d360-distiller
rm -rf ./.claude/plugins/.claude-plugin
rm -rf ./.claude/rosetta

The installer also merged the rosetta-plugins marketplace and the seven enabledPlugins keys into that scope's settings.json. The plugin files being gone is enough to stop the slash commands from loading, but to fully clean up, edit ./.claude/settings.json (or ~/.claude/settings.json for --user) and remove the rosetta-plugins entry from .extraKnownMarketplaces and the seven "<plugin>@rosetta-plugins" keys from .enabledPlugins. Leave every other key in place.

Restart your runtime to clear the slash-command palette.

8. Troubleshooting

HTTP 401 Unauthorized from the install route.

Either ROSETTA_API_KEY isn't set in the shell that ran the installer, or the key has been revoked. Confirm:

echo "${ROSETTA_API_KEY:+set}"   # should print: set

If empty, re-export per §2.1 and re-run in the same shell. If set but still 401, request a new key from the cohort channel — yours may have been revoked or rotated.

HTTP 403 Forbidden from the install route.

Your key is valid but lacks the plugin-install scope. Cohort participants get this scope by default; if you only have an agent-harness key (rosetta-agent runtime scope), you can't use it to fetch the install bundle. Request a plugin-install-scoped key.

The slash commands don't appear in /help after restart.

Confirm the plugin directories exist at the scope you installed into (./.claude/plugins/ for a project install — the default; or ~/.claude/plugins/ for a --user install):

ls ./.claude/plugins/
   # expect: rosetta-research/  rosetta-archaeology/  engagement-codex/  rosetta-agent/  engagement-rehearsal/  engagement-authoring/  d360-distiller/  .claude-plugin/

If they're missing, the install failed silently — re-run with verbose output: make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--verbose" (Shape A) or add --verbose to the curl-piped script's trailing arguments after --.

If they're present but the commands don't appear, confirm each plugin's .claude-plugin/plugin.json exists at its root:

cat ./.claude/plugins/rosetta-research/.claude-plugin/plugin.json

If the JSON is malformed or missing, the tarball extracted partially. Re-install.

For a project-scoped install, also confirm you relaunched Claude Code in the project directory — project-scope plugins load from ./.claude/settings.json, which only applies when the runtime is started in that directory.

The slash commands still don't appear (files present, restarted in the right directory).

This is almost always the settings.json registration step. Confirm the scope's settings.json carries both the rosetta-plugins marketplace and the seven enabledPlugins keys:

cat ./.claude/settings.json   # or ~/.claude/settings.json for --user
   # expect, alongside your other keys:
   #   .extraKnownMarketplaces."rosetta-plugins" = { "source": { "source": "directory", "path": "./.claude/plugins" } }
   #   .enabledPlugins."rosetta-research@rosetta-plugins"     = true
   #   .enabledPlugins."rosetta-archaeology@rosetta-plugins"  = true
   #   .enabledPlugins."engagement-codex@rosetta-plugins"     = true
   #   .enabledPlugins."rosetta-agent@rosetta-plugins"        = true
   #   .enabledPlugins."engagement-rehearsal@rosetta-plugins"  = true
   #   .enabledPlugins."engagement-authoring@rosetta-plugins"  = true
   #   .enabledPlugins."d360-distiller@rosetta-plugins"       = true

If those keys are absent, the merge was skipped. The two reasons:

• jq was not installed when you ran the installer. The installer warns, skips the merge, and prints the exact JSON snippet to add by hand — re-run and copy that snippet into your settings.json, or install jq and re-run (the merge is idempotent and safe to repeat).
• You passed --no-register (or --no-plugins), which copies the files but intentionally skips the merge. Re-run without those flags, or add the keys above by hand.

The marketplace path is relative (./.claude/plugins) for a pure project default and absolute otherwise — either form loads, as long as a relative path resolves against the project root you launch Claude Code in. The marketplace name (rosetta-plugins) and the plugin names in the enabledPlugins keys come straight from ./.claude/plugins/.claude-plugin/marketplace.json (.name and .plugins[].name); if you hand-author the snippet, match that file.

SHA-256 mismatch during install.

The installer aborts before extracting if the tarball's hash doesn't match the published .sha256 sidecar. This means either (a) the download was truncated — re-run; or (b) the release was re-cut and the hash legitimately changed. Compare your local <tarball>.sha256 against https://rosetta-design.com/install/<TAG>/install.tar.gz.sha256 (with your Authorization: Bearer header) to disambiguate.

The installer refuses to run, citing a "producer working tree".

You ran the installer from inside a rosetta-platform clone. With the project-scope default the installer fingerprints the project root (the nearest existing ancestor of the target — typically $(pwd)), not the not-yet-created ./.claude/plugins/, so it refuses even on a fresh in-repo run rather than clobbering the producer's own tree. The fingerprint set is unchanged (docs/rosetta-platform.spec-manifest.md + contracts/app-server-intake.md + util/plugins/ + db/seeds/ at the git toplevel). Run the installer from a different directory — a fresh project folder for a project-scoped install, or pass --user for a machine-wide install into ~/.claude/.

Cowork can't find the plugins after I upload the bundle.

Cowork doesn't consume the install tarball directly — for Cowork, upload each plugin's <plugin>-<version>.zip via the Cowork plugin settings UI individually. The install tarball is the Claude Code consumption surface; Cowork's per-plugin upload flow remains the Cowork-specific install path.

The per-plugin zips ship inside the install tarball at <scope>/.claude/plugins/<name>/<name>-<version>.zip (project scope: ./.claude/plugins/…; --user: ~/.claude/plugins/…) — use those.

I want the plugins but not the graph content.

Re-run with --no-data (passed through INSTALL_PLUGINS_FLAGS):

make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--no-data"

The rosetta/ data tree (./.claude/rosetta/ for project scope, ~/.claude/rosetta/ for --user) won't be created. The wizard also offers to skip the data on an interactive run.

I want the graph content but not the plugins.

make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--no-plugins"

The plugins/ tree is left alone; only the rosetta/ data tree is populated. Note that --no-plugins also skips the settings.json merge — there are no plugins to register.

I want to copy the files but manage settings.json myself.

Re-run with --no-register:

make install-plugins VERSION=v0.18.0 INSTALL_PLUGINS_FLAGS="--no-register"

The plugin trees and data land as usual, but the installer writes nothing to settings.json (the legacy copy-only behavior). You then add the rosetta-plugins marketplace + enabledPlugins keys yourself (see the "slash commands still don't appear" entry above for the exact shape).

My install is at v0.1.0 and I want to know what changed in v0.18.0 before I upgrade.

The platform's release notes on GitHub (https://github.com/vernonkeenan/rosetta-platform/releases/tag/v0.18.0) summarize per-tag changes. For per-plugin granular changes, each plugin's CHANGES.md inside its own directory carries that narrative.

9. Getting help

• The guided walkthrough. Signed-in users get the full OS-tabbed version of this guide — including Claude Desktop, Cowork, and claude.ai connector wiring — at rosetta-design.com/help.
• Issue reports. Open at https://github.com/vernonkeenan/rosetta-platform/issues with the contents of your MANIFEST.txt attached (./.claude/rosetta/MANIFEST.txt for a project install, ~/.claude/rosetta/MANIFEST.txt for --user).
• SLO target. Best-effort during pre-GA. Production-grade support comes after platform v1.0.0.