@openrig/cli 0.5.6 → 0.5.7

package/daemon/context-packs/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/context-packs/skills/process/executing-plans/manifest.yaml

@@ -1,12 +0,0 @@
-# GENERATED by scripts/generate-context-packs.mjs — DO NOT EDIT.
-# Package-time projection of a canonical skill; regenerated every build.
-name: "executing-plans"
-version: "0.5.6"
-taxonomy: "skills"
-purpose: "Use when you have a written implementation plan to execute in a separate session with review checkpoints"
-files:
-  - path: "SKILL.md"
-    role: "instruction"
-    summary: "Use when you have a written implementation plan to execute in a separate session with review checkpoints"
-  - path: "OPENRIG.md"
-    role: "reference"

package/daemon/context-packs/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/context-packs/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/context-packs/skills/process/using-superpowers/manifest.yaml

@@ -1,12 +0,0 @@
-# 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.6"
-taxonomy: "skills"
-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/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/context-packs/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

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

@@ -1,12 +0,0 @@
-# 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.6"
-taxonomy: "skills"
-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/specs/agents/shared/skills/process/brainstorming/OPENRIG.md

@@ -1,48 +0,0 @@
----
-skill: brainstorming
-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
-
-`brainstorming` is the "intent → design" front of the OpenRig planning chain. Agents use it before any creative or implementation work — to refine user intent into a shareable design doc that downstream skills (`writing-plans`, then `executing-plans`) consume.
-
-## OpenRig-specific modifications
-
-| Surface | Upstream | OpenRig |
-|---|---|---|
-| Visual Companion offer step | Standalone step #2 in the flow — "offer Visual Companion in its own message before clarifying questions" | **Removed.** OpenRig agents typically operate without a separate visual-companion mode; visual design work routes through dedicated design-pod seats. |
-| Spec self-review step | Step #7 — inline self-review for placeholders/contradictions/scope | **Removed.** Self-review is handled at the rig/orchestration layer (driver/guard pattern + review-lead). |
-| User reviews written spec | Step #8 — pause for user to review the spec file | **Removed.** OpenRig's the operator-walk and orchestration gates already cover this checkpoint at a higher level. |
-| Spec save path | `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` | `docs/plans/YYYY-MM-DD-<topic>-design.md` (matches OpenRig's `docs/plans/` convention) |
-| Process flow diagram | Includes Visual Companion + Spec self-review nodes | Simplified to remove those nodes; edges rewired |
-
-## Why these modifications (inferred)
-
-- **Multi-platform / multi-step gates removed**: OpenRig's rig-level orchestration (driver → guard → qa, the operator-walks) already provides the checkpoint structure that the upstream skill builds inline. Keeping those steps inside the skill double-gates the work.
-- **`docs/plans/` path**: OpenRig's project structure uses `docs/plans/` as the canonical home for design + implementation plan documents (matches `writing-plans` modification — both are co-ordinated).
-
-## Companion files
-
-None.
-
-## When to re-sync upstream
-
-Watch upstream for:
-
-- New phases or checkpoints in the brainstorming flow that OpenRig might want to adopt (rare; the skill is structurally stable in upstream).
-- Changes to the brainstorming-to-writing-plans handoff (must stay coordinated with the `writing-plans` modifications).
-
-When upstream changes:
-
-1. Pull non-conflicting changes into the OpenRig copy.
-2. Preserve the simplified 6-step flow and the `docs/plans/` save path unless operator direction reverses.
-3. Bump `last_upstream_check` in `SKILL.md` frontmatter.

package/daemon/specs/agents/shared/skills/process/brainstorming/SKILL.md

@@ -1,107 +0,0 @@
----
-name: brainstorming
-description: "You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation."
-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: |
-      Simplified the process flow. Removed the Visual Companion offer step,
-      the Spec self-review step, and the User-reviews-spec step (those gates
-      are handled at the rig/orchestration layer in OpenRig). Changed plan-
-      doc save path from docs/superpowers/specs/ to docs/plans/.
-      See OPENRIG.md for full divergence details.
----
-
-# Brainstorming Ideas Into Designs
-
-## Overview
-
-Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
-
-Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
-
-<HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
-</HARD-GATE>
-
-## Anti-Pattern: "This Is Too Simple To Need A Design"
-
-Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
-
-## Checklist
-
-You MUST create a task for each of these items and complete them in order:
-
-1. **Explore project context** — check files, docs, recent commits
-2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
-3. **Propose 2-3 approaches** — with trade-offs and your recommendation
-4. **Present design** — in sections scaled to their complexity, get user approval after each section
-5. **Write design doc** — save to `docs/plans/YYYY-MM-DD-<topic>-design.md` and commit
-6. **Transition to implementation** — invoke writing-plans skill to create implementation plan
-
-## Process Flow
-
-```dot
-digraph brainstorming {
-    "Explore project context" [shape=box];
-    "Ask clarifying questions" [shape=box];
-    "Propose 2-3 approaches" [shape=box];
-    "Present design sections" [shape=box];
-    "User approves design?" [shape=diamond];
-    "Write design doc" [shape=box];
-    "Invoke writing-plans skill" [shape=doublecircle];
-
-    "Explore project context" -> "Ask clarifying questions";
-    "Ask clarifying questions" -> "Propose 2-3 approaches";
-    "Propose 2-3 approaches" -> "Present design sections";
-    "Present design sections" -> "User approves design?";
-    "User approves design?" -> "Present design sections" [label="no, revise"];
-    "User approves design?" -> "Write design doc" [label="yes"];
-    "Write design doc" -> "Invoke writing-plans skill";
-}
-```
-
-**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.
-
-## The Process
-
-**Understanding the idea:**
-- Check out the current project state first (files, docs, recent commits)
-- Ask questions one at a time to refine the idea
-- Prefer multiple choice questions when possible, but open-ended is fine too
-- Only one question per message - if a topic needs more exploration, break it into multiple questions
-- Focus on understanding: purpose, constraints, success criteria
-
-**Exploring approaches:**
-- Propose 2-3 different approaches with trade-offs
-- Present options conversationally with your recommendation and reasoning
-- Lead with your recommended option and explain why
-
-**Presenting the design:**
-- Once you believe you understand what you're building, present the design
-- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
-- Ask after each section whether it looks right so far
-- Cover: architecture, components, data flow, error handling, testing
-- Be ready to go back and clarify if something doesn't make sense
-
-## After the Design
-
-**Documentation:**
-- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
-- Use elements-of-style:writing-clearly-and-concisely skill if available
-- Commit the design document to git
-
-**Implementation:**
-- Invoke the writing-plans skill to create a detailed implementation plan
-- Do NOT invoke any other skill. writing-plans is the next step.
-
-## Key Principles
-
-- **One question at a time** - Don't overwhelm with multiple questions
-- **Multiple choice preferred** - Easier to answer than open-ended when possible
-- **YAGNI ruthlessly** - Remove unnecessary features from all designs
-- **Explore alternatives** - Always propose 2-3 approaches before settling
-- **Incremental validation** - Present design, get approval before moving on
-- **Be flexible** - Go back and clarify when something doesn't make sense