llm-orchestrator 1.0.0 → 1.0.1

package/.claude-plugin/marketplace.json

@@ -8,7 +8,7 @@
     {
       "name": "llm-orchestrator",
       "source": "./",
-      "description": "Portable, cross-harness mandatory orchestration core — capability resolution, dispatch contracts, cost-aware routing, gates and verification."
+      "description": "Write rtk /task once — it plans the work, shards it across parallel subagents, gates every phase and verifies before claiming done. Claude Code, Codex, OpenCode, Kilo."
     }
   ]
 }

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "llm-orchestrator",
-  "description": "Portable, cross-harness mandatory orchestration core — capability resolution, dispatch contracts, cost-aware routing, gates and verification.",
-  "version": "1.0.0",
+  "description": "Write rtk /task once — it plans the work, shards it across parallel subagents, gates every phase and verifies before claiming done. Claude Code, Codex, OpenCode, Kilo.",
+  "version": "1.0.1",
   "author": {
     "name": "Bogdan-Gabriel Torcescu",
     "url": "https://www.linkedin.com/in/bogdantorcescu/"

package/README.md

@@ -1,36 +1,160 @@
 <!-- llm-orchestrator · created by Bogdan-Gabriel Torcescu · https://www.linkedin.com/in/bogdantorcescu/ · keep this credit when copying or deriving -->
 # llm-orchestrator
 
-A portable, cross-harness orchestration layer for coding agents. It discovers your project, resolves which MCPs/skills/workflows/CLI tools a task actually needs, enforces a small set of **mandatory** capabilities as real gates (not suggestions), and dispatches bounded, verifiable work to subagents — on Codex, Claude Code, OpenCode and Kilo alike.
+You write one line. The agent plans the work, splits it across parallel subagents, writes their
+prompts, runs them, reviews the result, proves it works, and stops. You are not in the loop for any
+of the steps in between.
 
-## Quick start
+```
+/task "users can't reset their password from the mobile app"
+```
+
+That is the whole interface. What happens after you press enter:
+
+| | |
+|---|---|
+| **Classifies** | Bug, feature, incident, refactor, investigation, review, deploy, config or research — each has its own workflow, gates and evidence rules. |
+| **Reads your project** | Languages, frameworks, test and build commands, CI, plus any rules you wrote in `AGENTS.md`. Your rules tighten the defaults; they never get silently dropped. |
+| **Builds a flow** | Phases, parallel groups, dependencies — each shard with its own scope, owner, acceptance conditions and iteration budget. |
+| **Writes the prompts** | Each subagent gets a dispatch contract: the facts that shard needs, the tools it may use, what it must produce. Not a copy of the whole conversation. |
+| **Picks a model per shard** | Cheap model for the mechanical shard, a strong one with high thinking for the hard shard — decided per shard at dispatch time against live pricing, not once for the whole task. |
+| **Runs them in parallel** | Clean sessions, disjoint file ownership, so two agents cannot fight over the same file. |
+| **Gates every phase** | `G0` plan approved → `G1` evidence complete → `G2` hypothesis valid → `G3` a test that actually fails → `G4` suite green → `G5` independent review passed → `G6` verified on the real surfaces. A phase does not start until the gate before it resolves. |
+| **Proves it, then stops** | Completion claims need evidence: fresh local test output, not a subagent's summary. Then it checkpoints what it learned and cleans up its branches and worktrees. |
 
-Three commands, from wherever you keep cloned tools:
+You get back a result that has been reviewed and verified, plus a written trail of what was decided
+and why. If something is missing — a tool it needs, an ambiguous requirement — it says so up front
+and asks you once, batched, instead of guessing or quietly doing less.
+
+The rest of the command set:
 
 ```sh
-git clone https://github.com/tbogdan/llm-orchestrator.git && cd llm-orchestrator
-node bin/llm-orchestrator.mjs init --project /path/to/app
-node bin/llm-orchestrator.mjs install --project /path/to/app --harness <harness> --skills-root <root> --apply
+/task "describe the work"        # the above, end to end
+/task-plan "describe the work"   # plan only — see the flow before anything runs
+/task-status                     # where the active work stands
+/task-verify                     # re-run verification against acceptance evidence
+/task-cancel                     # stop cleanly
+/incident-start ...              # incident lifecycle: evidence -> fix -> verify -> close
 ```
 
-`init` is read-only: it proposes a `--harness` from what it finds in `/path/to/app` (or your home directory), shows the install plan it *would* run, and reports which of the [8 mandatory core tools](#the-8-mandatory-core-tools) are missing with the exact install command for each — nothing is written unless you pass `--apply` (which only appends the `AGENTS.md` bindings template if that section is missing; it never touches the install itself). Everything else in this README explains the same commands in more detail, per harness.
+Works on Claude Code, Codex, OpenCode and Kilo — the same flow, rendered into each one's native
+commands and agents.
+
+## Quick start
 
+Pick the line that matches your harness. Everything is a dry run until you pass `--apply`.
 
-### Install as a Claude Code plugin
+### Claude Code — install as a plugin
 
-Claude Code users can skip the clone and install the orchestrator as a plugin:
+No clone, no Node invocation. Type these two in any Claude Code session:
 
 ```
 /plugin marketplace add tbogdan/llm-orchestrator
 /plugin install llm-orchestrator@tbogdan
 ```
 
-That registers the `orchestrate-core` skill from this repository directly. Project bindings and the
-other harnesses still go through `llm-orchestrator init` / `install` as described below.
+That registers the `orchestrate-core` skill straight from this repository, and `/plugin update
+llm-orchestrator@tbogdan` keeps it current. The plugin ships the skill and its resources only — it
+does not write project files. If you also want `.claude/commands/*.md`, the `.claude/agents/orchestrator.md`
+agent and the `@AGENTS.md` line in `CLAUDE.md`, run the CLI install below with `--harness claude`.
+
+### Codex, OpenCode, Kilo — install from npm
+
+Node 22+. `npx` fetches the published package, so there is nothing to clone:
+
+```sh
+npx llm-orchestrator init    --project /path/to/app
+npx llm-orchestrator install --project /path/to/app --harness codex    --apply
+npx llm-orchestrator install --project /path/to/app --harness opencode --apply
+npx llm-orchestrator install --project /path/to/app --harness kilo     --apply
+npx llm-orchestrator install --project /path/to/app --harness claude   --apply
+npx llm-orchestrator doctor  --project /path/to/app --harness <harness>
+```
+
+Prefer it on your PATH? `npm install -g llm-orchestrator`, then drop the `npx` prefix and call
+`llm-orchestrator ...` directly.
+
+### From a clone — development, or pinning a commit
+
+```sh
+git clone https://github.com/tbogdan/llm-orchestrator.git && cd llm-orchestrator
+npm test
+node bin/llm-orchestrator.mjs init    --project /path/to/app
+node bin/llm-orchestrator.mjs install --project /path/to/app --harness <harness> --apply
+```
+
+### Which one to use
+
+| Harness | Fastest install | What it gives you | Reload |
+| --- | --- | --- | --- |
+| Claude Code | `/plugin install llm-orchestrator@tbogdan` | the `orchestrate-core` skill | new session |
+| Claude Code (full) | `npx llm-orchestrator install --harness claude --apply` | skill + commands + agent + `CLAUDE.md` binding | `/reload` or new session |
+| Codex | `npx llm-orchestrator install --harness codex --apply` | `AGENTS.md` span, skill, `~/.codex/prompts/*.md` | new Codex session |
+| OpenCode | `npx llm-orchestrator install --harness opencode --apply` | `.opencode/command(s)/*.md`, skill | restart `opencode` |
+| Kilo | `npx llm-orchestrator install --harness kilo --apply` | `.kilo/command(s)/*.md`, skill | restart Kilo |
+
+`init` is read-only: it proposes a `--harness` from what it finds in `/path/to/app` (or your home directory), shows the install plan it *would* run, and reports which of the [8 mandatory core tools](#the-8-mandatory-core-tools) are missing with the exact install command for each — nothing is written unless you pass `--apply` (which only appends the `AGENTS.md` bindings template if that section is missing; it never touches the install itself). Everything else in this README explains the same commands in more detail, per harness.
+
+## Let an agent install it for you
+
+Paste the block below into any capable coding agent (Claude Code, Codex, OpenCode, Kilo). It
+installs the orchestrator itself without asking, then **stops and asks you once** before touching
+anything else — installing third-party tools on someone's machine is not a decision an agent gets to
+make silently.
+
+````text
+Install llm-orchestrator in this project, then report back.
+
+STEP 1 — install the orchestrator (do this without asking):
+  - On Claude Code: run `/plugin marketplace add tbogdan/llm-orchestrator` then
+    `/plugin install llm-orchestrator@tbogdan`.
+  - On any other harness, or if you also want the project files (commands, agent, AGENTS.md
+    bindings): run `npx llm-orchestrator install --project . --harness <harness> --apply`,
+    where <harness> is one of codex | claude | opencode | kilo.
+
+STEP 2 — find the gaps (read-only, writes nothing):
+  Run `npx llm-orchestrator init --project .`
+  It prints each of the 8 mandatory core tools as [present] or [missing], with the exact
+  install command for each missing one, and whether AGENTS.md has the orchestration
+  bindings section.
+
+STEP 3 — ASK ME BEFORE INSTALLING ANYTHING ELSE. Do not skip this step.
+  Use your harness's native question mechanism (AskUserQuestion on Claude Code,
+  request_user_input on Codex, question on OpenCode, ask_followup_question on Kilo).
+  Ask once, batched, and include in the question:
+    - the list of missing tools,
+    - the exact command you would run for each,
+    - that `brew install rtk` needs Homebrew and that the `/plugin` lines only work on
+      Claude Code,
+    - that declining is fine: the core still runs, in declared degraded mode.
+  Then install exactly the ones I approve, and nothing I did not approve.
+
+STEP 4 — verify and report:
+  Run `npx llm-orchestrator doctor --project . --harness <harness>` and show me the output.
+  Tell me plainly which tools are still missing and which gates are therefore degraded.
+  Do not claim the install succeeded without showing the doctor output.
+````
+
+The same shape works as a standing instruction in `AGENTS.md`/`CLAUDE.md` if you want new sessions
+to self-install. Keep step 3 intact if you do — an agent that installs MCP servers and Homebrew
+formulae unprompted is a worse problem than a missing gate.
 
 ## Why
 
-Every harness reinvents "which tool for which job," and every project's AGENTS.md/CLAUDE.md ends up repeating (and drifting from) the same rules. `llm-orchestrator` centralizes that decision in a small set of portable JSON registries plus a capability resolver, and renders the result into whatever native format your harness understands — commands, agents, skills, prompts.
+Ask an agent to fix a bug and you usually get one long session: it reads a bit, guesses, edits,
+declares victory, and you find out later that nothing was verified. Ask it to parallelize and you
+spend your afternoon writing subagent prompts by hand, then merging the mess when two of them edited
+the same file.
+
+The work that makes the difference is the same every time — classify the task, gather evidence
+before theorizing, write a failing test first, split what can run in parallel, keep agents out of
+each other's files, review independently, verify before claiming done, record what was learned. It
+is mechanical, and nobody wants to re-type it into every prompt.
+
+`llm-orchestrator` makes that flow the default. It ships as a skill your agent must load before it
+does anything, so the process runs whether or not you remembered to ask for it, and it is written
+once in portable form instead of being copy-pasted and left to drift across every project's
+`AGENTS.md` and every harness's config.
 
 ## How it works
 
@@ -63,6 +187,33 @@ These apply to every task, everywhere, regardless of harness (see `registries/co
 
 Four more gates are equally mandatory, at their own trigger rather than on every turn: `verification.checks` (verification-before-completion, before any completion claim), `skill.check` (before any action, check whether a skill already covers it), `tool.discovery` (search before declaring a tool absent), and `user.native_question` (every question to the user goes through the harness's native mechanism, batched into one question — `AskUserQuestion` on Claude Code, `request_user_input` / `update_plan` on Codex, `question` on OpenCode, `ask_followup_question` on Kilo; see `policies/questions.md`).
 
+#### Installing the core tools
+
+`llm-orchestrator init` reports which of these are missing and prints the matching command. The
+routes below are the ones it prints — each was checked against the published source, because three
+of them are not what the obvious guess would be: `rtk` on crates.io is an unrelated "Rust Type Kit",
+and `mempalace-mcp` and `superpowers` are binaries their plugin ships rather than npm packages you
+can `npx`.
+
+| Capability | Tool | Install |
+|---|---|---|
+| `orchestration.bootstrap`, `skill.check`, `verification.checks` | using-superpowers | `/plugin marketplace add anthropics/claude-plugins-official` then `/plugin install superpowers@claude-plugins-official` |
+| `memory.recall`, `memory.checkpoint` | mempalace | `/plugin marketplace add MemPalace/mempalace` then `/plugin install mempalace@mempalace` |
+| `reasoning.checkpoints` | sequential-thinking | `claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking` |
+| `communication.concise` | caveman | `/plugin marketplace add JuliusBrussee/caveman` then `/plugin install caveman@caveman` |
+| `shell.rtk` | rtk | `brew install rtk` (Homebrew core; **not** `cargo install rtk`) |
+| `docs.current` | context7 | `claude mcp add context7 -- npx -y @upstash/context7-mcp` |
+| `research.retrieve` | exa | `claude mcp add exa -- npx -y exa-mcp-server` |
+| `tool.discovery` | harness-native tool search | built in, nothing to install |
+
+The `/plugin ...` lines are Claude Code commands, typed in a session. The `claude mcp add ...` lines
+are shell commands; on Codex, OpenCode or Kilo, register the same MCP server through that harness's
+own config instead — the server package and arguments are identical.
+
+Every one of these is optional in the sense that the core still runs without it — but it then runs
+in **declared degraded mode**, and every plan and report says so. That is the design, not a
+workaround.
+
 The eight rows above are `registries/core-profile.json` orders 1–8, in that order. The same eight, in the same order, appear in `SKILL.md`, `policies/capabilities.md` and the `task` command checklist, and `lib/first-run.mjs` checks exactly these for presence — `tests/coherence.test.mjs` fails if any of those six lists drifts.
 
 ### Registries
@@ -77,15 +228,20 @@ Project-specific bindings live in the consuming project's `AGENTS.md`, under `##
 
 ## Install for your IDE
 
-Dry runs by default — inspect conflicts, then repeat with `--apply`. Existing user-owned files are never silently overwritten. `node bin/llm-orchestrator.mjs install ...` is the entry point; `node bin/install.mjs ...` (same options) still works underneath it.
+Dry runs by default — inspect conflicts, then repeat with `--apply`. Existing user-owned files are never silently overwritten.
 
 ```sh
-node bin/llm-orchestrator.mjs install --project /path/to/app --harness codex
-node bin/llm-orchestrator.mjs install --project /path/to/app --harness claude-code
-node bin/llm-orchestrator.mjs install --project /path/to/app --harness opencode
-node bin/llm-orchestrator.mjs install --project /path/to/app --harness kilo
+npx llm-orchestrator install --project /path/to/app --harness codex
+npx llm-orchestrator install --project /path/to/app --harness claude-code
+npx llm-orchestrator install --project /path/to/app --harness opencode
+npx llm-orchestrator install --project /path/to/app --harness kilo
 ```
 
+`npx llm-orchestrator` (or the bare `llm-orchestrator` after `npm install -g llm-orchestrator`) is
+the entry point. From a clone the same commands are `node bin/llm-orchestrator.mjs ...`; every
+example below spells the clone form, and the npm form is identical minus the `node bin/…` prefix.
+`node bin/install.mjs ...` (same options) still works underneath it.
+
 `--skills-root` is optional: it defaults per harness (`codex` → `~/.agents/skills`, `claude` → `~/.claude/skills`, `opencode` → `~/.config/opencode/skills`, `kilo` → `~/.kilo/skills`), so the four commands above are already complete — pass `--skills-root <dir>` only to override that default. `claude`, `claude-code`, and `claude code` resolve to the same harness.
 
 `--package-root <dir>` (where the package's own files are read from) and `--state-root <dir>` (where the installation manifest is kept; defaults to `$XDG_STATE_HOME/portable-orchestrator` or `~/.local/state/portable-orchestrator`) exist on `install`, `uninstall` and `init` for testing and for non-standard layouts — you normally leave both alone.
@@ -96,7 +252,11 @@ Multiple harnesses may share one explicitly enabled skill root using a comma-sep
 
 Same five steps for every harness; only the skills root and the reload differ.
 
-1. **Get the package** (Node 22+):
+1. **Get the package** (Node 22+) — either straight from npm:
+   ```sh
+   npx llm-orchestrator --help        # or: npm install -g llm-orchestrator
+   ```
+   or from a clone, when you want to read or pin the source:
    ```sh
    git clone https://github.com/tbogdan/llm-orchestrator.git
    cd llm-orchestrator && npm test
@@ -233,25 +393,26 @@ Prices and measured costs are dated evidence, not live tariffs; refresh `models/
 
 ## Updating
 
+From npm — `npx` always resolves the latest published version, so there is nothing to pull:
+
+```sh
+npx llm-orchestrator@latest install --project /path/to/app --harness <harness> --apply
+```
+
+From a clone:
+
 ```sh
 git -C llm-orchestrator pull
 node bin/llm-orchestrator.mjs install --project /path/to/app --harness <harness> --apply
 ```
 
-Re-running `install --apply` after a `git pull` is the entire update procedure — it is the same idempotent apply as a fresh install. Files the package generated and you haven't touched are refreshed to the new version; a project file you hand-edited (an `AGENTS.md` bindings section, a command you customized) is reported as a **conflict** and left untouched — nothing is overwritten silently. Resolve a reported conflict by reviewing the diff yourself and either keeping your edit or deleting the file so the next apply can regenerate it.
+In Claude Code, the plugin updates on its own terms: `/plugin update llm-orchestrator@tbogdan`.
 
-## Usage once installed
+Re-running `install --apply` after an update is the entire update procedure — it is the same idempotent apply as a fresh install. Files the package generated and you haven't touched are refreshed to the new version; a project file you hand-edited (an `AGENTS.md` bindings section, a command you customized) is reported as a **conflict** and left untouched — nothing is overwritten silently. Resolve a reported conflict by reviewing the diff yourself and either keeping your edit or deleting the file so the next apply can regenerate it.
 
-```sh
-/task "describe the work"        # plan + dispatch through the resolved capability plan
-/task-plan "describe the work"   # plan only, no dispatch
-/task-status                     # report progress/gaps on active work
-/task-verify                     # run the verification phase against acceptance evidence
-/task-cancel                     # stop active task work cleanly
-/incident-start ...              # incident lifecycle: start -> evidence -> fix -> verify -> close
-```
+## Usage once installed
 
-Exact command names and argument shapes are rendered per harness by `adapters/commands.mjs`; run `--help` on any installed command for the harness-native form.
+The command set is listed at the top of this README. Exact command names and argument shapes are rendered per harness by `adapters/commands.mjs`; run `--help` on any installed command for the harness-native form.
 
 ## Development
 

package/lib/first-run.mjs

@@ -138,6 +138,15 @@ async function rtkOnPath() {
 }
 
 /** The 8 mandatory core tools (registries/core-profile.json orders 1-8), checked read-only, presence only. */
+/**
+ * Install routes verified against the published sources, not guessed: `rtk` on crates.io is an
+ * unrelated tool of the same name, `mempalace-mcp` and `superpowers` are binaries a plugin
+ * provides rather than npm packages you can `npx`, so all three go through their marketplace.
+ */
+const SUPERPOWERS_INSTALL = '/plugin marketplace add anthropics/claude-plugins-official && /plugin install superpowers@claude-plugins-official';
+const MEMPALACE_INSTALL = '/plugin marketplace add MemPalace/mempalace && /plugin install mempalace@mempalace';
+const CAVEMAN_INSTALL = '/plugin marketplace add JuliusBrussee/caveman && /plugin install caveman@caveman';
+
 export async function checkMandatoryTools(project) {
   const [superpowers, mempalace, sequentialThinking, caveman, rtk, context7, exa] = await Promise.all([
     anySkillDirNamed(project, 'using-superpowers').then((v) => v || anySkillDirNamed(project, 'superpowers')).then((v) => v || anyPluginDirNamed('superpowers')),
@@ -149,15 +158,15 @@ export async function checkMandatoryTools(project) {
     anyConfigMentions(project, ['exa-mcp-server', '"exa"', 'exa-search']),
   ]);
   return [
-    { id: 'orchestration.bootstrap', tool: 'using-superpowers', present: superpowers, install_hint: 'npx -y superpowers install' },
-    { id: 'memory.recall', tool: 'mempalace', present: mempalace, install_hint: 'claude mcp add mempalace -- npx -y mempalace-mcp' },
-    { id: 'memory.checkpoint', tool: 'mempalace', present: mempalace, install_hint: 'claude mcp add mempalace -- npx -y mempalace-mcp' },
+    { id: 'orchestration.bootstrap', tool: 'using-superpowers', present: superpowers, install_hint: SUPERPOWERS_INSTALL },
+    { id: 'memory.recall', tool: 'mempalace', present: mempalace, install_hint: MEMPALACE_INSTALL },
+    { id: 'memory.checkpoint', tool: 'mempalace', present: mempalace, install_hint: MEMPALACE_INSTALL },
     { id: 'reasoning.checkpoints', tool: 'sequential-thinking', present: sequentialThinking, install_hint: 'claude mcp add sequential-thinking -- npx -y @modelcontextprotocol/server-sequential-thinking' },
-    { id: 'communication.concise', tool: 'caveman', present: caveman, install_hint: 'llm-orchestrator install --with-skill caveman' },
-    { id: 'shell.rtk', tool: 'rtk', present: rtk, install_hint: 'cargo install rtk' },
+    { id: 'communication.concise', tool: 'caveman', present: caveman, install_hint: CAVEMAN_INSTALL },
+    { id: 'shell.rtk', tool: 'rtk', present: rtk, install_hint: 'brew install rtk' },
     { id: 'docs.current', tool: 'context7', present: context7, install_hint: 'claude mcp add context7 -- npx -y @upstash/context7-mcp' },
     { id: 'research.retrieve', tool: 'exa-search', present: exa, install_hint: 'claude mcp add exa -- npx -y exa-mcp-server' },
-    { id: 'skill.check', tool: 'using-superpowers', present: superpowers, install_hint: 'npx -y superpowers install' },
+    { id: 'skill.check', tool: 'using-superpowers', present: superpowers, install_hint: SUPERPOWERS_INSTALL },
     { id: 'tool.discovery', tool: 'harness-native tool search', present: true, install_hint: null },
   ];
 }
@@ -201,6 +210,16 @@ async function agentsMdHasBindings(project) {
  * First-run wizard: no prompts, everything read-only unless --apply appends the
  * bindings template. Returns a plain report object; the CLI renders it to text.
  */
+/**
+ * How to spell a follow-up command for the way this process was started: `node bin/…` from a
+ * clone, the bare bin name when installed from npm (global or `npx`).
+ */
+export function cliInvocation(argv = process.argv) {
+  const script = argv[1] ? resolve(argv[1]) : '';
+  const fromClone = script === resolve(process.cwd(), 'bin', 'llm-orchestrator.mjs');
+  return fromClone ? 'node bin/llm-orchestrator.mjs' : 'llm-orchestrator';
+}
+
 export async function runInit({ project, harnesses, skillsRoot, apply = false, packageRoot, stateRoot, codexPromptsRoot, withAgents = false }) {
   const root = resolve(project);
   const requestedHarnesses = harnesses && harnesses.length > 0 ? harnesses.map(normalizeHarness) : null;
@@ -246,10 +265,11 @@ export async function runInit({ project, harnesses, skillsRoot, apply = false, p
     ? `Multiple harnesses share ${effectiveSkillsRoot}; point every selected IDE at this root (see README "Several harnesses at once").`
     : null;
 
+  const cli = cliInvocation();
   const nextCommands = [
-    `node bin/llm-orchestrator.mjs install --project ${root} --harness ${effectiveHarnesses.join(',')} --skills-root ${effectiveSkillsRoot}`,
-    `node bin/llm-orchestrator.mjs install --project ${root} --harness ${effectiveHarnesses.join(',')} --skills-root ${effectiveSkillsRoot} --apply`,
-    `node bin/llm-orchestrator.mjs doctor --project ${root} --harness ${effectiveHarnesses[0]}`,
+    `${cli} install --project ${root} --harness ${effectiveHarnesses.join(',')} --skills-root ${effectiveSkillsRoot}`,
+    `${cli} install --project ${root} --harness ${effectiveHarnesses.join(',')} --skills-root ${effectiveSkillsRoot} --apply`,
+    `${cli} doctor --project ${root} --harness ${effectiveHarnesses[0]}`,
   ];
 
   return {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "llm-orchestrator",
-  "version": "1.0.0",
-  "description": "Portable, cross-harness mandatory orchestration core (Codex, Claude Code, OpenCode, Kilo) — capability resolution, dispatch contracts, and harness adapters.",
+  "version": "1.0.1",
+  "description": "Write rtk /task once — it plans the work, shards it across parallel subagents, gates every phase and verifies before claiming done. Claude Code, Codex, OpenCode, Kilo.",
   "type": "module",
   "engines": {
     "node": ">=22"

package/registries/preferred-tools.json

@@ -14,7 +14,7 @@
       "display_name": "MemPalace",
       "recommendation_kind": "product",
       "installable": true,
-      "install": "claude mcp add mempalace -- npx -y mempalace-mcp"
+      "install": "/plugin marketplace add MemPalace/mempalace && /plugin install mempalace@mempalace"
     },
     {
       "id": "native-memory",
@@ -91,7 +91,7 @@
       "display_name": "Verification before completion",
       "recommendation_kind": "product",
       "installable": true,
-      "install": "llm-orchestrator install --with-skill verification-before-completion"
+      "install": "/plugin marketplace add anthropics/claude-plugins-official && /plugin install superpowers@claude-plugins-official"
     },
     {
       "id": "production-telemetry-collector",
@@ -269,7 +269,7 @@
       "display_name": "Caveman",
       "recommendation_kind": "product",
       "installable": true,
-      "install": "llm-orchestrator install --with-skill caveman"
+      "install": "/plugin marketplace add JuliusBrussee/caveman && /plugin install caveman@caveman"
     },
     {
       "id": "native-concise-policy",
@@ -301,7 +301,7 @@
       "display_name": "Superpowers",
       "recommendation_kind": "product",
       "installable": true,
-      "install": "npx -y superpowers install"
+      "install": "/plugin marketplace add anthropics/claude-plugins-official && /plugin install superpowers@claude-plugins-official"
     },
     {
       "id": "native-workflow-selection",
@@ -329,7 +329,7 @@
       "display_name": "RTK",
       "recommendation_kind": "product",
       "installable": true,
-      "install": "cargo install rtk"
+      "install": "brew install rtk"
     },
     {
       "id": "native-shell-wrapper",