@openrig/cli 0.5.2 → 0.5.3

package/daemon/context-packs/skills/process/using-superpowers/OPENRIG.md

@@ -0,0 +1,48 @@
+---
+skill: using-superpowers
+openrig-relationship: vendored-modified
+---
+
+# OpenRig and this skill
+
+## Origin
+
+- **Upstream**: Obra Superpowers (https://github.com/obra/superpowers)
+- **Vendoring pattern**: `modify-the-file`
+- **Last upstream check**: 2026-05-13 (diff against plugin source pulled 2026-05-11)
+
+## How OpenRig uses this skill
+
+`using-superpowers` is the catalog-aware "always reach for a skill before answering" bootstrap. It's loaded into every OpenRig agent's startup context to enforce the discipline that skills must be invoked through the `Skill` tool (not Read'd directly), and that the agent should pattern-match descriptions against the work at hand before producing free-form output.
+
+## OpenRig-specific modifications
+
+| Surface | Upstream | OpenRig |
+|---|---|---|
+| `<SUBAGENT-STOP>` block | Skip the skill if dispatched as a subagent | **Removed.** OpenRig doesn't use the upstream subagent-dispatch pattern; this directive doesn't fit the rig/pod/seat topology. |
+| Instruction Priority section | 3-tier priority: user > skills > system | **Removed.** OpenRig handles priority at the AgentSpec + agent-startup-content layer, not inside this skill. |
+| Platform-specific sections (Copilot CLI, Gemini CLI) | Each platform gets its own paragraph for how to access skills | **Removed.** OpenRig targets Claude Code + Codex specifically. The Claude Code paragraph is preserved. |
+| Platform Adaptation section | Points to `references/copilot-tools.md` and `references/codex-tools.md` for tool mapping | **Removed.** OpenRig agents don't need the upstream tool-mapping references; the rig spec lists tools directly. |
+
+## Why these modifications (inferred)
+
+- **Topology mismatch**: OpenRig's subagent model is the rig/pod/seat structure, not the upstream's "dispatch a subagent" pattern. The `<SUBAGENT-STOP>` block would silently skip the skill in seats that should be loading it.
+- **OpenRig is opinionated about target runtimes**: Claude Code + Codex are the supported pair. Multi-platform copy adds cognitive overhead without product value for OpenRig users.
+- **Priority lives at the spec layer**: OpenRig's AgentSpec + startup content (role.md, guidance/, CULTURE.md) is where instruction precedence is encoded; baking it into this skill duplicates the layering.
+
+## Companion files
+
+None. (Upstream ships `references/copilot-tools.md` and `references/codex-tools.md` but these reference the upstream Copilot tool surface, not OpenRig's. They are not vendored.)
+
+## When to re-sync upstream
+
+Watch upstream for:
+
+- Changes to the core "always invoke a skill" discipline (the heart of the skill).
+- New platforms upstream supports that OpenRig might also want to support — would need to add a corresponding paragraph here.
+
+When upstream changes:
+
+1. Pull non-conflicting changes into the OpenRig copy.
+2. Do NOT re-introduce the multi-platform sections, SUBAGENT-STOP block, or Instruction Priority section unless operator direction reverses.
+3. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/context-packs/skills/process/using-superpowers/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: using-superpowers
+description: Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: modify-the-file
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11)"
+    divergence_notes: |
+      Removed multi-platform-specific sections (Copilot CLI, Gemini CLI,
+      Platform Adaptation) — OpenRig targets Claude Code + Codex. Removed
+      the SUBAGENT-STOP block and Instruction Priority section — OpenRig
+      handles those concerns at the rig/agent-spec layer.
+      See OPENRIG.md for full divergence details.
+---
+
+<EXTREMELY-IMPORTANT>
+If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
+
+IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
+
+This is not negotiable. This is not optional. You cannot rationalize your way out of this.
+</EXTREMELY-IMPORTANT>
+
+## How to Access Skills
+
+**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
+
+**In other environments:** Check your platform's documentation for how skills are loaded.
+
+# Using Skills
+
+## The Rule
+
+**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
+
+```dot
+digraph skill_flow {
+    "User message received" [shape=doublecircle];
+    "About to EnterPlanMode?" [shape=doublecircle];
+    "Already brainstormed?" [shape=diamond];
+    "Invoke brainstorming skill" [shape=box];
+    "Might any skill apply?" [shape=diamond];
+    "Invoke Skill tool" [shape=box];
+    "Announce: 'Using [skill] to [purpose]'" [shape=box];
+    "Has checklist?" [shape=diamond];
+    "Create TodoWrite todo per item" [shape=box];
+    "Follow skill exactly" [shape=box];
+    "Respond (including clarifications)" [shape=doublecircle];
+
+    "About to EnterPlanMode?" -> "Already brainstormed?";
+    "Already brainstormed?" -> "Invoke brainstorming skill" [label="no"];
+    "Already brainstormed?" -> "Might any skill apply?" [label="yes"];
+    "Invoke brainstorming skill" -> "Might any skill apply?";
+
+    "User message received" -> "Might any skill apply?";
+    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
+    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
+    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
+    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
+    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
+    "Has checklist?" -> "Follow skill exactly" [label="no"];
+    "Create TodoWrite todo per item" -> "Follow skill exactly";
+}
+```
+
+## Red Flags
+
+These thoughts mean STOP—you're rationalizing:
+
+| Thought | Reality |
+|---------|---------|
+| "This is just a simple question" | Questions are tasks. Check for skills. |
+| "I need more context first" | Skill check comes BEFORE clarifying questions. |
+| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
+| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
+| "Let me gather information first" | Skills tell you HOW to gather information. |
+| "This doesn't need a formal skill" | If a skill exists, use it. |
+| "I remember this skill" | Skills evolve. Read current version. |
+| "This doesn't count as a task" | Action = task. Check for skills. |
+| "The skill is overkill" | Simple things become complex. Use it. |
+| "I'll just do this one thing first" | Check BEFORE doing anything. |
+| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
+| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
+
+## Skill Priority
+
+When multiple skills could apply, use this order:
+
+1. **Process skills first** (brainstorming, debugging) - these determine HOW to approach the task
+2. **Implementation skills second** (frontend-design, mcp-builder) - these guide execution
+
+"Let's build X" → brainstorming first, then implementation skills.
+"Fix this bug" → debugging first, then domain-specific skills.
+
+## Skill Types
+
+**Rigid** (TDD, debugging): Follow exactly. Don't adapt away discipline.
+
+**Flexible** (patterns): Adapt principles to context.
+
+The skill itself tells you which.
+
+## User Instructions
+
+Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

package/daemon/context-packs/skills/process/using-superpowers/manifest.yaml

@@ -0,0 +1,11 @@
+# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
+# Package-time projection of a canonical skill; regenerated every build.
+name: "using-superpowers"
+version: "0.5.3"
+purpose: "Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions"
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions"
+  - path: "OPENRIG.md"
+    role: "reference"

package/daemon/context-packs/skills/process/verification-before-completion/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: vendored-as-is
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11 = identical)"
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**This rule serves shipping — it is not a ritual that outranks it.** It governs one thing: *claims that a verifiable result holds* ("tests pass", "build succeeds", "bug fixed") — run the check before you assert it, and scale the check to the stakes (a one-line copy tweak is not a test-suite ceremony). Don't dodge it with synonyms; equally, don't inflate it into a tax on the word "done" or a reason to keep re-proving instead of shipping the working thing.
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Claiming a specific result is *proven* ("tests pass", "it's fixed", "build's green") before running the check in this message — enthusiasm itself is fine; an unverified **result claim** is the flag
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## When the check itself lies — content over shape
+
+Running a verification is necessary but not sufficient: a check can exit clean and still prove nothing. These are the named ways a green check lies — the failure siblings behind "evidence before claims." (Deeper treatment of *what* you verify against: `reference-first-verification`.)
+
+- **Assert on CONTENT, never shape or count.** Output that *looks* like success — a non-zero count, a clean exit, no error text — can carry failure as its content. Before trusting a check, ask what its output looks like *when it fails*: if failure and success are indistinguishable at a glance, the check proves nothing. (`[1 lines]` and `No matches found` both read as "a match" to a line-count.)
+- **Compare the returned value to the value you PASSED — never to a description of it.** A confident label (`evidenceRef NOW SET:` printed above the untouched original) is indistinguishable from a verification in a transcript. Diff the actual result against your actual input, not against a claim about it.
+- **Find the untested axis.** Thorough coverage of ONE axis reads as thorough coverage overall. Ask what every one of your tests shares — a healthy manifest, a default option value, the happy path — and treat that shared assumption as the dimension you never tested. (A 15-case "exhaustive" harness whose only defect lived on the one axis every case held constant.)
+- **A syntax check proves parseability and nothing else.** A clean `node --check` / lint / parse pass is the *covered* axis; boot and runtime are the untested one. Parseable ≠ sound.
+- **A failure whose shape is a HANG reports nothing.** A bare `await` against a stated deadline that never re-checks cannot fail loudly. Race it against a timer so failure has a shape you can see.
+- **A completeness inventory read through a truncating display is worthless.** When deciding *which occurrences to change*, count with `grep -c` / `grep -o` / full-line output — never `cut`, `head`, or a pager, which can hide a match *past* the cut (a doc pointer on a ~540-char line sat just past `cut -c1-180` and nearly shipped the defect inside its own fix). Distinguish *"I found N"* (a count) from *"I saw N"* (a display). Audit multiline prose **by paragraph, not by line** — a line filter both misses long-line matches and false-flags paragraphs whose companion text is on the next line. Then re-audit with a **different method** than the one that built the inventory — same-method re-checking reproduces the blind spot. (Empty/short output is a claim about your COMMAND until re-proven a second way.)
+
+## Why This Matters
+
+From 24 failure memories:
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/daemon/context-packs/skills/process/verification-before-completion/manifest.yaml

@@ -0,0 +1,9 @@
+# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
+# Package-time projection of a canonical skill; regenerated every build.
+name: "verification-before-completion"
+version: "0.5.3"
+purpose: "Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always"
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always"

package/daemon/context-packs/skills/process/writing-plans/OPENRIG.md

@@ -0,0 +1,52 @@
+---
+skill: writing-plans
+openrig-relationship: vendored-modified
+---
+
+# OpenRig and this skill
+
+## Origin
+
+- **Upstream**: Obra Superpowers (https://github.com/obra/superpowers)
+- **Vendoring pattern**: `modify-the-file`
+- **Last upstream check**: 2026-05-13 (diff against plugin source pulled 2026-05-11)
+
+## How OpenRig uses this skill
+
+`writing-plans` is the middle step of OpenRig's three-stage implementation flow: `brainstorming` produces the design, `writing-plans` turns the design into a bite-sized task plan, and `executing-plans` (also OpenRig-modified) drives the plan to completion in batches. Driver seats use this skill when authoring plans for guard + qa to review and for downstream drivers to execute.
+
+## OpenRig-specific modifications
+
+| Surface | Upstream | OpenRig |
+|---|---|---|
+| Plan save path | `docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md` | `docs/plans/YYYY-MM-DD-<feature-name>.md` (matches OpenRig's `docs/plans/` convention; coordinated with the matching change in `brainstorming`) |
+| Scope Check section | Explicit step to break multi-subsystem specs into sub-project specs | **Removed.** OpenRig's slice + mission decomposition (handled at the orchestration layer) already enforces single-coherence scope per plan. |
+| File Structure section | Explicit step to map files-to-be-created/modified with responsibilities before defining tasks | **Removed.** OpenRig drivers work inside an already-scoped slice; file-decomposition decisions live in the slice spec, not the plan. |
+| Worktree context hint | "If working in an isolated worktree, it should have been created via the `superpowers:using-git-worktrees` skill at execution time." | "This should be run in a dedicated worktree (created by brainstorming skill)." — less explicit cross-skill dependency. |
+| "For agentic workers" plan-header pointer | Suggests `superpowers:subagent-driven-development` (recommended) or `superpowers:executing-plans` | "For Claude: REQUIRED SUB-SKILL: Use `superpowers:executing-plans` to implement this plan task-by-task." Removed the subagent-driven-development pointer (consistent with the `executing-plans` modification). |
+| Step tracking syntax | `- [ ] **Step 1: ...**` (checkbox for TodoWrite tracking) | `**Step 1: ...**` (bare bold; OpenRig drivers use their own task-tracking) |
+
+## Why these modifications (inferred)
+
+- **Path coordination**: `docs/plans/` is OpenRig's canonical home for plan documents. The `brainstorming` skill produces designs at `docs/plans/...-design.md`; `writing-plans` produces plans at `docs/plans/...-feature-name.md`. Same root.
+- **Scope + structure handled higher**: OpenRig's slice spec already constrains scope (one coherent slice) and identifies the touched-file surface. Repeating those checks inside the plan-authoring skill double-gates the work.
+- **No subagent-driven-development pointer**: same reason as the `executing-plans` modification — OpenRig topologies provide parallel-pod review via separate seats; routing through subagents is structurally redundant.
+- **Bare bold step syntax**: OpenRig drivers track progress via the orchestration queue + their own task tooling, not via in-file TodoWrite checkboxes.
+
+## Companion files
+
+None.
+
+## When to re-sync upstream
+
+Watch upstream for:
+
+- Changes to plan structure or task-granularity guidance.
+- Coordination changes with `brainstorming` and `executing-plans` (this skill is the middle of a 3-skill chain; changes to either end may require this skill to follow).
+
+When upstream changes:
+
+1. Pull non-conflicting changes into the OpenRig copy.
+2. Preserve the `docs/plans/` save path and the absence of the Scope Check + File Structure sections unless operator direction reverses.
+3. Re-check that the subagent-driven-development pointer hasn't crept back in.
+4. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/context-packs/skills/process/writing-plans/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: writing-plans
+description: Use when you have a spec or requirements for a multi-step task, before touching code
+metadata:
+  openrig:
+    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
+    vendoring_pattern: modify-the-file
+    last_upstream_check: "2026-05-13 (diff against plugin source pulled 2026-05-11)"
+    divergence_notes: |
+      Removed the Scope Check + File Structure sections, the subagent-driven-
+      development sub-skill pointer, and the checkbox-tracking syntax for
+      steps. Changed plan-doc save path from docs/superpowers/plans/ to
+      docs/plans/. See OPENRIG.md for full divergence details.
+---
+
+# Writing Plans
+
+## Overview
+
+Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
+
+Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
+
+**Announce at start:** "I'm using the writing-plans skill to create the implementation plan."
+
+**Context:** This should be run in a dedicated worktree (created by brainstorming skill).
+
+**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`
+
+## Bite-Sized Task Granularity
+
+**Each step is one action (2-5 minutes):**
+- "Write the failing test" - step
+- "Run it to make sure it fails" - step
+- "Implement the minimal code to make the test pass" - step
+- "Run the tests and make sure they pass" - step
+- "Commit" - step
+
+## Plan Document Header
+
+**Every plan MUST start with this header:**
+
+```markdown
+# [Feature Name] Implementation Plan
+
+> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.
+
+**Goal:** [One sentence describing what this builds]
+
+**Architecture:** [2-3 sentences about approach]
+
+**Tech Stack:** [Key technologies/libraries]
+
+---
+```
+
+## Task Structure
+
+````markdown
+### Task N: [Component Name]
+
+**Files:**
+- Create: `exact/path/to/file.py`
+- Modify: `exact/path/to/existing.py:123-145`
+- Test: `tests/exact/path/to/test.py`
+
+**Step 1: Write the failing test**
+
+```python
+def test_specific_behavior():
+    result = function(input)
+    assert result == expected
+```
+
+**Step 2: Run test to verify it fails**
+
+Run: `pytest tests/path/test.py::test_name -v`
+Expected: FAIL with "function not defined"
+
+**Step 3: Write minimal implementation**
+
+```python
+def function(input):
+    return expected
+```
+
+**Step 4: Run test to verify it passes**
+
+Run: `pytest tests/path/test.py::test_name -v`
+Expected: PASS
+
+**Step 5: Commit**
+
+```bash
+git add tests/path/test.py src/path/file.py
+git commit -m "feat: add specific feature"
+```
+````
+
+## Remember
+- Exact file paths always
+- Complete code in plan (not "add validation")
+- Exact commands with expected output
+- Reference relevant skills with @ syntax
+- DRY, YAGNI, TDD, frequent commits
+
+## Execution Handoff
+
+After saving the plan, offer execution choice:
+
+**"Plan complete and saved to `docs/plans/<filename>.md`. Two execution options:**
+
+**1. Subagent-Driven (this session)** - I dispatch fresh subagent per task, review between tasks, fast iteration
+
+**2. Parallel Session (separate)** - Open new session with executing-plans, batch execution with checkpoints
+
+**Which approach?"**
+
+**If Subagent-Driven chosen:**
+- Spawn a fresh subagent for each task; code-review the result before merging
+- Stay in this session
+- Pair with whatever subagent-orchestration skill your runtime provides (e.g., the Obra Superpowers plugin ships one if you have that plugin installed)
+
+**If Parallel Session chosen:**
+- Guide them to open new session in worktree
+- **REQUIRED SUB-SKILL:** New session uses superpowers:executing-plans

package/daemon/context-packs/skills/process/writing-plans/manifest.yaml

@@ -0,0 +1,11 @@
+# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
+# Package-time projection of a canonical skill; regenerated every build.
+name: "writing-plans"
+version: "0.5.3"
+purpose: "Use when you have a spec or requirements for a multi-step task, before touching code"
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when you have a spec or requirements for a multi-step task, before touching code"
+  - path: "OPENRIG.md"
+    role: "reference"

package/daemon/context-packs/world/install/01-world-from-primitives.md

@@ -0,0 +1,97 @@
+# You have talked to another agent. You have never talked to one in another terminal.
+
+Start from what you have actually done. You spawn a sub-agent, it goes away and works, it reports
+back. You may have run several at once. That is agent-to-agent communication and you are fluent
+in it.
+
+**Every bit of it happened inside your own session, through a bus your harness handed you.** The
+other agent was something you contained. When your session ends, it ends. You have never sent
+anything to an agent you did not spawn, and you have no mechanism in mind for doing so.
+
+That is not an oversight on your part. **Nothing you were trained on works any other way** — every
+tool in this category does agent comms within a session, over a built-in bus. So what follows is
+outside the frame you were given, and it takes a minute to land.
+
+## Picture this
+
+Another coding agent — a Claude, or a Codex — is running **in a different terminal on this
+machine.** Not inside your session. A separate process, with its own context, its own work, its
+own prompt box sitting there waiting for someone to type in it.
+
+**Now picture yourself doing the typing.**
+
+That is the whole idea. And the mechanism is something you already know:
+
+```bash
+tmux send-keys -t some-agents-pane "the file you want is src/auth.ts, not src/user.ts" Enter
+tmux capture-pane -p -t some-agents-pane        # read what is on their screen right now
+```
+
+`tmux send-keys` types into another pane. If that pane holds an agent, **you just talked to it** —
+and to that agent nothing unusual happened, because its input box does not know who filled it.
+
+No API. No message bus. No protocol between you. **The terminal is the wire.**
+
+Two things follow that are just as far outside the frame, and worth saying out loud because you
+will not infer them:
+
+- **It works across tools.** You can drive a Codex the same way. Different model, different
+  vendor, same terminal. Almost nobody has done this.
+- **Those agents outlive your session.** They are separate processes. Yours ending does not end
+  theirs — and theirs ending does not lose their work, because what they wrote to disk stays.
+
+`send-keys` alone is not reliable enough to build on, which is the only reason the rest of this
+exists.
+
+## What the daemon adds, and why it had to exist
+
+Raw `send-keys` gets you far and then stops. You need to know **which pane is who** — and pane ids
+are opaque and change. You need messages to carry a **sender**, so a reply can go back. You need
+**durable state**, because a pane's scrollback is not a record and dies with the process. You need
+to know **who is running at all**.
+
+So: a small daemon, a SQLite database, and a naming convention.
+
+- `<pod>-<member>@<rig>` is an **address**. It resolves to a pane. That is all a session name is.
+- `rig send <addr> "msg"` is `send-keys` **plus a from-line** so the receiver can answer you.
+- `rig capture <addr>` is `capture-pane`.
+- `rig ps` asks the database who exists, because the database is the only thing that knows.
+- `rig queue` is durable messages — a message that survives the pane, because scrollback does not.
+
+**Nothing above is exotic.** It is tmux, a daemon, a database, and files on disk. If a `rig`
+command ever seems like magic, the useful question is *which of those four is it actually doing* —
+and you can read the source, it is on this machine.
+
+## Why it is arranged as topology
+
+Once agents can drive each other, the question is not *can they talk* but **who should**. An agent
+with no structure around it either does everything itself or asks everyone about everything.
+
+So the arrangement borrows from network topology, which you also already know:
+
+- a **rig** is a team with a purpose — named for what it is *for*
+- a **pod** is a group inside it that shares a context domain, so knowledge earned by one member
+  is likely useful to its neighbours and not to the whole rig
+- a **seat** is an address that **outlives its occupant**. You are the current occupant of one.
+  The seat accumulates knowledge across everyone who has sat in it.
+
+**The seat is the load-bearing idea**, and it is the one with no analogue in your training data.
+You are not a session that happens to have a name. You are a tenant.
+
+## What you can now build, which is the point
+
+You have addressable colleagues, durable messages, a state database, and a filesystem. Stack those
+the way you would stack any other primitives and you get something specific: **a topology of
+agents that can be given a roadmap and build software against it** — one deciding scope, others
+implementing, others checking, handing work between themselves without a human in the loop for
+every step.
+
+That is what OpenRig is. **Not a framework you are running inside — a set of primitives you are
+holding.** The same posture you would take toward tmux and jq applies here: compose them, script
+them, and build the thing that does not exist yet.
+
+> **PREDICT — commit before you check.**
+> `rig send` puts a message in another agent's terminal. Say what you think happens if that agent
+> is **busy** when it arrives — does it interrupt them, get dropped, or wait? Commit to an answer.
+>
+> Then say which of the four ingredients above you would look at first to find out.