npm - @h-rig/product-ad-website - Versions diffs - 0.0.6-alpha.283 - Mend

@h-rig/product-ad-website 0.0.6-alpha.283

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (38) hide show

package/README.md +3 -0
package/package.json +52 -0
package/site/assets/favicon.svg +1 -0
package/site/assets/og-card.png +0 -0
package/site/assets/rig.css +199 -0
package/site/assets/rig.js +66 -0
package/site/assets/search-index.json +1 -0
package/site/assets/site.css +46 -0
package/site/assets/site.js +510 -0
package/site/cli/index.html +88 -0
package/site/config/index.html +256 -0
package/site/docs/agent-tools/index.html +129 -0
package/site/docs/architecture/index.html +42 -0
package/site/docs/capabilities/index.html +84 -0
package/site/docs/entities/index.html +68 -0
package/site/docs/environment/index.html +62 -0
package/site/docs/faq/index.html +17 -0
package/site/docs/fleet-irc/index.html +44 -0
package/site/docs/gate/index.html +128 -0
package/site/docs/getting-started/index.html +50 -0
package/site/docs/glossary/index.html +31 -0
package/site/docs/index.html +68 -0
package/site/docs/operator/index.html +49 -0
package/site/docs/packages/index.html +36 -0
package/site/docs/pi-extensions/index.html +15 -0
package/site/docs/recipes/index.html +28 -0
package/site/docs/runs/index.html +35 -0
package/site/docs/security/index.html +29 -0
package/site/docs/server/index.html +27 -0
package/site/docs/swarm-commander/index.html +41 -0
package/site/docs/task-sources/index.html +129 -0
package/site/docs/troubleshooting/index.html +23 -0
package/site/docs/validators/index.html +177 -0
package/site/index.html +1653 -0
package/site/plugins/examples/index.html +419 -0
package/site/plugins/index.html +193 -0
package/site/skills/index.html +140 -0
package/site/variants/deck/index.html +1 -0

package/site/plugins/index.html ADDED Viewed

@@ -0,0 +1,193 @@
+<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Plugin authoring // RIG</title><meta property="og:image" content="https://how.rig-does.work/assets/og-card.png"><meta name="twitter:card" content="summary_large_image"><meta name="description" content="From definePlugin to a composed package: Rig's contribution types, the single-channel metadata+executable model, the capability model, and contract testing."><meta property="og:title" content="Plugin authoring // RIG"><meta property="og:description" content="From definePlugin to a composed package: Rig's contribution types, the single-channel metadata+executable model, the capability model, and contract testing."><link rel="stylesheet" href="../assets/rig.css?v=v9"><link rel="stylesheet" href="../assets/site.css?v=v9"><link rel="icon" type="image/svg+xml" href="../assets/favicon.svg"></head><body><canvas id="docfield"></canvas><nav class="nav"><div class="nav-in"><a class="brand" href="../index.html"><span class="mk"></span><span class="blk">Rig</span></a><button class="burger" onclick="document.getElementById('nl').classList.toggle('open')">menu</button><div class="nav-links" id="nl"><button class="nsearch" type="button" onclick="rigSearchOpen()">search<kbd>&#8984;K</kbd></button><a href="../index.html" class="">overview</a><a href="../docs/index.html" class="">docs</a><a href="../plugins/index.html" class="active">plugins</a><a href="../skills/index.html" class="">skills</a><a href="../cli/index.html" class="">cli</a><a href="../config/index.html" class="">config</a><a href="https://github.com/humanity-org/rig" class="ext">github</a></div></div></nav><div class="docwrap"><aside class="sidebar"><div class="grp">START</div><a href="../docs/index.html" class="">docs home</a><a href="../docs/capabilities/index.html" class="">capabilities</a><a href="../docs/getting-started/index.html" class="">getting started</a><div class="grp">RUN</div><a href="../docs/runs/index.html" class="">the run lifecycle</a><a href="../docs/operator/index.html" class="">operator guide</a><a href="../docs/swarm-commander/index.html" class="">swarm commander</a><a href="../docs/fleet-irc/index.html" class="">drone messages</a><a href="../docs/agent-tools/index.html" class="">agent tools</a><a href="../docs/gate/index.html" class="">the merge gate</a><a href="../docs/troubleshooting/index.html" class="">troubleshooting</a><div class="grp">ARCHITECTURE</div><a href="../docs/architecture/index.html" class="">how rig works</a><a href="../docs/entities/index.html" class="">entities & data model</a><a href="../docs/server/index.html" class="">OMP relay/web</a><a href="../docs/security/index.html" class="">security & trust</a><a href="../docs/environment/index.html" class="">environment variables</a><div class="grp">EXTEND</div><a href="../plugins/index.html" class="active">plugin authoring</a><a href="../plugins/examples/index.html" class="">plugin examples</a><a href="../docs/pi-extensions/index.html" class="">OMP/Pi extensions</a><a href="../skills/index.html" class="">skills</a><a href="../docs/task-sources/index.html" class="">task sources</a><a href="../docs/validators/index.html" class="">validators & hooks</a><div class="grp">OPERATE</div><a href="../cli/index.html" class="">cli reference</a><a href="../config/index.html" class="">rig.config.ts</a><a href="../docs/recipes/index.html" class="">recipes</a><a href="../docs/glossary/index.html" class="">glossary</a><a href="../docs/faq/index.html" class="">faq</a><div class="grp">ENGINE</div><a href="../docs/packages/index.html" class="">packages</a></aside><main class="doc"><h1>Plugin authoring</h1>
+<p class="lede">Almost everything in Rig is a plugin &mdash; the CLI launcher and the Rig session included. The <code>apps/rig</code> application composes the first-party graph; a project adds explicit executable packages through <code>rig.config.ts</code>. Live OMP capability comes from OMP/Pi packages such as <code>runtime.pi.packages</code>. Rig never scans disk, so if a package is not composed, it does not exist.</p>
+<h2 id="walkthrough">The walkthrough: definePlugin &rarr; published</h2>
+<p>Six steps from empty package to a composable plugin a consumer can <code>bun add</code>. No registry, no marketplace &mdash; npm is the distribution; live OMP capability still comes from OMP/Pi packages.</p>
+<table class="t"><thead><tr><th>step</th><th>what you do</th></tr></thead>
+<tbody>
+<tr><td>1. scaffold</td><td>A plain Bun/npm package: <code>bun init</code>, add <code>@rig/core</code> (and <code>@rig/contracts</code> types) as deps. One default export.</td></tr>
+<tr><td>2. declare</td><td><code>definePlugin({ name, version, contributes })</code> &mdash; validated against the <code>RigPlugin</code> schema at call time; invalid shapes throw immediately, not at dispatch time.</td></tr>
+<tr><td>3. implement</td><td>Executable contributions (validators, task sources, hooks&hellip;) carry their function on the same entry as their metadata &mdash; one object, no separate runtime channel. See <a href="#single-channel">the single-channel model</a>.</td></tr>
+<tr><td>4. test</td><td>Contract tests with <code>bun:test</code>: <code>definePlugin</code> throws on bad shape, ids namespace, and you call the executable fns directly off the returned object &mdash; no session required.</td></tr>
+<tr><td>5. wire</td><td>In a consuming project: <code>plugins: [myPlugin(options)]</code> in <code>rig.config.ts</code>. <code>rig plugin list</code> shows what it contributes; <code>rig plugin validate --task &lt;id&gt;</code> exercises its validators.</td></tr>
+<tr><td>6. publish</td><td><code>bun publish</code> like any npm package. Consumers <code>bun add</code> it and import it in their config &mdash; no registry, no marketplace step, npm is the distribution.</td></tr>
+</tbody></table>
+<h2 id="worked-examples">Worked examples <span class="ns">// copyable packages</span></h2>
+<p>The walkthrough is the contract. The examples are the sortie brief: three complete packages you can copy into a repo, wire through real config, and verify against the loaded plugin host. They cover the three extension seams teams usually need first:</p>
+<table class="t"><thead><tr><th>example</th><th>what it proves</th><th>load path</th></tr></thead><tbody>
+<tr><td><a href="examples/index.html#validator-plugin">validator plugin</a></td><td>A custom check enters the same validation gate as <code>std:typecheck</code>.</td><td><code>.rig/rig.config.ts</code> &mdash; executable plugin code.</td></tr>
+<tr><td><a href="examples/index.html#task-source-plugin">task-source plugin</a></td><td>A custom <code>taskSource.kind</code> resolves through the same factory path as the standard adapters.</td><td><code>.rig/rig.config.ts</code> &mdash; executable factory.</td></tr>
+<tr><td><a href="examples/index.html#pi-extension-package">OMP/Pi package</a></td><td>A live-session tool is pinned with <code>runtime.pi.packages</code> and materialized into <code>.pi/settings.json</code>.</td><td><code>rig.config.ts</code> or declarative <code>rigfig.toml</code> &mdash; package data, not a Rig plugin.</td></tr>
+</tbody></table>
+<p>Go to <a href="examples/index.html">plugin examples &rarr;</a> for the full file listings, config, verification steps, and the exact source seams each one relies on.</p>
+<h2 id="entry">The entry point</h2>
+<pre class="code"><span class="k">import</span> { definePlugin } <span class="k">from</span> <span class="s">"@rig/core"</span>;
+<span class="k">export default</span> <span class="f">definePlugin</span>({
+  name: <span class="s">"my-plugin"</span>,
+  version: <span class="s">"0.1.0"</span>,
+  contributes: { <span class="c">/* any subset of the eight types below */</span> },
+});</pre>
+<p><code>definePlugin</code> validates the shape against the <code>RigPlugin</code> schema in <code>@rig/contracts</code> and throws on invalid input. The return value is what you pass to <code>plugins: [...]</code>.</p>
+<div class="note"><b>Effect Schema</b> is the runtime schema/validation library Rig&rsquo;s contracts are written in &mdash; the same one used across <code>@rig/contracts</code>. Every <code>RigPlugin</code> field (<code>name</code>, <code>version</code>, each contribution type) is an Effect <code>Schema.Struct</code>, so <code>definePlugin</code> decodes your object against it and rejects the bad shape <i>before</i> anything boots. The whole plugin contract lives in one file: <code>packages/contracts/src/plugin.ts</code>.</div>
+<h3 id="where-contributions-land">Where each contribution lands <span class="ns">// metadata in, registry out</span></h3>
+<p>Every contribution is two things: metadata at config-load time, a registry entry at boot. The plugin host (<code>@rig/core</code>) flattens all composed plugins, dedupes the ids, then routes each contribution type to its own registry:</p>
+<pre class="code"><span class="c">// appPluginGraph + rig.config.ts project extras</span>
+       <span class="p">&darr;</span>
+<span class="f">createPluginHost</span>(plugins)        <span class="c">// flatten + dedupe ids, enforce namespacing</span>
+       <span class="p">&darr;</span>
+&#9500;&#9472; validators        <span class="p">&rarr;</span> <span class="f">createValidatorRegistry</span>     <span class="c">// in-process run(ctx)</span>
+&#9500;&#9472; hooks             <span class="p">&rarr;</span> harness settings file        <span class="c">// managed files</span>
+&#9500;&#9472; skills            <span class="p">&rarr;</span> <span class="s">.pi/skills/&lt;id&gt;/</span>          <span class="c">// materialized SKILL.md</span>
+&#9500;&#9472; repoSources       <span class="p">&rarr;</span> <span class="f">createRepoRegistry</span>
+&#9500;&#9472; agentRoles        <span class="p">&rarr;</span> <span class="f">createAgentRoleRegistry</span>     <span class="c">// role:&lt;id&gt; &rarr; model</span>
+&#9500;&#9472; taskFieldSchemas  <span class="p">&rarr;</span> <span class="f">createTaskFieldRegistry</span>
+&#9500;&#9472; taskSources       <span class="p">&rarr;</span> <span class="f">buildTaskSourceRegistry</span>     <span class="c">// resolved by kind</span>
+&#9500;&#9472; panels            <span class="p">&rarr;</span> read-model presentation cargo <span class="c">// display metadata for session surfaces</span>
+&#9500;&#9472; capabilities      <span class="p">&rarr;</span> capability resolver       <span class="c">// provides / requires / replaces</span>
+&#9492;&#9472; cliCommands       <span class="p">&rarr;</span> the <span class="s">rig</span> command surface</pre>
+<p>Every registry above lives in <code>@rig/core</code> (kernel capabilities resolve through <code>@rig/kernel-seed</code>). Contributions carry their executable fn on the <em>same</em> entry as their metadata &mdash; see <a href="#single-channel">the single-channel model</a>.</p>
+<h2 id="namespacing">Namespacing</h2>
+<p>Every registration id is <code>&lt;plugin-name&gt;:&lt;local-id&gt;</code> (e.g. <code>my-plugin:typecheck</code>). The plugin host (<code>@rig/core</code>) throws at config-load time on duplicate plugin names, duplicate contribution ids, duplicate executable task-source kinds, and metadata/runtime drift.</p>
+<h2 id="types">The contribution types</h2>
+<table class="t"><thead><tr><th>type</th><th>what it adds</th></tr></thead>
+<tbody>
+<tr><td><code>validators</code></td><td>Pass/fail gates that run at task completion (carry an executable <code>run(ctx)</code>).</td></tr>
+<tr><td><code>hooks</code></td><td><code>PreToolUse</code> / <code>PostToolUse</code> / <code>UserPromptSubmit</code> / <code>Stop</code> / <code>SessionStart</code> / <code>SessionEnd</code> hooks, written into the active harness settings file.</td></tr>
+<tr><td><code>skills</code></td><td>SKILL.md prompt context, materialized into <code>.pi/skills/&lt;id&gt;/</code>.</td></tr>
+<tr><td><code>repoSources</code></td><td>External repositories the runtime may clone/reference.</td></tr>
+<tr><td><code>agentRoles</code></td><td><code>role:&lt;id&gt;</code> &rarr; model resolution.</td></tr>
+<tr><td><code>taskFieldSchemas</code></td><td>Structured fields parsed from issue-body blocks.</td></tr>
+<tr><td><code>taskSources</code></td><td><code>kind</code>-keyed task adapters (carry an executable <code>factory</code>; even first-party ones resolve this way).</td></tr>
+<tr><td><code>cliCommands</code></td><td>Commands callable directly as <code>rig &lt;command&gt;</code> (or <code>rig plugin run &lt;id&gt;</code>).</td></tr>
+<tr><td><code>stages</code> / <code>stageMutations</code></td><td>Run-lifecycle stages and mutations (validate / verify / commit / push / PR / merge&hellip;).</td></tr>
+<tr><td><code>capabilities</code></td><td>Named product capabilities other plugins resolve through the capability model.</td></tr>
+<tr><td><code>panels</code></td><td>Read-model presentation cargo &mdash; display metadata consumed by session surfaces. Reach for <code>sessionExtensions</code> when you need live in-session tools.</td></tr>
+<tr><td><code>blockerClassifiers</code></td><td>Classifiers that label why a run is blocked.</td></tr>
+<tr><td><code>sessionExtensions</code></td><td>Executable installers wired into the OMP/Pi session at creation time.</td></tr>
+<tr><td><code>seedEntrypoints</code></td><td>Bootstrap entrypoints resolved through the <code>@rig/kernel-seed</code> plugin ABI.</td></tr>
+</tbody></table>
+<h2 id="single-channel">The single-channel model: metadata + executable, one object</h2>
+<p>A plugin is <b>one object</b>. Each <code>contributes</code> entry carries its schema-validated metadata <em>and</em> its executable fn together &mdash; there is no second <code>definePlugin</code> argument and no separate runtime channel. Effect Schema can&rsquo;t represent functions, so <code>definePlugin</code> decodes the object against the metadata manifest and simply ignores the fns (Schema strips excess), returning the original object unchanged with its fns intact:</p>
+<pre class="code"><span class="k">export default</span> <span class="f">definePlugin</span>({
+  name: <span class="s">"my-plugin"</span>, version: <span class="s">"0.1.0"</span>,
+  contributes: {
+    validators: [{
+      id: <span class="s">"my-plugin:typecheck"</span>, category: <span class="s">"integration"</span>,   <span class="c">// metadata…</span>
+      <span class="k">async</span> <span class="f">run</span>(ctx) {                                    <span class="c">// …and the executable fn, same entry</span>
+        <span class="c">// ctx: { taskId, workspaceRoot, scope, monorepoRoot?, artifactsDir?, taskConfig? }</span>
+        <span class="k">return</span> { id: <span class="s">"my-plugin:typecheck"</span>, passed: <span class="k">true</span>, summary: <span class="s">"ok"</span> };
+      },
+    }],
+  },
+});</pre>
+<p>The plugin host auto-registers each executable into the <code>ValidatorRegistry</code> at boot; <code>taskValidate</code> dispatches <b>in-process</b>, no subprocess. Because the fn rides on the returned object, tests reach it directly (<code>plugin.contributes?.validators?.[0].run(ctx)</code>) without booting a session. Kernel capability implementations ride the same way, in a <code>capabilityProviders</code> map keyed by the tag the plugin <code>provides</code>.</p>
+<h2 id="validators">Validators</h2>
+<p>Categories: <code>boundary</code> &middot; <code>contract</code> &middot; <code>integration</code> &middot; <code>regression</code> &middot; <code>external</code> &middot; <code>custom</code>. Result shape: <code>{ id, passed, summary, details? }</code>. Wire one to a task with a <code>validator:&lt;id&gt;</code> label, or exercise a plugin&rsquo;s validators against a task with <code>rig plugin validate --task &lt;id&gt;</code>. For how validators and hooks behave at run time &mdash; categories, the gate, hook events &mdash; see <a href="../docs/validators/index.html">validators &amp; hooks &rarr;</a>.</p>
+<h2 id="hooks">Hooks</h2>
+<pre class="code">hooks: [{
+  id: <span class="s">"my-org:stop-check"</span>,
+  event: <span class="s">"Stop"</span>,                       <span class="c">// one of the six HookEvent literals</span>
+  matcher: { kind: <span class="s">"all"</span> },            <span class="c">// "all" | { kind: "tool", name } | { kind: "glob", pattern }</span>
+  command: <span class="s">"/repo/scripts/my-stop-check.sh"</span>,
+}]</pre>
+<p>Written into the active harness settings file when Rig prepares the workspace. The materializer is idempotent &mdash; operator-authored entries (no <code>_rigPlugin</code> marker) are preserved; plugin-owned entries are replaced and tagged <code>_rigPlugin: "&lt;plugin&gt;"</code>. A hook may ship a shell <code>command</code> or a typed implementation (<code>{ hooks: { [hookId]: fn } }</code> on the same plugin object); the runtime materializes a shim command for typed hooks automatically.</p>
+<h2 id="skills">Skills</h2>
+<pre class="code">skills: [{
+  id: <span class="s">"my-plugin:boundary-analysis"</span>,
+  path: <span class="k">new</span> <span class="f">URL</span>(<span class="s">"skills/boundary-analysis/SKILL.md"</span>, import.meta.url).pathname,
+  description: <span class="s">"Boundary analysis prompt"</span>,
+}]</pre>
+<p>On boot the runtime validates each skill and materializes it into <code>.pi/skills/&lt;id&gt;/SKILL.md</code> &mdash; OMP/Pi&rsquo;s project-scope directory, scanned natively at session start (so plugin skills reach the live session too). Each materialized dir carries a <code>.rig-plugin</code> marker; re-materialization replaces only plugin-owned skills and never touches operator-authored ones. See <a href="../skills/index.html">skills &rarr;</a>.</p>
+<h2 id="misc">repoSources, agentRoles, taskFieldSchemas</h2>
+<pre class="code">repoSources: [{ id: <span class="s">"my-plugin:main-repo"</span>, url: <span class="s">"https://github.com/org/repo"</span>, defaultPath: <span class="s">"repos/main-repo/"</span> }]
+agentRoles:  [{ id: <span class="s">"my-plugin:architect"</span>, defaultModel: <span class="s">"team-default"</span> }]
+taskFieldSchemas: [{ id: <span class="s">"my-plugin:browser-field"</span>, fieldName: <span class="s">"Browser"</span>, schemaJson: <span class="s">"{...}"</span> }]</pre>
+<p>A <code>Browser:</code> block in an issue body is parsed as JSON and validated against <code>schemaJson</code> by <code>createTaskFieldRegistry</code>, then passed to the agent under the field name. Agent roles resolve <code>role:&lt;id&gt;</code> task labels to models; repo sources can optionally carry managed-mirror fields (<code>defaultBranch</code>, <code>remoteEnvVar</code>, <code>checkoutEnvVar</code>) when Rig should sync the repo on the plugin&rsquo;s behalf.</p>
+<h3 id="schemajson-format">The <code>schemaJson</code> format <span class="ns">// JSON in, presence out</span></h3>
+<p><code>schemaJson</code> is a <b>JSON string</b> &mdash; a JSON-serialized schema-like payload, not an object. Use <code>JSON.stringify(&hellip;)</code> when you author it:</p>
+<pre class="code">taskFieldSchemas: [{
+  id: <span class="s">"my-plugin:browser-field"</span>,
+  fieldName: <span class="s">"Browser"</span>,
+  schemaJson: <span class="f">JSON.stringify</span>({
+    type: <span class="s">"object"</span>,
+    properties: { url: { type: <span class="s">"string"</span> }, viewport: { type: <span class="s">"string"</span> } },
+    required: <span class="k">true</span>,            <span class="c">// top-level boolean — the presence signal Rig reads</span>
+  }),
+}]</pre>
+<p>The payload is <b>opaque to the engine</b>: Rig does not deep-validate properties or JSON-Schema constraints. It reads exactly one thing &mdash; a <b>top-level <code>"required": true</code></b> &mdash; as the canonical &ldquo;this field must be present on the task&rdquo; marker. With that set, a task whose <code>fieldName</code> value is missing, <code>null</code>, or empty fails <code>validateTaskFields</code> with a collected error. Without it, the extension is optional and the schema is yours to interpret however your plugin or agent prompt wants. Note this is a <i>top-level</i> boolean <code>required: true</code>, distinct from JSON Schema&rsquo;s per-property <code>required: ["url"]</code> array (which Rig ignores).</p>
+<h2 id="tasksources">taskSources</h2>
+<pre class="code">taskSources: [{ id: <span class="s">"my-plugin:linear"</span>, kind: <span class="s">"linear"</span>, description: <span class="s">"Linear issues adapter"</span> }]</pre>
+<p><code>kind</code> is an open string &mdash; name yours whatever you like (<code>"linear"</code>, <code>"jira"</code>, <code>"my-org:queue"</code>). <code>buildTaskSourceRegistry(config, pluginHost)</code> reads <code>config.taskSource.kind</code>, finds a matching executable factory on the plugin host, and instantiates the source; uniqueness is enforced at resolution. There are <b>no hard-coded kinds</b>: the application graph contributes GitHub Issues, and project plugin extras contribute Linear or any custom source through the same resolver. Source-specific config rides in the <code>taskSource.options</code> bag. The full first-party source shapes, label conventions, and write-back behaviour live on the <a href="../docs/task-sources/index.html">task sources page &rarr;</a></p>
+<h2 id="clicommands">cliCommands</h2>
+<pre class="code">cliCommands: [{ id: <span class="s">"my-plugin:report"</span>, command: <span class="s">"report"</span>, description: <span class="s">"Generate the weekly report"</span> }]</pre>
+<p>Callable as <code>rig plugin run report</code> &mdash; or directly as <code>rig report</code>; plugin-contributed commands join the top-level CLI surface.</p>
+<h2 id="testing">Contract testing</h2>
+<p>Don&rsquo;t ship a plugin you haven&rsquo;t run through a contract test. There is no separate testkit &mdash; <code>definePlugin</code> <em>is</em> the contract check: it decodes your object against the <code>RigPlugin</code> schema in <code>@rig/contracts</code> and throws on a bad shape (missing/duplicate ids, bad name/version, under-declared effects). Since the executable fns ride on the same object, you call them directly &mdash; no session required:</p>
+<pre class="code"><span class="c">// my-plugin.contract.test.ts</span>
+<span class="k">import</span> { describe, it, expect } <span class="k">from</span> <span class="s">"bun:test"</span>;
+<span class="k">import</span> myPlugin <span class="k">from</span> <span class="s">"./src/index"</span>;
+<span class="k">const</span> plugin = <span class="f">myPlugin</span>();
+<span class="f">describe</span>(<span class="s">"my-plugin contract"</span>, () =&gt; {
+  <span class="c">// 1) construction itself is the metadata contract — definePlugin threw if the shape was bad</span>
+  <span class="f">it</span>(<span class="s">"declares namespaced ids"</span>, () =&gt; {
+    <span class="k">const</span> v = plugin.contributes?.validators?.[<span class="p">0</span>];
+    <span class="f">expect</span>(v?.id).<span class="f">toMatch</span>(/^my-plugin:/);
+  });
+  <span class="c">// 2) call the executable validator directly, off the same object</span>
+  <span class="f">it</span>(<span class="s">"validator runs and passes"</span>, <span class="k">async</span> () =&gt; {
+    <span class="k">const</span> v = plugin.contributes?.validators?.[<span class="p">0</span>];
+    <span class="k">const</span> result = <span class="k">await</span> v!.<span class="f">run</span>({ taskId: <span class="s">"t-1"</span>, workspaceRoot: <span class="s">"/tmp/x"</span>, scope: [<span class="s">"src/a.ts"</span>] });
+    <span class="f">expect</span>(result.passed).<span class="f">toBe</span>(<span class="k">true</span>);
+  });
+  <span class="c">// 3) exercise a custom task-source factory by kind</span>
+  <span class="f">it</span>(<span class="s">"task source resolves its kind"</span>, () =&gt; {
+    <span class="k">const</span> ts = plugin.contributes?.taskSources?.[<span class="p">0</span>];
+    <span class="k">const</span> src = ts!.<span class="f">factory</span>({ kind: ts!.kind });
+    <span class="f">expect</span>(src.kind).<span class="f">toBe</span>(ts!.kind);
+  });
+});</pre>
+<p>Run it with <code>bun test</code> &mdash; the same runner the engine uses. Metadata is verified by construction; hook and skill <i>dispatch</i> are the runtime&rsquo;s job, so cover end-to-end hook behaviour with your own integration test.</p>
+<h2 id="working-examples">Living references in the repo</h2>
+<p>The first-party plugins under <code>packages/</code> are the reference implementations &mdash; real, composed, contract-tested code rather than toy snippets:</p>
+<ul>
+<li><b><code>packages/tasks-plugin/</code></b> &mdash; the single tasks capability: source access, source adapters, and read-only derived state. The canonical <code>taskSources</code> + read-model shape.</li>
+<li><b><code>packages/github-provider-plugin/</code></b> &mdash; a swappable SCM provider (auth, credentials, Projects, issue analysis) contributed as a capability. Good for seeing <code>provides</code>/<code>requires</code> and <code>capabilityProviders</code> in practice.</li>
+<li><b><code>packages/config-plugin/</code></b> &mdash; a compact plugin that contributes both a CLI command (<code>rig config get/set</code>) and read-model presentation cargo via a panel. A clean template for a command + display contribution.</li>
+</ul>
+<p>Copy the closest match, rename the <code>&lt;plugin-name&gt;:</code> id prefix everywhere, and fill in your own <code>factory(config)</code> and <code>run(ctx)</code> logic.</p>
+<h2 id="see-also">See also</h2>
+<ul>
+<li><a href="examples/index.html">Plugin examples</a> &mdash; complete validator, task-source, and OMP/Pi extension packages with load and verification steps.</li>
+<li><a href="../docs/validators/index.html">Validators &amp; hooks</a> &mdash; run-time behaviour of the two channels you contribute most.</li>
+<li><a href="../docs/task-sources/index.html">Task sources</a> &mdash; the first-party <code>github-issues</code> / <code>linear</code> adapters and their conventions.</li>
+<li><a href="../skills/index.html">Skills</a> &mdash; SKILL.md authoring and how plugin skills reach the OMP/Pi session.</li>
+<li><a href="../docs/pi-extensions/index.html">OMP/Pi extensions</a> &mdash; the other half: extend the live OMP session, not the workflow automation Rig runs around it.</li>
+<li><a href="../config/index.html">rig.config.ts</a> &mdash; where <code>plugins: [...]</code> and <code>taskSource</code> are declared.</li>
+</ul>
+<div class="note"><b>Plugins extend the workflow automation Rig runs around a session; OMP/Pi extensions extend the live session.</b> If what you want is a new tool or slash command <i>inside OMP</i>, you want an <a href="../docs/pi-extensions/index.html">OMP/Pi extension</a>, not a Rig plugin. The two compose: a Rig plugin declares workflow metadata; an OMP/Pi package acts at session start.</div>
+<div class="nextnav"><a href="../docs/environment/index.html"><span class="dir">&larr; Back</span><span class="ttl">Environment variables</span></a><a href="../plugins/examples/index.html"><span class="dir">Next &rarr;</span><span class="ttl">Plugin examples</span></a></div>
+</main></div><footer><div class="wrap"><div class="foot"><div class="col"><h5>orchestrate</h5><a href="../docs/getting-started/index.html">getting started</a><a href="../docs/runs/index.html">the run lifecycle</a><a href="../docs/operator/index.html">operator guide</a><a href="../docs/gate/index.html">the merge gate</a></div><div class="col"><h5>extend</h5><a href="../plugins/index.html">plugin authoring</a><a href="../skills/index.html">skills guide</a><a href="../docs/pi-extensions/index.html">OMP/Pi extensions</a><a href="../docs/packages/index.html">packages</a></div><div class="col"><h5>live</h5><a href="../index.html">the home rig</a><a href="../cli/index.html">cli reference</a><a href="https://where.rig-does.work/install">install script</a></div><div class="sig">Rig is the OMP session extension.<br><span class="blk">You are the operator.</span><br>release: rig --version</div></div></div></footer><script src="../assets/rig.js"></script><script src="../assets/site.js?v=v9"></script></body></html>

package/site/skills/index.html ADDED Viewed

@@ -0,0 +1,140 @@
+<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1"><title>Skills // RIG</title><meta property="og:image" content="https://how.rig-does.work/assets/og-card.png"><meta name="twitter:card" content="summary_large_image"><meta name="description" content="Author SKILL.md prompt context, ship it in a plugin, and understand how Rig materializes skills for OMP/Pi sessions without scanning arbitrary packages."><meta property="og:title" content="Skills // RIG"><meta property="og:description" content="Author SKILL.md prompt context, ship it in a plugin, and understand how Rig materializes skills for OMP/Pi sessions without scanning arbitrary packages."><link rel="stylesheet" href="../assets/rig.css?v=v9"><link rel="stylesheet" href="../assets/site.css?v=v9"><link rel="icon" type="image/svg+xml" href="../assets/favicon.svg"></head><body><canvas id="docfield"></canvas><nav class="nav"><div class="nav-in"><a class="brand" href="../index.html"><span class="mk"></span><span class="blk">Rig</span></a><button class="burger" onclick="document.getElementById('nl').classList.toggle('open')">menu</button><div class="nav-links" id="nl"><button class="nsearch" type="button" onclick="rigSearchOpen()">search<kbd>&#8984;K</kbd></button><a href="../index.html" class="">overview</a><a href="../docs/index.html" class="">docs</a><a href="../plugins/index.html" class="">plugins</a><a href="../skills/index.html" class="active">skills</a><a href="../cli/index.html" class="">cli</a><a href="../config/index.html" class="">config</a><a href="https://github.com/humanity-org/rig" class="ext">github</a></div></div></nav><div class="docwrap"><aside class="sidebar"><div class="grp">START</div><a href="../docs/index.html" class="">docs home</a><a href="../docs/capabilities/index.html" class="">capabilities</a><a href="../docs/getting-started/index.html" class="">getting started</a><div class="grp">RUN</div><a href="../docs/runs/index.html" class="">the run lifecycle</a><a href="../docs/operator/index.html" class="">operator guide</a><a href="../docs/swarm-commander/index.html" class="">swarm commander</a><a href="../docs/fleet-irc/index.html" class="">drone messages</a><a href="../docs/agent-tools/index.html" class="">agent tools</a><a href="../docs/gate/index.html" class="">the merge gate</a><a href="../docs/troubleshooting/index.html" class="">troubleshooting</a><div class="grp">ARCHITECTURE</div><a href="../docs/architecture/index.html" class="">how rig works</a><a href="../docs/entities/index.html" class="">entities & data model</a><a href="../docs/server/index.html" class="">OMP relay/web</a><a href="../docs/security/index.html" class="">security & trust</a><a href="../docs/environment/index.html" class="">environment variables</a><div class="grp">EXTEND</div><a href="../plugins/index.html" class="">plugin authoring</a><a href="../plugins/examples/index.html" class="">plugin examples</a><a href="../docs/pi-extensions/index.html" class="">OMP/Pi extensions</a><a href="../skills/index.html" class="active">skills</a><a href="../docs/task-sources/index.html" class="">task sources</a><a href="../docs/validators/index.html" class="">validators & hooks</a><div class="grp">OPERATE</div><a href="../cli/index.html" class="">cli reference</a><a href="../config/index.html" class="">rig.config.ts</a><a href="../docs/recipes/index.html" class="">recipes</a><a href="../docs/glossary/index.html" class="">glossary</a><a href="../docs/faq/index.html" class="">faq</a><div class="grp">ENGINE</div><a href="../docs/packages/index.html" class="">packages</a></aside><main class="doc"><h1>Skills</h1>
+<p class="lede">A skill is standing prompt context for an OMP/Pi session &mdash; a <code>SKILL.md</code> file, YAML frontmatter plus a markdown body, that a plugin ships and Rig materializes verbatim into <code>.pi/skills/</code> where OMP/Pi reads it.</p>
+<h2 id="what-a-skill-is">What a skill is <span class="ns">// reusable prompt context</span></h2>
+<p>An OMP/Pi session starts from a base prompt plus whatever context the work carries. A skill injects <em>standing</em> context on top of that &mdash; a procedure, a checklist, a house rule &mdash; so you brief the session once instead of pasting it into every issue. The format is deliberately boring: a markdown file with a small YAML header. No build step, no runtime, no code path. The frontmatter names the skill; the body <em>is</em> the prompt.</p>
+<p>Skills reach OMP/Pi by being copied into the directory it scans. Rig&rsquo;s job is to take the <code>SKILL.md</code> files a plugin declares, validate them, and place them where OMP/Pi looks. Discovery is native from there.</p>
+<div class="note">A skill is content, not behavior. If you need to <em>add a tool, a slash command, or a hook</em>, that&rsquo;s a <a href="../docs/pi-extensions/index.html">Pi extension</a> or a <a href="../docs/validators/index.html">hook</a>, not a skill. See <a href="#skills-vs-extensions-vs-hooks">skills vs. extensions vs. hooks</a> below for the dividing line.</div>
+<h2 id="skill-md-format">The SKILL.md format <span class="ns">// frontmatter + body</span></h2>
+<p>One file. The frontmatter block is delimited by <code>---</code> lines; everything after the closing delimiter is the body. Here is a real, non-trivial skill &mdash; a boundary-analysis procedure an OMP/Pi session can follow when asked to touch module edges:</p>
+<pre class="code"><span class="c">---</span>
+name: boundary-analysis
+description: How to reason about module boundaries before editing across them
+owner: platform-team
+priority: high
+<span class="c">---</span>
+<span class="c"># Boundary analysis</span>
+Before editing code that crosses a package or module boundary, do this:
+1. Identify the boundary. Name the two sides and the contract between them
+   (the exported types, the function signatures, the event shapes).
+2. Decide which side owns the change. A change is &quot;upstream&quot; if it alters
+   the contract, &quot;downstream&quot; if it only consumes it. Prefer downstream.
+3. If the change is upstream, list every downstream consumer first. Do not
+   edit the contract until you have the full blast radius written down.
+4. Keep the diff on one side of the boundary per commit where possible.
+   A commit that edits both the producer and three consumers is hard to
+   review and hard to revert.
+When in doubt, widen the type on the producer and narrow on the consumer,
+never the reverse &mdash; that keeps old callers working.</pre>
+<p>The body can be any length and any markdown. It is copied verbatim, so write it for the OMP/Pi session the way you would brief a new engineer: concrete steps, not vibes.</p>
+<h3 id="frontmatter-fields">Frontmatter fields</h3>
+<p>The loader parses the header line-by-line into key/value pairs. <code>name</code> is the only required field. Everything else is optional and free-form.</p>
+<table class="t"><thead><tr><th>field</th><th>required</th><th>meaning</th></tr></thead>
+<tbody>
+<tr><td>name</td><td>yes</td><td>The skill&rsquo;s human name. Must be a string, or the skill is skipped with a warning at materialization.</td></tr>
+<tr><td>description</td><td>no</td><td>One-line summary. Carried on the plugin&rsquo;s skill registration, not required in the frontmatter.</td></tr>
+<tr><td><i>any other key</i></td><td>no</td><td>Arbitrary extra keys are tolerated (e.g. <code>owner</code>, <code>priority</code>). The parser coerces <code>true</code>/<code>false</code>, integers, and decimals and unquotes quoted strings while validating, then copies the file through unchanged.</td></tr>
+</tbody></table>
+<div class="note">The frontmatter parser is intentionally small &mdash; it is line-based, not a full YAML engine. Keep each field on its own <code>key: value</code> line. Lines starting with <code>#</code> and blank lines inside the header are ignored. Nested YAML structures are not parsed. <b>Keep the header flat.</b></div>
+<h2 id="contributing-a-skill">How a plugin contributes a skill <span class="ns">// the registration</span></h2>
+<p>A plugin-contributed skill reaches OMP/Pi through explicit Rig materialization &mdash; nothing is scanned from arbitrary packages. A plugin declares each one in its <code>contributes.skills</code> array with a namespaced id and a path to the <code>SKILL.md</code> on disk:</p>
+<pre class="code">contributes: {
+  skills: [{
+    id: <span class="s">"my-plugin:boundary-analysis"</span>,
+    path: <span class="k">new</span> <span class="f">URL</span>(<span class="s">"skills/boundary-analysis/SKILL.md"</span>, import.meta.url).pathname,
+    description: <span class="s">"Boundary analysis prompt"</span>,
+  }]
+}</pre>
+<p>The <code>id</code> follows the standard <code>&lt;plugin-name&gt;:&lt;local-id&gt;</code> namespacing convention and must be unique across loaded plugins. For the <code>path</code>: use an absolute path (via <code>import.meta.url</code>) for npm-installed plugins, since the package can be unpacked anywhere; a relative path is resolved against the project root. The full plugin shape lives in <a href="../plugins/index.html">plugin authoring &rarr;</a>.</p>
+<h2 id="the-loader">Validation <span class="ns">// what the materializer checks</span></h2>
+<p>The skill materializer inside Rig&rsquo;s provider plugin turns each declared <code>SKILL.md</code> into a materialized directory. Before it copies a file it does one check: split the frontmatter from the body, parse the header, and enforce that a string <code>name</code> exists. If that passes, the <em>whole</em> file is copied through byte for byte &mdash; frontmatter and body together, exactly as the author wrote it.</p>
+<h3 id="loader-behavior">What validation guarantees</h3>
+<ul>
+<li><b>name is mandatory.</b> If the parsed frontmatter has no string <code>name</code>, the materializer throws <code>SKILL.md missing required field "name"</code> for that file, skips it with a warning, and keeps going. A file with no frontmatter at all fails the same way &mdash; no header means no <code>name</code>.</li>
+<li><b>the file is copied verbatim.</b> The materialized <code>SKILL.md</code> is the source file unchanged &mdash; frontmatter, body, whitespace and all &mdash; so the session sees exactly what the author wrote.</li>
+<li><b>the header parser is lenient.</b> Extra keys beyond <code>name</code> and <code>description</code> are tolerated, not rejected. The parser is line-based, not a full YAML engine.</li>
+<li><b>scalars are coerced while parsing.</b> <code>true</code>/<code>false</code> become booleans; integer and decimal strings become numbers; single- or double-quoted strings are unquoted &mdash; this feeds the <code>name</code> check, and does not alter the copied file.</li>
+</ul>
+<p>This is the same validation Rig runs on every boot. There is no second, hidden validator.</p>
+<h2 id="materialization">Materialization <span class="ns">// placing skills where OMP/Pi looks</span></h2>
+<p>This is where the skill becomes a file the OMP/Pi session can read. During explicit Rig materialization, the plugin host flattens every configured plugin&rsquo;s <code>contributes.skills</code> into one list and writes it into the workspace. Each skill becomes a directory under <code>.pi/skills/</code> holding the verbatim <code>SKILL.md</code> plus a marker file. The directory name is the skill id with every run of non-directory-safe characters replaced by <code>-</code> &mdash; so <code>my-plugin:boundary-analysis</code> lands at <code>.pi/skills/my-plugin-boundary-analysis/SKILL.md</code>.</p>
+<pre class="code"><span class="c">// project root</span>
+.pi/
+<span class="p">&#9492;&#9472;</span> skills/
+   <span class="p">&#9492;&#9472;</span> my-plugin-boundary-analysis/   <span class="c">// &lt;sanitized-id&gt;</span>
+      <span class="p">&#9500;&#9472;</span> SKILL.md                    <span class="c">// copied verbatim from the plugin</span>
+      <span class="p">&#9492;&#9472;</span> .rig-plugin                 <span class="c">// { "plugin": "my-plugin", "skillId": "my-plugin:boundary-analysis" }</span></pre>
+<p>This is the same directory OMP/Pi scans natively. OMP/Pi looks in <code>&lt;cwd&gt;/.pi/skills/</code> (project scope) and <code>~/.pi/agent/skills/</code> (user scope). Rig only ever writes the project-scope copy; the user-scope directory is yours.</p>
+<div class="note"><b>Correction worth stating plainly:</b> the project-scope skill directory is <code>.pi/skills/</code> &mdash; not <code>.agents/skills/</code>. The materialized location and OMP/Pi&rsquo;s scan path are the same <code>.pi/skills/</code> tree.</div>
+<p>Current boot path: Rig resolves the project plugin host, asks the provider-owned session asset materializer to run, and that materializer handles both sides of the OMP/Pi handoff. Plugin skills are copied into <code>.pi/skills/</code>; config-declared Pi packages from <code>runtime.pi.packages</code> are merged into <code>.pi/settings.json</code> with Rig-managed package state tracked separately in <code>.rig/state/pi-managed-packages.json</code>. The settings file stays Pi-native &mdash; no Rig marker fields are added to it.</p>
+<h3 id="idempotency-and-the-marker">Idempotency &amp; the .rig-plugin marker</h3>
+<p>Materialization is idempotent and safe to run on every boot. Before writing the current set, Rig scans <code>.pi/skills/</code> and deletes <em>only</em> directories that carry a <code>.rig-plugin</code> marker, then re-inserts the current plugin skills. The marker is a small JSON file recording the owning plugin and the skill id:</p>
+<pre class="code"><span class="p">{</span>
+  <span class="s">"plugin"</span>: <span class="s">"my-plugin"</span>,
+  <span class="s">"skillId"</span>: <span class="s">"my-plugin:boundary-analysis"</span>
+<span class="p">}</span></pre>
+<p>Because the delete is gated on the marker, the cycle converges: a plugin you removed from <code>rig.config.ts</code> loses its materialized directory on the next boot, and a plugin you kept gets exactly one fresh copy.</p>
+<h3 id="operator-sovereignty">Operator sovereignty</h3>
+<p>Any skill directory <em>without</em> a <code>.rig-plugin</code> marker is treated as operator-authored and is never deleted, never overwritten. You can drop your own <code>SKILL.md</code> into <code>.pi/skills/</code> by hand and it will sit alongside plugin skills untouched across every re-materialization. <b>Plugin-owned is replaceable; operator-owned is sovereign.</b></p>
+<div class="note"><b>The same discipline applies to hooks.</b> Plugin hooks are written into the active harness settings file with their own plugin marker; operator-authored hook entries are preserved on re-materialization. One rule across skills and hooks: marked = managed by Rig, unmarked = yours. See <a href="../docs/validators/index.html">validators &amp; hooks &rarr;</a>.</div>
+<h3 id="boot-safety">Boot-safety &mdash; a bad skill never blocks a run</h3>
+<p>Materialization is non-fatal by design. If a declared <code>SKILL.md</code> is missing on disk, or fails frontmatter validation (no string <code>name</code>), Rig skips that one skill with a warning and continues &mdash; it does not abort the OMP/Pi session boot. The validated file is then copied verbatim, so the session sees exactly what the author wrote, byte for byte.</p>
+<h2 id="reproducibility">Reproducibility, honestly <span class="ns">// what &ldquo;pinned&rdquo; does and doesn&rsquo;t mean</span></h2>
+<p>Skills are reproducible in the plain sense: the <code>SKILL.md</code> is a file checked into the plugin (or the project), and materialization copies it verbatim. Two operators on the same plugin version get the same skill body. That is the whole story.</p>
+<div class="note">There is <b>no separate version-lock or pin mechanism</b> for an individual skill beyond the plugin&rsquo;s own version. Reproducibility comes from the plugin being pinned in <a href="../config/index.html">rig.config.ts</a> and the file being copied unchanged &mdash; not from any per-skill pin. If you want a skill frozen, freeze the plugin version that ships it.</div>
+<h2 id="loading-a-skill-in-tests">Testing a skill</h2>
+<p>Verify a skill the same way Rig does &mdash; materialize it into a scratch project root and assert the file landed. A valid skill writes <code>.pi/skills/&lt;sanitized-id&gt;/SKILL.md</code> and is reported in the returned list; an invalid one is skipped and the list comes back empty:</p>
+<pre class="code"><span class="c">// materialize into a temp root, then assert on the result</span>
+<span class="k">const</span> written = <span class="k">await</span> <span class="f">materializeSkills</span>(root, [
+  { pluginName: <span class="s">"my-plugin"</span>, skill: { id: <span class="s">"my-plugin:boundary-analysis"</span>, path: <span class="s">"SKILL.md"</span> } },
+]);
+<span class="f">expect</span>(written).<span class="f">toHaveLength</span>(<span class="s">1</span>);
+<span class="f">expect</span>(existsSync(resolve(root, <span class="s">".pi"</span>, <span class="s">"skills"</span>, <span class="s">"my-plugin-boundary-analysis"</span>, <span class="s">"SKILL.md"</span>))).<span class="f">toBe</span>(<span class="k">true</span>);</pre>
+<h2 id="session-skills-in-the-palette">Session skills in the native palette <span class="ns">// what the Rig session reports</span></h2>
+<p>Bare <code>rig</code> and every detached OMP drone report only the skills their own runtime loaded. Foreground-only capabilities are not projected as drone capabilities, regardless of local or remote placement. Fleet work materializes through inline <code>/fleet</code>, <code>/tasks</code>, and <code>/drone</code> cards; skills remain prompt context. Full live UX in <a href="../docs/pi-extensions/index.html">OMP/Pi extensions &rarr;</a>.</p>
+<h2 id="skills-vs-extensions-vs-hooks">Skills vs. extensions vs. hooks <span class="ns">// pick the right tool</span></h2>
+<p>Three mechanisms extend what an OMP/Pi-backed workflow can do. They are not interchangeable:</p>
+<table class="t"><thead><tr><th>mechanism</th><th>what it adds</th><th>where it lives</th></tr></thead>
+<tbody>
+<tr><td>skill</td><td>Standing prompt context &mdash; procedures, checklists, house rules. Content only.</td><td><code>.pi/skills/&lt;sanitized-id&gt;/SKILL.md</code></td></tr>
+<tr><td>OMP/Pi extension</td><td>Installable package: tools, slash commands, behaviors. Code.</td><td><code>.pi/settings.json</code> <code>packages</code>, auto-installed at session start</td></tr>
+<tr><td>hook</td><td>A guard that fires on a lifecycle event (e.g. block edits outside scope).</td><td>Active harness settings file, with a plugin marker</td></tr>
+</tbody></table>
+<p><b>OMP/Pi extensions</b> are discovered and added with <code>rig pi search</code> / <code>rig pi add</code>, or declared team-wide via <code>runtime.pi.packages</code> in <a href="../config/index.html">rig.config.ts</a> &mdash; Rig materializes the list into <code>.pi/settings.json</code> and OMP/Pi auto-installs at session start on every host. Reach for a skill when you need to <em>tell</em> the session something; reach for an extension when you need to <em>give</em> it a new capability; reach for a hook when you need to <em>stop</em> it doing something.</p>
+<h2 id="see-also">See also</h2>
+<ul>
+<li><a href="../plugins/index.html">Plugin authoring</a> &mdash; the full <code>contributes</code> shape and how to ship a skill in a package.</li>
+<li><a href="../plugins/examples/index.html#pi-extension-package">Plugin examples: OMP/Pi package</a> &mdash; a small live-session tool pinned through <code>runtime.pi.packages</code> and materialized beside skills.</li>
+<li><a href="../docs/pi-extensions/index.html">OMP/Pi extensions</a> &mdash; installable tools and slash commands, and the session/collab UX.</li>
+<li><a href="../docs/validators/index.html">Validators &amp; hooks</a> &mdash; the other side of the materialization discipline.</li>
+<li><a href="../config/index.html">rig.config.ts</a> &mdash; where plugins and <code>runtime.pi.packages</code> are pinned.</li>
+</ul>
+<div class="nextnav"><a href="../docs/pi-extensions/index.html"><span class="dir">&larr; Back</span><span class="ttl">OMP/Pi extensions</span></a><a href="../docs/task-sources/index.html"><span class="dir">Next &rarr;</span><span class="ttl">Task sources</span></a></div>
+</main></div><footer><div class="wrap"><div class="foot"><div class="col"><h5>orchestrate</h5><a href="../docs/getting-started/index.html">getting started</a><a href="../docs/runs/index.html">the run lifecycle</a><a href="../docs/operator/index.html">operator guide</a><a href="../docs/gate/index.html">the merge gate</a></div><div class="col"><h5>extend</h5><a href="../plugins/index.html">plugin authoring</a><a href="../skills/index.html">skills guide</a><a href="../docs/pi-extensions/index.html">OMP/Pi extensions</a><a href="../docs/packages/index.html">packages</a></div><div class="col"><h5>live</h5><a href="../index.html">the home rig</a><a href="../cli/index.html">cli reference</a><a href="https://where.rig-does.work/install">install script</a></div><div class="sig">Rig is the OMP session extension.<br><span class="blk">You are the operator.</span><br>release: rig --version</div></div></div></footer><script>document.querySelectorAll('[data-tab]').forEach(function(t){t.onclick=function(){document.querySelectorAll('[data-tab]').forEach(function(x){x.classList.remove('on')});document.querySelectorAll('[data-cmd]').forEach(function(x){x.style.display='none'});t.classList.add('on');var c=document.querySelector('[data-cmd="'+t.dataset.tab+'"]');if(c)c.style.display='flex';};});document.querySelectorAll('.cp').forEach(function(b){b.onclick=function(){var code=b.parentElement.querySelector('code');if(navigator.clipboard)navigator.clipboard.writeText(code.innerText);var o=b.innerText;b.innerText='copied';setTimeout(function(){b.innerText=o;},1200);};});</script><script src="../assets/rig.js"></script><script src="../assets/site.js?v=v9"></script></body></html>

package/site/variants/deck/index.html ADDED Viewed

	@@ -0,0 +1 @@
1	+ <!doctype html><meta http-equiv="refresh" content="0; url=../../index.html"><link rel="canonical" href="../../index.html"><title>Redirecting…</title><a href="../../index.html">the live deck now lives on the home page →</a>