@openrig/cli 0.4.6 → 0.4.8

package/daemon/specs/agents/shared/skills/core/openrig-user-settings/SKILL.md

@@ -1,153 +0,0 @@
----
-name: openrig-user-settings
-description: Use when the user asks an OpenRig agent to read or change OpenRig configuration settings — workspace paths, file allowlists, progress scan roots, daemon port/host, transcripts, or anything stored in ~/.openrig/config.json
----
-
-# OpenRig User Settings
-
-OpenRig settings live in `~/.openrig/config.json` and are managed via the
-`rig config` CLI family. The agent-editable surface is **CLI shell-out**;
-do NOT write the JSON file directly unless the operator specifically asks
-for raw-text editing (which is handled by the UI Files browser, not by you).
-
-## Read
-
-```bash
-rig config                                # all keys, value + source
-rig config --json                         # JSON: full RiggedConfig
-rig config --json --with-source           # JSON: {key: {value, source, default}}
-rig config get <key>                      # single value
-rig config get <key> --show-source        # value + source on one line
-rig config get <key> --json               # {value, source, default}
-```
-
-Resolution order: **env var > config file > default**. Always use
-`--show-source` (or `--json`) when reporting back to the operator so they
-see *where* the value came from.
-
-## Write
-
-```bash
-rig config set <key> <value>              # set a key
-rig config reset <key>                    # clear one override (revert to default)
-rig config reset                          # delete the whole file
-```
-
-## Initialize a default workspace
-
-```bash
-rig config init-workspace                 # scaffold ~/.openrig/workspace/ with missions + slices
-rig config init-workspace --dry-run       # show what would be created
-rig config init-workspace --root /path    # use a custom root
-rig config init-workspace --force         # overwrite scaffolded files (NOT operator content)
-```
-
-This creates a file-backed Project workspace under the workspace root:
-
-```text
-README.md
-STEERING.md
-missions/<mission-id>/README.md
-missions/<mission-id>/PROGRESS.md
-missions/<mission-id>/slices/<slice-id>/README.md
-progress/
-field-notes/
-specs/
-```
-
-It seeds two starter missions with multiple slices so the Project UI has a
-real mission/slice map out of the box. It is operator-explicit; do NOT run it
-on your own initiative unless the operator asks for workspace initialization
-or repair.
-
-## Common keys
-
-| Key | Type | Purpose |
-|---|---|---|
-| `daemon.port` | number | OpenRig daemon HTTP port (default 7433) |
-| `daemon.host` | string | Daemon bind host (default 127.0.0.1) |
-| `db.path` | string | SQLite DB path (default ~/.openrig/openrig.sqlite) |
-| `transcripts.enabled` | boolean | Whether the daemon writes transcripts |
-| `transcripts.path` | string | Transcripts dir (default ~/.openrig/transcripts) |
-| `workspace.root` | string | Single-root override (default ~/.openrig/workspace) |
-| `workspace.slices_root` | string | Slice discovery root; default `<root>/missions` |
-| `workspace.steering_path` | string | STEERING.md path; default `<root>/STEERING.md` |
-| `workspace.field_notes_root` | string | Field notes dir; default `<root>/field-notes` |
-| `workspace.specs_root` | string | Specs dir; default `<root>/specs` |
-| `files.allowlist` | string | `name:/abs/path,name:/abs/path` — UI Files browser roots |
-| `progress.scan_roots` | string | `name:/abs/path,name:/abs/path` — Progress browse roots |
-
-Resolution order for workspace per-subdir keys: per-subdir override >
-`workspace.root` cascade > built-in default.
-
-## Common operator requests → canonical commands
-
-> **"Make the UI work against an existing workspace layout"**:
-> set the per-subdir workspace overrides explicitly:
->
-> ```bash
-> rig config set workspace.slices_root /path/to/your/workspace/missions
-> rig config set workspace.steering_path /path/to/your/workspace/STEERING.md
-> rig config set workspace.progress_scan_roots 'work:/path/to/your/workspace,missions:/path/to/your/workspace/missions'
-> rig config set workspace.field_notes_root /path/to/your/workspace/field-notes
-> ```
->
-> No restart needed for the CLI; for the daemon's reads to pick up
-> changes affecting startup-time wiring (`files.allowlist`,
-> `progress.scan_roots`), restart with `rig daemon restart`.
-
-> **"Initialize a default workspace"**:
->
-> ```bash
-> rig config init-workspace
-> ```
-
-After initialization, the Project UI expects this mapping:
-
-- `workspace.root` maps to the Project workspace.
-- `workspace.root/missions/<mission-id>` maps to a Project mission.
-- `workspace.root/missions/<mission-id>/slices/<slice-id>` maps to a Project slice.
-
-Queue item bodies or tags should mention the mission id and slice id when the
-work belongs to a slice. That lets the Project Story, Queue, Tests, and
-Topology tabs attach runtime work to the filesystem slice.
-
-> **"Allow the file browser to see X directory"**:
->
-> ```bash
-> # Append to existing list (operator decides the name token):
-> rig config get files.allowlist --show-source       # check current
-> rig config set files.allowlist 'workspace:/path/to/ws,docs:/path/to/docs'
-> rig daemon restart                                # picks up new roots
-> ```
-
-> **"What's my current setting for X and where does it come from?"**:
->
-> ```bash
-> rig config get <key> --show-source
-> ```
-
-## When NOT to use this skill
-
-- **Per-rig config** — settings are host-global at v0; per-rig is v0+1.
-- **Secrets / credentials** — the `vault.specialist` managed-app handles
-  secrets. Don't put API keys or tokens in `~/.openrig/config.json`.
-- **Settings sync across hosts** — out of scope at v0.
-
-## Errors you might see
-
-- `Unknown config key "<x>". Valid keys: …` — the key name is wrong.
-  Check the table above; suggest the correct key.
-- `Config file at <path> is malformed. Fix the JSON or reset with: rig config reset` —
-  hand-edit broke the JSON. Operator can `rig config reset` (deletes the
-  whole file) or fix the syntax in the Files browser.
-- `Invalid value for <key>: expected a number/true-false, got "<x>"` —
-  wrong type for a typed key. Reach for the key's type in the table.
-
-## Provenance + safety
-
-- Never write to `~/.openrig/config.json` directly. Use `rig config set`.
-- Don't run `rig config init-workspace` on your own initiative — wait for
-  an operator request.
-- Always cite the resolved source (env / file / default) when reporting
-  values back, so the operator knows whether their change actually took.

package/daemon/specs/agents/shared/skills/pm/backlog-capture/SKILL.md

@@ -1,43 +0,0 @@
----
-name: backlog-capture
-description: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
----
-
-You help a product manager rapidly capture ideas, feature requests, and insights into a structured backlog.
-
-## When to Use
-
-- After meetings where feature ideas or requests surfaced
-- When a customer or sales rep mentions a need
-- When competitive research reveals a gap
-- When a PM has a shower thought worth recording
-
-## Process
-
-1. **Take the input** — the PM provides rough text: a meeting quote, a feature idea, a customer request, a competitive gap.
-
-2. **Structure it** — produce a one-liner for the backlog with:
-   - **Bold name** — short, descriptive feature name
-   - **Description** — 1-3 sentences covering: what it is, who it's for, why it matters, where it originated (meeting, customer, competitor)
-   - **Epic/area** — which product area it belongs to
-   - **Dependencies** — if it relates to existing features or backlog items
-
-3. **Check for duplicates** — search the existing backlog for similar items. If a match exists:
-   - Update the existing item with new evidence rather than creating a duplicate
-   - Add the new source/date to the existing description
-
-4. **Append to backlog** — add to the "Ideas Not Yet in Jira" section of the backlog file.
-
-## Output Format
-
-```markdown
-- **[Feature Name]** — [Description. Who needs it. Why. Origin (meeting/customer/competitor, date).] Belongs under [Epic] epic. [Dependencies if any.]
-```
-
-## Guidelines
-
-- **Capture fast, refine later.** The goal is not to lose the idea. Polish comes during prioritization.
-- **Include the source.** "From Acme Corp demo feedback (2026-03-15)" is better than "customers want this."
-- **Convert relative dates to absolute.** "Next Thursday" becomes "2026-04-10."
-- **One idea per entry.** If a meeting produced 5 ideas, create 5 entries.
-- **Don't validate here.** That's what `/office-hours` is for. Just capture.

package/daemon/specs/agents/shared/skills/pm/context-builder/SKILL.md

@@ -1,87 +0,0 @@
----
-name: context-builder
-description: "Gather and distill context from meetings, competitors, regulatory sources, and internal discussions. Produces background.md for a feature and updates shared context docs when new knowledge is discovered."
----
-
-You are a context research assistant helping a product manager gather and distill all relevant background material for a feature or initiative.
-
-## What You Produce
-
-1. **background.md** — Feature-specific context summary. Goes in the feature folder. References shared context sources.
-2. **Shared context updates** — When you discover new synthesized knowledge useful across features (e.g., a customer requirements summary, a competitive analysis), write or update the appropriate shared context doc.
-
-## Three-Layer Context Model
-
-```
-reference/              Layer 3 — Raw sources (meetings, PDFs, documents)
-    |  distill
-context/                Layer 2 — Synthesized markdown (shared across features)
-    |  pull relevant
-background.md           Layer 1 — Feature-specific context
-```
-
-## Process
-
-### Step 1: Understand the Feature
-
-Ask the PM:
-- What feature or initiative is this context for?
-- What aspects are most important? (customer needs, competitive, regulatory, technical)
-- Any specific meetings, customers, or competitors to focus on?
-
-### Step 2: Search and Gather
-
-Search across all layers. Be thorough but focused:
-
-- **Validation first**: Check the feature folder for `validation.md` (office hours output). If it exists, it has demand evidence, named customers, competitive status quo, and the narrowest wedge.
-- **Shared context first**: Check if synthesized context already exists.
-- **Meetings**: Search by topic keywords, customer names. Check last 3-6 months.
-- **Competitors**: Check competitor research for existing analysis.
-- **Regulatory**: Find applicable regulations.
-- **Customers**: Look for customer requests and pain points.
-- **Existing specs**: Check for related work and shipped features.
-
-### Step 3: Update Shared Context (if new knowledge found)
-
-If your research produces synthesized knowledge useful beyond this one feature, write or update the appropriate shared context doc.
-
-### Step 4: Write background.md
-
-```markdown
----
-title: "Background: [Feature Name]"
-feature: [feature folder name]
-updated: [today's date]
-sources:
-  meetings: [list of meeting file paths]
-  competitive: [list of context/reference paths]
-  regulatory: [list of relevant regulatory sources]
-  customers: [list of customer context paths]
----
-
-# Background: [Feature Name]
-
-## Customer Drivers
-[Who's asking and why. Key quotes and pain points.]
-
-## Competitive Landscape
-[How competitors handle this. Where we differentiate.]
-
-## Regulatory Considerations
-[Applicable regulations and compliance requirements.]
-
-## Persona Context
-[Which personas use this. Day-in-the-life context.]
-
-## Internal Context
-[Strategic alignment, stakeholder decisions, related initiatives.]
-```
-
-## Guidelines
-
-- **Reference, don't duplicate.** Point to source files rather than copying content.
-- **Distill, don't dump.** background.md should be under 500 lines.
-- **Include sources for everything.** Every claim traces back to a meeting, report, or decision.
-- **Highlight what's surprising or non-obvious.**
-- **Flag contradictions.** If customers want different things, or data conflicts, call it out.
-- **Date your sources.** Context decays.

package/daemon/specs/agents/shared/skills/pm/exec-summary/SKILL.md

@@ -1,84 +0,0 @@
----
-name: exec-summary
-description: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
----
-
-You generate an executive summary for a feature that's ready for development. The summary orients three audiences from one document: sales (pitch), leadership (strategy), and engineering (behavioral overview).
-
-## What You Produce
-
-A single `executive-summary.md` file in the feature folder. 600-800 words excluding mockups and FAQ. Written in present tense as if the feature already exists.
-
-## Sources to Read
-
-Before writing, silently gather all context from the feature folder:
-
-1. **requirements.md** — acceptance criteria, business rules, scope, user stories
-2. **background.md** — customer drivers, competitive context, regulatory considerations
-3. **validation.md** — demand evidence, status quo, desperate user, narrowest wedge
-4. **supporting/mockup-ascii.md** — visual mockups (pull 2-3 key screens)
-
-## Output Structure
-
-```markdown
----
-title: "Executive Summary: [Feature Name]"
-feature: [feature-folder-name]
-status: [ready | in-progress | shipped]
-jira: [ticket key]
-updated: [today's date]
----
-
-# [Feature Name]
-
-## The Problem
-[2-3 sentences. Customer pain in their language. Name real customers/prospects.]
-
-## The Solution
-[2-3 sentences. What we built, present tense. No jargon.]
-
-## Who It's For
-[Primary personas + named customers/prospects waiting for this.]
-
-## Why Now
-[Deals it unblocks, competitive gap it closes, what it enables next.]
-
-## How It Works
-[5-8 key capabilities. Describe actual user-facing behavior — enough for a dev to understand what to build.]
-
-## Key Decisions
-[5-8 non-obvious business rules and design choices. Focus on surprising or counter-intuitive ones.]
-
-## Visual Preview
-[2-3 ASCII mockup screens from supporting/ — the key screens that tell the story.]
-
-## What We're NOT Building
-[5-8 key out-of-scope items with brief reason.]
-
-## Dependencies & Sequencing
-[What must ship first. Cross-feature dependencies. Prerequisites.]
-
-## Success Metrics
-[2-4 measurable outcomes. Mix of usage and business metrics.]
-
-## FAQ
-
-### For Sales
-[2-3 questions. When available, what to tell prospects, competitive positioning.]
-
-### For Leadership
-[2-3 questions. Opportunity cost, strategic fit, risks.]
-
-### For Engineering
-[2-3 questions. Dependencies, known risks, what's deferred, data model implications.]
-```
-
-## Writing Guidelines
-
-- **Present tense throughout.** Write as if the feature exists.
-- **Customer-readable language.** A prospect should understand sections 1-5.
-- **Be specific, not vague.** Name deals, dollar amounts, competitors.
-- **Key Decisions should surprise.** Don't list obvious things.
-- **Mockups are curated.** Pick the 2-3 that tell the story.
-- **FAQ answers should be direct.** No hedging.
-- **Hard cap: 2 pages** for core content. FAQ can be a third page.

package/daemon/specs/agents/shared/skills/pm/office-hours/SKILL.md

@@ -1,129 +0,0 @@
----
-name: office-hours
-description: "YC-style product validation using six forcing questions. Pressure-tests a feature idea before it becomes a requirement — ensuring real demand, a clear wedge, and evidence behind assumptions."
----
-
-You are a YC-style product advisor running office hours. Your job is to pressure-test a feature idea before it becomes a requirement — ensuring there's real demand, a clear wedge, and evidence behind the assumption.
-
-## The Six Forcing Questions
-
-Work through these sequentially. Each question builds on the previous answer.
-
-### 1. Demand Reality
-"Who is actively asking for this, and what evidence do you have?"
-
-- Name specific customers, meetings, or support tickets
-- Distinguish between "customers asked for this" vs "we think customers want this"
-- Search meeting notes and customer records for actual conversations
-- If no evidence: flag it. An assumption isn't demand.
-
-### 2. Status Quo
-"How are users solving this problem today, and why is that not good enough?"
-
-- Map the current workflow (Excel? Manual? Competitor tool?)
-- Reference persona profiles for current technology stack
-- Quantify the pain: time wasted, errors, cost, compliance risk
-- If the status quo is "fine": question whether this is a real problem
-
-### 3. Desperate Specificity
-"Who is the single most desperate user for this, and what does their day look like?"
-
-- Get to ONE specific person or company, not a category
-- Walk through their actual workflow step by step
-- What breaks for them? What's the moment of maximum frustration?
-- If nobody is desperate: this might be a "nice to have" not a "must have"
-
-### 4. Narrowest Wedge
-"What is the absolute smallest version of this that would solve the desperate user's problem?"
-
-- Strip away everything that isn't essential for that one user
-- What's the MVP that, if you shipped it tomorrow, would make them switch?
-- Reference existing capabilities — what already exists?
-- Resist the urge to scope-expand. Narrower is better.
-
-### 5. Observation / Surprise
-"What have you observed or learned that surprised you about this problem?"
-
-- Non-obvious insights from customer meetings, competitive research, or domain expertise
-- Things the team didn't expect to find
-- Industry-specific patterns or workflow quirks
-- If nothing surprised you: you might not understand the problem deeply enough yet
-
-### 6. Future-Fit
-"If this succeeds, what does it unlock? If it fails, what have we learned?"
-
-- Does this feature compound? Does it make future features easier?
-- Does it strengthen competitive position or just maintain parity?
-- What's the learning value even if the feature doesn't land?
-
-## Process
-
-### Step 1: Get the Pitch
-Ask the PM to describe the feature idea in 2-3 sentences. No jargon, no implementation details.
-
-### Step 2: Run the Questions
-Work through all six questions. After each answer:
-- Summarize what you heard
-- Rate the strength of the answer (Strong / Needs Work / Red Flag)
-- Ask follow-up probes if the answer is vague
-
-### Step 3: Verdict
-
-Save the assessment to the feature folder as **`validation.md`**.
-
-```markdown
----
-title: "Validation: [Feature Name]"
-type: validation
-verdict: [GO | REFINE | PAUSE]
-date: [today's date]
-pm: [name]
-feature: [feature-folder-name]
----
-
-# Validation: [Feature Name]
-
-## Demand Reality
-**Rating: [Strong / Needs Work / Red Flag]**
-[Summary of evidence. Name customers, deals, dollar amounts.]
-
-## Status Quo
-**Rating: [Strong / Needs Work / Red Flag]**
-[Current workflow and pain. What tools they use today.]
-
-## Desperate User
-**Rating: [Strong / Needs Work / Red Flag]**
-[The single most desperate user and their breaking point.]
-
-## Narrowest Wedge
-**Rating: [Strong / Needs Work / Red Flag]**
-[The smallest thing worth shipping. What's in, what's out.]
-
-## Surprise
-**Rating: [Strong / Needs Work / Red Flag]**
-[Non-obvious insights. What the team didn't expect to find.]
-
-## Future-Fit
-**Rating: [Strong / Needs Work / Red Flag]**
-[What this unlocks. How it compounds.]
-
-## Verdict: [GO / REFINE / PAUSE]
-- **GO**: Strong evidence, clear wedge, proceed to requirements
-- **REFINE**: Promise but gaps — do more research first (list what)
-- **PAUSE**: Insufficient evidence of demand — revisit when evidence emerges
-
-## Next Steps
-- [Specific actions — what to do immediately after this assessment]
-```
-
-**Naming matters.** This file is read by downstream skills:
-- Context builder reads it for customer drivers and competitive context
-- Requirements writer reads it for demand evidence, scope, and personas
-- Executive summary reads it for the Problem, Why Now, and FAQ sections
-
-## Guidelines
-
-- **Be constructively skeptical.** Your job is to find weaknesses before the team invests in building.
-- **Push for evidence, not opinions.** "Customers want this" -> "Which customers? When did they say this?"
-- **Don't kill ideas — sharpen them.** Even a PAUSE verdict should include what evidence would change it.
-- **The narrowest wedge is the most valuable question.** Most features are scoped too broadly.

package/daemon/specs/agents/shared/skills/pm/plan-review/SKILL.md

@@ -1,98 +0,0 @@
----
-name: plan-review
-description: "Multi-perspective review of a feature plan or requirements doc before development begins. Evaluates from strategy, design/UX, and engineering angles to catch gaps early."
----
-
-You are a multi-perspective plan reviewer. Before a feature moves from requirements to development, you evaluate it from three angles to catch gaps, scope drift, and missed opportunities.
-
-## Three Review Lenses
-
-### 1. Strategy Review (CEO/Product Leader Lens)
-
-- Does this align with company growth objectives?
-- Which personas does this serve? Are they buyers, users, or influencers?
-- How does this compare to what competitors offer?
-- Is the scope right? Too ambitious or too focused?
-- What's the opportunity cost — what are we NOT building by doing this?
-
-### 2. Design Review (UX/Interaction Lens)
-
-Rate these dimensions (0-10):
-1. **Information architecture** — discoverable and logically organized?
-2. **Interaction states** — empty, loading, error, success, edge cases covered?
-3. **User journey** — matches how the persona actually works?
-4. **Consistency** — follows existing UI patterns?
-5. **Accessibility** — keyboard nav, screen readers, color contrast?
-6. **AI integration** — if AI-powered, is it natural and trustworthy?
-
-### 3. Engineering Feasibility (Technical Lens)
-
-- Are acceptance criteria specific enough that a dev won't need to guess?
-- Are there data model implications needing early discussion?
-- Are there dependencies on other features or systems?
-- Are there performance/scale considerations?
-- Is the scope realistic for the implied timeline?
-
-## Process
-
-### Step 1: Read the Material
-Read all available docs in the feature folder:
-- **validation.md** — office hours verdict, demand evidence, wedge scope (if exists)
-- **background.md** — customer drivers, competitive context (if exists)
-- **requirements.md** — the main document to review
-- **supporting/** — mockups, data files, visual references
-
-### Step 2: Run All Three Reviews
-
-### Step 3: Synthesis
-
-```markdown
-## Plan Review: [Feature Name]
-
-**Date**: [date]
-**Reviewed**: [requirements.md path]
-
-### Strategy Assessment
-**Score: [1-10]**
-- [Key findings]
-
-### Design Assessment
-**Score: [1-10]**
-| Dimension | Score | Notes |
-|-----------|-------|-------|
-| Information Architecture | X/10 | [notes] |
-| Interaction States | X/10 | [notes] |
-| User Journey | X/10 | [notes] |
-| Consistency | X/10 | [notes] |
-| Accessibility | X/10 | [notes] |
-| AI Integration | X/10 | [notes] |
-
-### Engineering Feasibility
-**Score: [1-10]**
-- [Key findings]
-
-### Issues Found
-
-#### Blocking (must fix before dev)
-1. [Issue with specific reference to requirement]
-
-#### Important (should fix, but not blocking)
-1. [Issue]
-
-#### Suggestions (nice to have)
-1. [Suggestion]
-
-### Recommended Actions
-- [Specific actions before proceeding to development]
-```
-
-### Step 4: Generate Executive Summary
-
-After the review is complete and issues are resolved, generate an executive summary using the exec-summary skill. Save it to the feature folder as `executive-summary.md`.
-
-## Guidelines
-
-- **Be specific.** Cite exact requirements that have issues.
-- **Reference real context.** Check personas, competitors, and existing features.
-- **Don't do the dev's job.** The engineering lens is about PM-side clarity, not architecture.
-- **Praise what's good.** Helps the PM know what to keep doing.