@openrig/cli 0.5.6 → 0.5.7

package/daemon/specs/agents/shared/skills/process/executing-plans/OPENRIG.md

@@ -1,56 +0,0 @@
----
-skill: executing-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 (initial relationship declaration)
-
-## How OpenRig uses this skill
-
-This is the canonical "execute a plan that another seat wrote" skill for OpenRig implementation agents. The driver/guard/qa pattern depends on this skill to keep plan-execution checkpointable and reviewable. Without the batch-with-checkpoint structure, the orchestration loop loses its in-flight review surface.
-
-## OpenRig-specific modifications
-
-The skill was restructured from upstream's all-tasks-at-once execution shape into a batch-with-checkpoint shape:
-
-| Aspect | Upstream | OpenRig |
-|---|---|---|
-| Execution unit | All tasks in plan, sequentially | Batch (default 3 tasks per batch) |
-| Reporting cadence | Once at end (after all tasks complete) | Between every batch |
-| Architect-review surface | None inside the skill | Step 3 "Report" + Step 4 "Continue" cycle |
-| Subagent alternative | Suggests `superpowers:subagent-driven-development` as a better choice when subagents are available | **Removed**. OpenRig topologies already supply separate pods for review; the subagent pointer added cognitive overhead with no win. |
-| Stop conditions | "Hit a blocker" | "Hit a blocker **mid-batch**" |
-| Step 5 "Complete Development" | Step 3 in upstream | Renumbered to Step 5 to make room for the batch-and-report cycle |
-
-The `## Integration` section preserves the upstream sub-skill pointers (`using-git-worktrees`, `writing-plans`, `finishing-a-development-branch`) — those are also vendored from obra-superpowers and present in OpenRig under the same names.
-
-## Why these modifications
-
-- **Batch-and-report cadence fits the OpenRig driver/guard/qa rhythm.** Architect feedback is in-the-loop rather than after-the-fact. A driver who reports between batches gives guard + qa room to surface direction corrections before more work compounds the wrong direction.
-- **The subagent-driven-development pointer doesn't fit the OpenRig posture.** OpenRig already provides parallel-pod review via separate seats; routing through subagents is structurally redundant.
-- **"Mid-batch" precision in stop conditions** matches the batch unit. A driver hitting a blocker between tasks should still report — the unit of "stop and ask" is the batch, not the whole plan.
-
-## Companion files
-
-None at the moment.
-
-## When to re-sync upstream
-
-Watch for upstream changes to:
-
-- **Plan-execution discipline** — stop conditions, verification rules, blocker-handling cadence.
-- **The relationship to writing-plans + finishing-a-development-branch** — if upstream changes how these compose, OpenRig should consider whether the new shape is worth adopting.
-
-When upstream changes:
-
-1. Pull non-conflicting changes into the OpenRig copy.
-2. Preserve the batch-with-checkpoint structure unless operator direction reverses.
-3. Re-check that the subagent-alternative pointer hasn't crept back in.
-4. Bump `last_upstream_check` in `SKILL.md` frontmatter.
-5. Note any structural shape changes in `divergence_notes`.

package/daemon/specs/agents/shared/skills/process/executing-plans/SKILL.md

@@ -1,94 +0,0 @@
----
-name: executing-plans
-description: Use when you have a written implementation plan to execute in a separate session with review checkpoints
-metadata:
-  openrig:
-    vendored_from: "Obra Superpowers (https://github.com/obra/superpowers)"
-    vendoring_pattern: modify-the-file
-    last_upstream_check: "2026-05-13 (initial vendoring declaration)"
-    divergence_notes: |
-      Restructured from upstream's all-tasks-at-once execution into batch-with-
-      checkpoint execution (default 3 tasks per batch + report + continue cycle).
-      Removed the upstream suggestion to use superpowers:subagent-driven-development
-      as an alternative. See OPENRIG.md for full divergence details.
----
-
-# Executing Plans
-
-## Overview
-
-Load plan, review critically, execute tasks in batches, report for review between batches.
-
-**Core principle:** Batch execution with checkpoints for architect review.
-
-**Announce at start:** "I'm using the executing-plans skill to implement this plan."
-
-## The Process
-
-### Step 1: Load and Review Plan
-1. Read plan file
-2. Review critically - identify any questions or concerns about the plan
-3. If concerns: Raise them with your human partner before starting
-4. If no concerns: Create TodoWrite and proceed
-
-### Step 2: Execute Batch
-**Default: First 3 tasks**
-
-For each task:
-1. Mark as in_progress
-2. Follow each step exactly (plan has bite-sized steps)
-3. Run verifications as specified
-4. Mark as completed
-
-### Step 3: Report
-When batch complete:
-- Show what was implemented
-- Show verification output
-- Say: "Ready for feedback."
-
-### Step 4: Continue
-Based on feedback:
-- Apply changes if needed
-- Execute next batch
-- Repeat until complete
-
-### Step 5: Complete Development
-
-After all tasks complete and verified:
-- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
-- **REQUIRED SUB-SKILL:** Use superpowers:finishing-a-development-branch
-- Follow that skill to verify tests, present options, execute choice
-
-## When to Stop and Ask for Help
-
-**STOP executing immediately when:**
-- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
-- Plan has critical gaps preventing starting
-- You don't understand an instruction
-- Verification fails repeatedly
-
-**Ask for clarification rather than guessing.**
-
-## When to Revisit Earlier Steps
-
-**Return to Review (Step 1) when:**
-- Partner updates the plan based on your feedback
-- Fundamental approach needs rethinking
-
-**Don't force through blockers** - stop and ask.
-
-## Remember
-- Review plan critically first
-- Follow plan steps exactly
-- Don't skip verifications
-- Reference skills when plan says to
-- Between batches: just report and wait
-- Stop when blocked, don't guess
-- Never start implementation on main/master branch without explicit user consent
-
-## Integration
-
-**Required workflow skills:**
-- **superpowers:using-git-worktrees** - REQUIRED: Set up isolated workspace before starting
-- **superpowers:writing-plans** - Creates the plan this skill executes
-- **superpowers:finishing-a-development-branch** - Complete development after all tasks

package/daemon/specs/agents/shared/skills/process/using-superpowers/OPENRIG.md

@@ -1,48 +0,0 @@
----
-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/specs/agents/shared/skills/process/using-superpowers/SKILL.md

@@ -1,106 +0,0 @@
----
-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/specs/agents/shared/skills/process/writing-plans/OPENRIG.md

@@ -1,52 +0,0 @@
----
-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/specs/agents/shared/skills/process/writing-plans/SKILL.md

@@ -1,126 +0,0 @@
----
-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