@openrig/cli 0.5.1 → 0.5.3

package/daemon/context-packs/skills/core/watchdog/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: watchdog
+description: Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking.
+metadata:
+  openrig:
+    stage: factory-approved
+    sibling_skills:
+      # Sibling sweep 2026-07-19 audit: superseded control-plane-* family
+      # dropped (control-plane-watchdog now redirects HERE); kept the
+      # genuinely adjacent set.
+      - queue-handoff
+      - workflow-runtime
+      - refocus
+      - looping-workflows
+      - intake-routing
+      - human-in-the-loop
+      - status-not-chat-orchestrator
+      - oversight-team
+---
+
+# Watchdog
+
+Continuity checks are timed or evidence-triggered interventions that
+keep an agent workflow from going idle, drifting, or entering needless
+bureaucracy. They operationalize the refocus doctrine.
+
+## Use this when
+
+- **Authoring a watchdog policy** for a long-running rig (artifact-pool
+  edges, stale-owner detection, periodic reminders).
+- **Choosing the intervention level** for a stale-owner situation: is
+  this a wake, a refocus, or an alignment checkpoint?
+- **Drafting wake/refocus/alignment-checkpoint message text** that
+  prevents cadence pollution and bureaucracy theater.
+- **Deciding cadence** — scan vs wake intervals, conservative vs
+  aggressive nudging.
+
+## Don't use this when
+
+- The agent is actively working and closing artifacts. Prefer no-op.
+- The intervention is masking bad startup or workflow design — fix the
+  underlying cause, don't compensate via watchdog.
+- The work has a clear next-action handoff already in queue. Use queue
+  nudges instead of a watchdog policy.
+
+## The 3-level intervention stack
+
+| Level | Goal | When | What it does |
+|---|---|---|---|
+| **Wake** | Restart motion | Owner appears idle, stale, blocked, or missing a next handoff | Small liveness nudge — does NOT reframe the work |
+| **Refocus** | Correct drift | Output shows mode drift, approval regression, weak stop-condition reasoning | Medium alignment nudge — re-centers on role, north star, current approved workstream, coordination mode, stop conditions; does NOT interrupt valid work |
+| **Alignment checkpoint** | Rebuild shared map | Phase boundary, lifecycle mutation, product-intent decision, confusing contradiction | Larger deliberate pause — agent runs full refocus before proceeding |
+
+`cron`, timers, and `rig watchdog` are scheduling substrates. They
+should NOT imply that every tick means the same semantic action. The
+intervention level is chosen by evidence, not cadence.
+
+## Current best practice for refocus message text
+
+A well-shaped refocus message:
+
+- Starts with: **finish current action first**.
+- Names the intervention kind: wake, refocus, or alignment checkpoint.
+- Names the current approved workstream or says none is known.
+- Says what continuity means: continue, verify, hand off, or explicitly park.
+- Names stop conditions: scope/risk/posture changes, failed gate, contradictory evidence, or no continuity chain naming a sensible next step.
+- Does NOT convert itself into a fresh approval gate.
+- Does NOT wake delivery seats unless an approved workflow exists and the owner is stale.
+
+## Failure modes (7; verbatim)
+
+1. Cadence is too frequent and pollutes the workstream.
+2. Watchdog wakes the wrong seat instead of the stale owner.
+3. Refocus text is too rule-shaped and creates brittle behavior.
+4. Watchdog compensates for bad startup or workflow design instead of revealing it.
+5. Refocus is misread as a new top-priority task and interrupts the current action.
+6. Refocus becomes bureaucracy theater: an already-approved workflow stops for re-approval.
+7. Repeated static nudges teach agents to answer the reminder instead of progressing the artifact.
+
+## Artifact-pool loop edges (the first evidence-aware pattern)
+
+The first evidence-aware watchdog use that should remain small and
+explicit:
+
+- **Consumer-pool wake**: if a ready artifact exists, wake the consumer loop head.
+- **Producer-edge repair**: if upstream completion exists but the downstream artifact is missing, wake the producer loop head.
+
+**Scan cadence and wake cadence are separate.** Worked example (from the
+RSI v2 mission, now archived — the numbers are era-specific, the
+scan-vs-wake separation is the durable rule): scan every 30 seconds, wake
+at most every 600 seconds while work remains actionable.
+
+This is not a generic workflow engine. It's a guardrail against cold
+pools and missing edge artifacts.
+
+## Two surfaces: rigx watchdog (config-layer) and rig watchdog (daemon-shipped)
+
+| Surface | Status | Policies |
+|---|---|---|
+| `rigx watchdog` (config-layer dogfood) | Tmux-backed loops; coexists with daemon | Static periodic-reminder + artifact-pool-ready + edge-artifact-required (per-RSI-loop) |
+| `rig watchdog` (daemon-shipped, v0.2.0 Phase C) | SQLite-backed scheduler; survives daemon restart | `periodic-reminder` / `artifact-pool-ready` / `edge-artifact-required` / `workflow-keepalive` (Phase D — reads workflow_instances directly) |
+
+Daemon `rig watchdog` is the active host coordination surface for new
+work. History records only loud evaluations (`sent` / `terminal`);
+quiet skip reasons are NOT recorded — POC parity so agents are not
+woken about scheduler polls.
+
+## Future shape (current limit)
+
+The mature primitive should be evidence-aware: inspect durable
+queue/workflow state, pane activity, transcript/context growth, and
+known workstream frontier; classify the intervention as no-op / wake /
+refocus / alignment-checkpoint; prefer no-op for active owners; render
+message text from the active orientation graph instead of hard-coding
+static policy.
+
+Until queue substrate, activity state, and lifecycle evidence are fully
+productized at this level of granularity: keep config-layer use small
+and explicit, prefer one workflow watchdog plus targeted exception
+handling over many per-seat nag loops.
+
+## See also
+
+- `refocus` skill — the doctrine this primitive operationalizes; full and light trace templates
+- `queue-handoff` skill — durable handoff via queue items; watchdog is complementary (watchdog wakes; queue routes)
+- `looping-workflows` skill — operating discipline for self-driving rig-shaped loops; uses watchdog policies for loop edges

package/daemon/context-packs/skills/core/watchdog/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: "watchdog"
+version: "0.5.3"
+purpose: "Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Use when configuring `rig watchdog` policies, authoring wake/refocus/alignment-checkpoint messages, or choosing the right intervention level for a stale-owner situation. The 3-level continuity-check stack (wake / refocus / alignment-checkpoint), the discipline that prevents cadence pollution and bureaucracy theater, and the artifact-pool loop-edge pattern for evidence-aware waking."

package/daemon/context-packs/skills/pm/backlog-capture/SKILL.md

@@ -0,0 +1,43 @@
+---
+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/context-packs/skills/pm/backlog-capture/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: "backlog-capture"
+version: "0.5.3"
+purpose: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication."

package/daemon/context-packs/skills/pm/context-builder/SKILL.md

@@ -0,0 +1,87 @@
+---
+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/context-packs/skills/pm/context-builder/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: "context-builder"
+version: "0.5.3"
+purpose: "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."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "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."

package/daemon/context-packs/skills/pm/exec-summary/SKILL.md

@@ -0,0 +1,84 @@
+---
+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/context-packs/skills/pm/exec-summary/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: "exec-summary"
+version: "0.5.3"
+purpose: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document."

package/daemon/context-packs/skills/pm/office-hours/SKILL.md

@@ -0,0 +1,129 @@
+---
+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/context-packs/skills/pm/office-hours/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: "office-hours"
+version: "0.5.3"
+purpose: "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."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "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."

package/daemon/context-packs/skills/pm/plan-review/SKILL.md

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

package/daemon/context-packs/skills/pm/plan-review/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: "plan-review"
+version: "0.5.3"
+purpose: "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."
+files:
+  - path: "SKILL.md"
+    role: "instruction"
+    summary: "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."