Skip to content

guides

Intended Documentation

OpenShell Starter Kit

The lightweight in-repo pattern for a first OpenShell pilot — the Open Intent taxonomy, the Intended CLI, and the OpenShell adapter wired into a repo, generating policy locally.

beginner3 min readimplemented

OpenShell Starter Kit#

The starter kit is the smallest repository pattern that gets Intended governing a shell-style agent runtime (OpenClaw, Claude Code, Codex CLI, or a NemoClaw-style robotics runtime). It bundles the Open Intent taxonomy, the Intended CLI, and the OpenShell adapter so you can generate a sandbox policy artifact locally and prove value before moving into shared, hosted operations.

What it is for#

Use the starter kit when you want to:

  • pull the Open Intent taxonomy into a real repository;
  • generate OpenShell policy artifacts locally with one command;
  • keep the first rollout lightweight and reviewable;
  • pilot before adopting hosted Intended operations.

Starter structure#

The in-repo starter (open-source/intended-openshell-starter/) is intentionally small:

text
intended-openshell-starter/
  README.md
  package.json              # compile:openshell script
  intended-openshell.json   # the compiler input

The package.json ships a single script that wraps the compiler:

json
{
  "scripts": {
    "compile:openshell": "intended openshell-compile --input intended-openshell.json --output intended-openshell.yaml --runtime openclaw --provider nvidia"
  }
}

Steps#

Install the packages

The starter depends on three Intended packages: the Open Intent taxonomy, the OpenShell adapter, and the CLI.

bash
pnpm add @intended-inc/open-intent @intended-inc/openshell-adapter

The intended CLI is in private beta for design partners — build it from the monorepo workspace (see the note below).

Registry access

These packages live in the Intended monorepo (@intended/cli, @intended-inc/openshell-adapter, @intended-inc/open-intent). If your environment is not configured for the registry that hosts them, install from the monorepo workspace instead — the same intended openshell-compile command is available once the CLI is built locally.

Edit the input

Open intended-openshell.json and set the runtime, providers, and presets your pilot needs. The minimal form is presets-only:

json
{
  "profileName": "intended-openshell-starter",
  "runtime": "openclaw",
  "providers": ["nvidia"],
  "requestedPresets": ["github"]
}

See the Runtime Quickstart for the full list of runtimes, providers, and presets.

Generate the policy artifact

Run the compiler directly or through the starter's script. CLI flags merge with the input file.

bash
intended openshell-compile \
  --input intended-openshell.json \
  --output intended-openshell.yaml \
  --runtime openclaw \
  --provider nvidia

Review the generated YAML — its header records the profile, risk posture, and inferred presets — before you apply anything.

Apply it upstream

Apply the artifact with the upstream runtime's own interface:

bash
openshell policy set intended-openshell.yaml

What stays local at first#

The starter kit is for repo-level, developer-level adoption. In the first pass, keep these local:

  • policy artifact generation;
  • runtime configuration review;
  • review-mode rollout;
  • quick iteration on presets and allowed endpoints.

When to move to hosted Intended#

Graduate from the starter pattern to hosted Intended when you need maintained LIM intelligence, shared policy operations, multi-user approvals, runtime inventory, audit workflows and reporting, or environment-aware rollout control.

Suggested pilot flow#

  1. Start with one runtime path and one repo.
  2. Generate policy from your presets (and, optionally, intents and LIM context).
  3. Roll out in staging first; keep high-risk paths in review mode.
  4. Move to hosted Intended when more than one user or environment needs to govern the same runtime flow.

Next steps#

OpenShell Starter Kit | Intended