@ory/argus 0.4.0 → 0.6.0

package/assets/skills/ory-build-integration/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: ory-build-integration
+description: Wire an Ory Network integration into your own application using the ory/integrates template patterns. Use when the user wants to add an Ory integration to their app — an Action webhook handler that fires during a flow, a Console/gateway config to validate Ory JWTs, or an Enterprise live-event-stream consumer — phrases like "wire up an Ory webhook", "add an Ory Action handler to my app", "react to Ory identity events", "validate Ory tokens at my gateway", "build an Ory integration in my project". For contributing an integration back to ory/integrates instead, use ory-contribute-integration.
+---
+
+# Build an Ory Integration Into Your App
+
+You are helping the user wire an Ory Network integration into **their own
+application**, reusing the proven patterns from the public `ory/integrates`
+repository. There is no contribution, registry, `Maintained by:`, or DCO concern
+here — you fetch the **runnable subset** of a template and adapt it in place.
+
+This skill carries the workflow. The template files live in
+`github.com/ory/integrates` (branch `main`); fetch the ones you need so they stay
+current.
+
+> **Precondition:** `ory/integrates` must be reachable (public repo). If a fetch
+> fails, tell the user and stop — do not fabricate handler code.
+
+## Step 1 — Determine the type and app context
+
+Pick the integration type from intent; ask directly if unclear.
+
+| Signal from the user | Type |
+|---|---|
+| Transform/enrich an identity at registration; gate or react to a flow **synchronously**; call a vendor API during an Ory flow | `webhook` |
+| Validate Ory JWTs at a gateway; **Console-only** config; no handler code | `config` |
+| React to events **asynchronously**; Ory **Enterprise** Live Event Stream consumer | `http-event` |
+
+Also establish: the app's framework/runtime, where the handler will live, and how
+it's deployed (these decide where you write files and how you mount the route).
+
+## Step 2 — Fetch the runnable subset
+
+Pull only the files the user needs from `_examples/_template-<type>/`. Prefer raw
+fetch so you don't clone the whole repo into the user's project.
+
+**Raw file fetch** (base URL
+`https://raw.githubusercontent.com/ory/integrates/main/_examples/_template-<type>/`):
+
+```bash
+BASE=https://raw.githubusercontent.com/ory/integrates/main/_examples/_template-webhook
+mkdir -p ory-integration/webhook ory-integration/jsonnet
+curl -fsSL "$BASE/ory-actions.yaml"          -o ory-integration/ory-actions.yaml
+curl -fsSL "$BASE/jsonnet/identity.jsonnet"  -o ory-integration/jsonnet/identity.jsonnet
+curl -fsSL "$BASE/webhook/server.ts"         -o ory-integration/webhook/server.ts
+curl -fsSL "$BASE/webhook/package.json"      -o ory-integration/webhook/package.json
+curl -fsSL "$BASE/webhook/tsconfig.json"     -o ory-integration/webhook/tsconfig.json
+curl -fsSL "$BASE/webhook/.env.example"      -o ory-integration/webhook/.env.example
+```
+
+**Sparse checkout** (if the user prefers a git copy to diff against):
+
+```bash
+git clone --depth 1 --filter=blob:none --sparse https://github.com/ory/integrates /tmp/ory-integrates
+git -C /tmp/ory-integrates sparse-checkout set _examples/_template-webhook
+# then copy the files you want out of /tmp/ory-integrates/_examples/_template-webhook
+```
+
+Runnable subset per type (skip `registry.entry.yaml.example`, the
+`Maintained by:` README, and lockfiles — `npm install` regenerates the lock):
+
+- **webhook** — `ory-actions.yaml`, `jsonnet/identity.jsonnet`,
+  `webhook/{server.ts, package.json, tsconfig.json, .env.example}`.
+- **config** — `ory-console-steps.md` (no code; it's a Console walkthrough).
+- **http-event** — `ory-event-stream.yaml`,
+  `webhook/{server.ts, idempotency.ts, package.json, tsconfig.json, .env.example}`.
+
+Adapt the fetched handler into the user's app: integrate the route into their
+existing server if they have one, or run the `webhook/` server standalone.
+
+## Step 3 — Wire it to the user's Ory project
+
+- **webhook** — deploy the handler, then create an Ory Action pointing at it using
+  `ory-actions.yaml` as the template (set `url` to the deployed handler, set the
+  `X-Webhook-Secret` value, and the matching `ORY_WEBHOOK_SECRET` in the
+  handler's `.env`). Adjust `jsonnet/identity.jsonnet` to the body shape the
+  handler expects. Apply via the Ory Console or the Ory CLI.
+- **config** — follow `ory-console-steps.md`: configure the vendor side, then the
+  Ory Console (gateway/JWT validation, provider config, etc.). No code to deploy.
+- **http-event** (Enterprise) — deploy the handler, then configure the
+  event-stream target from `ory-event-stream.yaml` (URL with embedded Basic Auth;
+  set `BASIC_AUTH_USER` / `BASIC_AUTH_PASSWORD` in `.env` to match) and the event
+  filter. Keep the `idempotency.ts` dedupe wired up — delivery is at-least-once.
+
+Always verify the signature/secret path: webhook uses the `X-Webhook-Secret`
+header; http-event uses HTTP Basic Auth embedded in the configured URL.
+
+## Step 4 — Test locally
+
+Stand up Ory and exercise the flow locally before pointing at production:
+
+- Use {{REF_LOCAL_DEV}} to run a local Ory stack (Kratos / Keto / Hydra +
+  gateway), then trigger the relevant flow and confirm the handler fires.
+- Use {{REF_AUTH_SETUP}} when the app also needs Ory project / SDK setup wired up.
+
+For a webhook, hit `GET /health` on the handler, then run the Ory flow and check
+the handler logs. For http-event, emit a test event and confirm both the dedupe
+and the downstream side effect.
+
+## What this skill does NOT do
+
+- It does not create a contribution to `ory/integrates` (no `registry.entry.yaml`,
+  `Maintained by:`, SPDX, or DCO) — use `ory-contribute-integration` for that.
+- It does not invent handler code — it fetches the real templates from
+  `ory/integrates`.
+- It does not deploy to the user's infrastructure or modify their Ory project
+  without confirmation.

package/assets/skills/ory-contribute-integration/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: ory-contribute-integration
+description: Author a new Ory Network integration as a contribution to the public ory/integrates repository. Use when the user wants to contribute an integration back to Ory, add an entry to the Ory integrations registry/catalog, open a PR against ory/integrates, or publish a reusable integration for others — phrases like "contribute an Ory integration", "add my integration to ory/integrates", "submit a webhook integration to Ory", "get my integration into the registry". For wiring an integration into your own app instead, use ory-build-integration.
+---
+
+# Contribute an Integration to ory/integrates
+
+You are helping the user author a new integration and contribute it back to the
+public `ory/integrates` repository ("Sample code and reference configuration for
+integrating Ory Network with third-party products"). The deliverable is a pull
+request against `github.com/ory/integrates`.
+
+This skill carries the workflow. The **template files** live in the repo itself —
+fetch them from `github.com/ory/integrates` (branch `main`) rather than
+reproducing them, so they never drift.
+
+> **Precondition:** `ory/integrates` must be reachable (it is a public repo). If
+> `gh repo view ory/integrates` or a fetch of a template file fails, tell the
+> user the repo is unreachable and stop — do not fabricate template contents.
+
+## Step 0 — Open the "New integration" issue first
+
+Ory asks contributors to open a **New integration** issue before the PR, so scope
+is confirmed and the work isn't already in flight. Remind the user to do this
+(GitHub → `ory/integrates` → Issues → "New integration" template) and capture the
+issue number for the PR.
+
+## Step 1 — Get a checkout and pick the category
+
+The contribution workflow happens inside a checkout of the repo:
+
+```bash
+gh repo clone ory/integrates
+cd integrates
+```
+
+(or a fork, if the user will PR from their own remote.) Then choose the
+**category folder** the integration belongs in — it must match an existing
+top-level directory (`crm/`, `api-gateways/`, `identity-verification/`, `mfa/`,
+`enterprise-sso/`, …). List them with `ls -d */ | grep -v _examples`.
+
+## Step 2 — Determine the integration type
+
+Every integration is one of three types. Infer from intent; if unclear, ask
+directly.
+
+| Signal from the user | Type | Template |
+|---|---|---|
+| Transform/enrich an identity at registration; gate or react to a self-service flow **synchronously**; call a vendor API during an Ory flow | `webhook` | `_examples/_template-webhook/` |
+| Validate Ory JWTs at a gateway; **Console-only** setup; no handler code | `config` | `_examples/_template-config/` |
+| React to events **asynchronously**; Ory Network **Enterprise** Live Event Stream consumer | `http-event` | `_examples/_template-http-event/` |
+
+## Step 3 — Copy the template into the category folder
+
+From the repo root, copy the whole template directory to
+`<category>/<integration-slug>` (slug is lowercase, hyphenated, matches the dir
+name):
+
+```bash
+cp -R _examples/_template-webhook crm/<integration-slug>      # webhook
+# or _examples/_template-config / _examples/_template-http-event
+```
+
+Each template ships these files (confirm with `ls -R <category>/<integration-slug>`):
+
+- **webhook** — `README.md`, `ory-actions.yaml`, `jsonnet/identity.jsonnet`,
+  `registry.entry.yaml.example`, and a runnable `webhook/` (`server.ts`,
+  `package.json`, `package-lock.json`, `tsconfig.json`, `.env.example`).
+- **config** — `README.md`, `ory-console-steps.md`,
+  `registry.entry.yaml.example`.
+- **http-event** — `README.md`, `ory-event-stream.yaml`,
+  `registry.entry.yaml.example`, and a runnable `webhook/` (`server.ts`,
+  `idempotency.ts`, `package.json`, `package-lock.json`, `tsconfig.json`,
+  `.env.example`).
+
+The copied files are the source of truth — read them and fill in every
+`<placeholder>` and `<!-- comment -->`.
+
+## Step 4 — Fill out the integration
+
+1. **README.md** — replace `<Integration Name>`, set the `Maintained by:` line
+   (`Ory Engineering`, `Community contributors`, or the user's `@handle`), and
+   complete: what it does, use case, prerequisites, deploy steps, **Ory Console
+   configuration**, troubleshooting. No vendor marketing — factual wiring only.
+2. **Code / config for the type** (see per-type notes below).
+3. **registry.entry.yaml** — rename `registry.entry.yaml.example` →
+   `registry.entry.yaml` and fill in every field (`name`, `displayName`,
+   `vendor`, `category`, `type`, `maintainedBy`, `description`, `useCase`,
+   `coreFunctionality`, `oryMechanism`, `protocol`, `status`; http-event also
+   needs `subscribedEvents`). The field comments in the file enumerate the
+   allowed enum values.
+4. **Apache-2.0 SPDX header** at the top of every source file you ship, e.g.
+   `// SPDX-License-Identifier: Apache-2.0`.
+
+### webhook specifics
+- `ory-actions.yaml` is the Ory Action hook config (a `web_hook` with an
+  `X-Webhook-Secret` `api_key` auth header). Point `url` at the deployed handler
+  and set the shared secret.
+- `jsonnet/identity.jsonnet` is the request-body template — adjust to the shape
+  your handler expects.
+- The `webhook/` server must run (`cd webhook && cp .env.example .env && npm
+  install && npm start`); it exposes `GET /health` and the `POST` target.
+  `ORY_WEBHOOK_SECRET` in `.env` must match the secret in `ory-actions.yaml`.
+
+### config specifics
+- No code. Write a real `ory-console-steps.md`: vendor-side setup, the exact Ory
+  Console navigation, the fields to configure, a test, and troubleshooting. A
+  README-only contribution with no real console steps will be rejected.
+
+### http-event specifics
+- `ory-event-stream.yaml` configures the Ory-side event target (URL with embedded
+  Basic Auth) and the event filter. List the consumed events under both the YAML
+  `events:` and the registry `subscribedEvents:`.
+- The `webhook/` handler authenticates with HTTP Basic Auth, dedupes by SHA-256
+  of the body (`idempotency.ts`) because delivery is at-least-once, and always
+  returns 200. Live event streams are an **Enterprise** feature — say so in the
+  README.
+
+## Step 5 — Regenerate the registry
+
+From the repo root:
+
+```bash
+cd scripts && npm install && cd ..
+node scripts/build-registry.js
+```
+
+This rewrites the top-level `registry.yaml` from every `registry.entry.yaml`.
+Commit the regenerated `registry.yaml` along with your integration.
+
+## Step 6 — Open the PR (DCO + checklist)
+
+Walk the CONTRIBUTING checklist before opening the PR:
+
+- [ ] Integration is in the correct category folder.
+- [ ] `README.md` covers what it does, prerequisites, deploy, Console config,
+      troubleshooting, and a `Maintained by:` line.
+- [ ] Type deliverables present: webhook → `ory-actions.yaml` + `jsonnet/` +
+      runnable `webhook/`; config → real `ory-console-steps.md`; http-event →
+      `ory-event-stream.yaml` + runnable `webhook/` + `subscribedEvents`.
+- [ ] `registry.entry.yaml` filled and `registry.yaml` regenerated.
+- [ ] Apache-2.0 SPDX header in each source file.
+- [ ] **DCO sign-off on every commit** — `git commit -s`.
+
+```bash
+git checkout -b add-<integration-slug>-integration
+git add <category>/<integration-slug> registry.yaml
+git commit -s -m "Add <Integration Name> integration"
+git push -u origin add-<integration-slug>-integration
+gh pr create --repo ory/integrates --title "Add <Integration Name> integration" \
+  --body "Closes #<issue-number>. <summary>"
+```
+
+Expect review questions about Ory Network compatibility, webhook security
+(signature verification, secret handling), and README clarity.
+
+## What this skill does NOT do
+
+- It does not wire an integration into the user's own application — use
+  `ory-build-integration` for that (no registry/DCO).
+- It does not run `build-registry.js` or open the PR without confirmation; it
+  guides, the user executes.
+- It does not invent template contents — it reads the real files from
+  `ory/integrates`.

package/assets/skills/ory-e2b-sandbox/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: ory-e2b-sandbox
+description: Scaffold an E2B (e2b.dev) sandbox template that boots with {{PKG}} preinstalled, so every Claude/Codex/Gemini/OpenClaw/OpenCode session running inside the sandbox is gated by Ory auth, permissions, and tracing without any per-sandbox setup. Use when the user asks to "create an E2B sandbox with Ory agent security", "build an E2B template with the Ory plugin", "make an E2B image that includes Ory auth", or any close variant. The skill generates the template files in the user's project — it does not deploy them.
+---
+
+# E2B sandbox with Ory agent security
+
+You are helping the user scaffold an [E2B](https://e2b.dev) sandbox template
+that preinstalls and registers the {{PKG}} plugin. The resulting template
+publishes a named image; every `Sandbox.create("<tag>")` call from their SDK
+gets a runtime where the agent's tool calls are already authenticated against
+Ory Identities, authorized against Ory Permissions, and emitted as trace
+spans — with **no** install step at sandbox boot.
+
+This skill carries the full workflow and the file contents. You generate the
+files in the user's repo; the user runs the build.
+
+> **Precondition:** the user has (or will obtain) an `E2B_API_KEY` and has
+> installed the E2B CLI / SDK (`npm install e2b dotenv`). If they haven't, point
+> them at <https://e2b.dev/docs> and stop — do not fabricate credentials.
+
+## Step 1 — Confirm the target
+
+Before writing files, confirm with the user:
+
+1. **Where in their repo should the integration live?** A common choice is
+   `integrations/e2b/` at the repo root. Use that unless they say otherwise.
+2. **Template tag.** Default to `agent-ory` (e.g. `claude-code-ory`,
+   `codex-ory`). Operators will reference this string in `Sandbox.create()`.
+3. **Will the sandbox have network access to Ory?** It must — the plugin makes
+   live API calls to `ORY_PROJECT_URL` from inside the sandbox.
+
+If the user is targeting an in-process harness (OpenClaw, OpenCode), the host
+binary that loads the plugin must also be available inside the sandbox. Flag
+this and ask how they ship that binary today — usually `npm install` of a
+project that already depends on the harness runtime.
+
+## Step 2 — Generate the files
+
+Create these four files at the chosen location (the example uses
+`integrations/e2b/`).
+
+### `integrations/e2b/template.ts`
+
+```ts
+import { Template } from "e2b";
+
+export const template = Template()
+  .fromUbuntuImage("22.04")
+  .aptInstall(["curl", "ca-certificates", "git", "python3"])
+
+  // Node.js 20 (NodeSource)
+  .runCmd("curl -fsSL https://deb.nodesource.com/setup_20.x | bash -")
+  .aptInstall(["nodejs"])
+
+  // Install the harness CLI globally. Replace `@anthropic-ai/claude-code` with
+  // the binary that hosts the Ory plugin in this sandbox (e.g. the Codex or
+  // Gemini CLI). For in-process harnesses (openclaw, opencode), `npm install`
+  // the harness runtime here instead and ensure its entrypoint is on PATH.
+  .npmInstall(["@anthropic-ai/claude-code"], { g: true })
+
+  // Install the Ory plugin into the harness's discovery location.
+  .setWorkdir("/root")
+  .runCmd("{{NPX}} install")
+
+  // Sandbox runtime defaults. Per-tenant secrets (project URL, tokens, client
+  // IDs) MUST be passed at Sandbox.create() time, never baked into the image.
+  .setEnvs({
+    ORY_AUTH_GATE: "1",
+    ORY_PERMISSION_MODE: "observe",
+    ORY_PERMISSION_NAMESPACE: "AgentTools",
+    ORY_AGENT_DEBUG: "true",
+    ORY_AGENT_LOG_FILE: "/root/ory-agent-debug.log",
+  })
+
+  .setWorkdir("/workspace");
+```
+
+### `integrations/e2b/build.prod.ts`
+
+```ts
+import "dotenv/config";
+import { Template, defaultBuildLogger } from "e2b";
+import { template } from "./template";
+
+await Template.build(template, "agent-ory", {
+  cpuCount: 2,
+  memoryMB: 4096,
+  onBuildLogs: defaultBuildLogger(),
+});
+```
+
+### `integrations/e2b/build.dev.ts`
+
+```ts
+import "dotenv/config";
+import { Template, defaultBuildLogger } from "e2b";
+import { template } from "./template";
+
+await Template.build(template, "agent-ory-dev", {
+  cpuCount: 2,
+  memoryMB: 4096,
+  skipCache: true,
+  onBuildLogs: defaultBuildLogger(),
+});
+```
+
+### `integrations/e2b/.env.example`
+
+```
+# E2B credentials — required to build and run templates.
+E2B_API_KEY=e2b_***
+
+# Per-tenant Ory wiring — passed to Sandbox.create() at runtime, NOT baked into
+# the template. Listed here so operators know what to plumb through.
+ORY_PROJECT_URL=https://<slug>.projects.oryapis.com
+ORY_OAUTH2_CLIENT_ID=
+ORY_USER_SESSION_TOKEN=
+# Optional: pin a static agent identity instead of DCR.
+# ORY_AGENT_API_KEY=
+```
+
+### `integrations/e2b/package.json`
+
+```json
+{
+  "name": "ory-e2b-integration",
+  "version": "0.0.0",
+  "private": true,
+  "type": "module",
+  "scripts": {
+    "build:dev": "tsx build.dev.ts",
+    "build:prod": "tsx build.prod.ts"
+  },
+  "dependencies": {
+    "dotenv": "^16.4.5",
+    "e2b": "^2.3.0"
+  },
+  "devDependencies": {
+    "tsx": "^4.19.0",
+    "typescript": "^6.0.2"
+  }
+}
+```
+
+### `integrations/e2b/README.md`
+
+Generate a README that captures:
+
+- What the template provides (harness CLI + {{PKG}} preinstalled, runtime
+  defaults baked in, secrets supplied at sandbox creation).
+- The build flow: `npm install`, `npx e2b auth login` once, then
+  `npm run build:prod`.
+- A `Sandbox.create("agent-ory", { envs: { ... } })` example showing which env
+  vars to inject at runtime (`ORY_PROJECT_URL`, `ORY_OAUTH2_CLIENT_ID`,
+  `ORY_USER_SESSION_TOKEN` or `ORY_USER_OAUTH2_TOKEN`, optional
+  `ORY_AGENT_API_KEY`).
+- A pointer to {{REF_AUTH_SETUP}} for full env-var coverage and to
+  {{REF_LOCAL_DEV}} for testing the same plugin locally before publishing the
+  template.
+
+## Step 3 — Build and publish
+
+Walk the user through:
+
+```bash
+cd integrations/e2b
+cp .env.example .env        # then fill in E2B_API_KEY
+npm install
+npx e2b auth login          # one-time
+npm run build:prod          # publishes the tag chosen in Step 1
+```
+
+Manage the published template via the E2B CLI:
+
+```bash
+npx e2b template list
+npx e2b template delete <tag>
+```
+
+## Step 4 — Use the sandbox
+
+Show the user the minimal SDK call once their template is live:
+
+```ts
+import { Sandbox } from "e2b";
+
+const sbx = await Sandbox.create("agent-ory", {
+  envs: {
+    ORY_PROJECT_URL: process.env.ORY_PROJECT_URL!,
+    ORY_OAUTH2_CLIENT_ID: process.env.ORY_OAUTH2_CLIENT_ID!,
+    // Pre-supply a user token so the headless sandbox skips PKCE.
+    ORY_USER_SESSION_TOKEN: process.env.ORY_USER_SESSION_TOKEN!,
+  },
+});
+
+await sbx.commands.run("{{BIN}} --version");  // sanity check
+```
+
+Sandboxes are headless, so the user **must** pre-supply
+`ORY_USER_SESSION_TOKEN` or `ORY_USER_OAUTH2_TOKEN` — otherwise the auth gate's
+PKCE browser flow has no target and hangs. See {{REF_AUTH_SETUP}} for the full
+env-var matrix.
+
+## Step 5 — Promotion path
+
+The template ships with `ORY_PERMISSION_MODE=observe` baked in so first-run
+sandboxes never block. To promote a sandbox to hard enforcement without
+rebuilding the template, either pass `ORY_PERMISSION_MODE=enforce` at
+`Sandbox.create()` time, or run `{{NPX}} permissions enforce` inside a running
+sandbox. Run `{{NPX}} permissions bootstrap` first on a fresh Ory project so
+the `use` tuples exist before enforcement turns on.
+
+## What this skill does NOT do
+
+- It does not build or publish the template — the user runs the build, so
+  they can see logs and own the resulting tag.
+- It does not bake secrets into the image. `ORY_PROJECT_URL`, OAuth client IDs,
+  and any tokens are always passed at `Sandbox.create()` time.
+- It does not pin the harness CLI version inside the template. If the user
+  wants reproducibility, swap the unpinned `npmInstall([...])` for a tagged
+  version (e.g. `["@anthropic-ai/claude-code@1.2.3"]`) before building.
+- It does not modify the user's Ory project. Use {{REF_AUTH_SETUP}} to
+  provision the OAuth2 client and namespaces the sandbox will need.

package/dist/skills.d.ts

@@ -1,9 +1,10 @@
 /**
  * Canonical Ory agent skills and commands.
  *
- * The skill playbooks (auth-setup, login-flow, social-login, local-dev) and the
- * local-stack commands (local-up, local-down) live once, as token-bearing
- * templates under `packages/core/assets/`. Every harness plugin renders them
+ * The skill playbooks (auth-setup, login-flow, social-login, local-dev,
+ * permissions-onboarding, contribute-integration, build-integration,
+ * e2b-sandbox) and the local-stack commands (local-up, local-down) live once,
+ * as token-bearing templates under `packages/core/assets/`. Every harness plugin renders them
  * through {@link renderOrySkills} / {@link renderOryCommands}, substituting the
  * harness's CLI binary, package name, and the way it references sibling skills
  * and commands. Plugins then write the rendered docs into whatever location
@@ -50,7 +51,7 @@ export interface RenderProfileOptions {
     packageName: string;
 }
 /**
- * Render the four guide skills for a harness as `SKILL.md` documents.
+ * Render the guide skills for a harness as `SKILL.md` documents.
  */
 export declare function renderOrySkills(harness: string, opts: RenderProfileOptions): RenderedSkill[];
 /**

package/dist/skills.js

@@ -2,9 +2,10 @@
 /**
  * Canonical Ory agent skills and commands.
  *
- * The skill playbooks (auth-setup, login-flow, social-login, local-dev) and the
- * local-stack commands (local-up, local-down) live once, as token-bearing
- * templates under `packages/core/assets/`. Every harness plugin renders them
+ * The skill playbooks (auth-setup, login-flow, social-login, local-dev,
+ * permissions-onboarding, contribute-integration, build-integration,
+ * e2b-sandbox) and the local-stack commands (local-up, local-down) live once,
+ * as token-bearing templates under `packages/core/assets/`. Every harness plugin renders them
  * through {@link renderOrySkills} / {@link renderOryCommands}, substituting the
  * harness's CLI binary, package name, and the way it references sibling skills
  * and commands. Plugins then write the rendered docs into whatever location
@@ -70,6 +71,21 @@ const SKILL_SOURCES = [
         name: "ory-permissions-onboarding",
         file: "skills/permissions-onboarding/SKILL.md",
     },
+    {
+        id: "contribute-integration",
+        name: "ory-contribute-integration",
+        file: "skills/ory-contribute-integration/SKILL.md",
+    },
+    {
+        id: "build-integration",
+        name: "ory-build-integration",
+        file: "skills/ory-build-integration/SKILL.md",
+    },
+    {
+        id: "e2b-sandbox",
+        name: "ory-e2b-sandbox",
+        file: "skills/ory-e2b-sandbox/SKILL.md",
+    },
 ];
 const COMMAND_SOURCES = [
     {
@@ -177,7 +193,7 @@ function parseFrontmatter(markdown) {
 }
 // ─── Public render API ──────────────────────────────────────────────
 /**
- * Render the four guide skills for a harness as `SKILL.md` documents.
+ * Render the guide skills for a harness as `SKILL.md` documents.
  */
 function renderOrySkills(harness, opts) {
     const profile = buildProfile(harness, opts);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ory/argus",
-  "version": "0.4.0",
+  "version": "0.6.0",
   "description": "Ory Argus: the core API for building authentication, authorization, and audit into AI agent harness plugins, extensions, and custom integrations",
   "license": "Apache-2.0",
   "homepage": "https://ory.com",