Agent Skills

---

name: eol-readiness-advisor

description: Run a go/no-go assessment for retiring a product or feature, then right-size the effort. Use when someone says "we should probably kill this" and nobody has made the call.

---

name: eol-stakeholder-sequence

description: Plan who to talk to about a sunset, in what order, and what each conversation must cover. Use when an EOL decision is made and you want the landmines found before the announcement.

---

name: epic-breakdown-advisor

description: Break down epics into user stories with Humanizing Work split patterns. Use when a backlog item is too large to estimate, sequence, or deliver safely.

---

name: epic-hypothesis

description: Frame an epic as a testable hypothesis with target user, expected outcome, and validation method. Use when defining a major initiative before roadmap, discovery, or delivery planning.

---

name: executive-onboarding-playbook

description: Plan a VP or CPO 30-60-90 day diagnostic onboarding path. Use when entering a new executive product role and avoiding premature change.

---

name: feature-investment-advisor

description: Evaluate feature investments using revenue impact, cost structure, ROI, and strategy. Use when deciding whether a feature deserves investment.

---

name: agent-starters

description: Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance.

---

name: agent-startup-and-context-ingestion

description: Use when designing or auditing how an agent becomes useful after launch — AGENTS.md overlays, role files, skills, rig specs, workflow specs, startup checklists, refocus messages, "rig context" surface. Covers the 4 failure modes that make startup context fail (old rig spec misses current operating mode; current agents never told about new guidance; startup file as dumping ground; orchestrator transmits implementation without preserving product intent).

---

name: backlog-capture

description: Quickly capture product ideas, feature requests, or insights from meetings and conversations. Rapid documentation with smart categorization and deduplication.

---

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.

---

name: cross-host-rig-commands

description: Use when addressing a registered remote OpenRig host, choosing its transport, or interpreting a cross-host result.

---

name: developing-openrig

description: Use when changing OpenRig's own source in a clone of the openrig repository: finding which package or file owns a behaviour, choosing which tests to run, testing a change without disturbing the OpenRig daemon your own session runs on, judging whether a diff touches a high-risk area, or preparing a pull request. Not for operating rigs (openrig-skills) or designing rig topologies.

---

name: developing-openrig

description: Use when changing OpenRig's own source in a clone of the openrig repository: finding which package or file owns a behaviour, choosing which tests to run, testing a change without disturbing the OpenRig daemon your own session runs on, judging whether a diff touches a high-risk area, or preparing a pull request. Not for operating rigs (openrig-skills) or designing rig topologies.

---

name: development-team

description: Use when a development pod begins or hands off implementation, QA, or design work.

---

name: exec-summary

description: Generate a 1-2 page executive summary for a feature — orients sales, leadership, and engineering from a single document.

---

name: human-in-the-loop

description: Use when classifying a slice closeout (auto-continue / human gate / park), routing a real decision to a human, or designing a human queue/dashboard surface. Treats humans as durable network participants with attention surfaces, queues, and decision records — escalation lands as a durable attention item, not a chat message. Approval is NOT required for every clean closeout; the default RSI conveyor continues unless an explicit human gate is reached.

---

name: messaging-the-human

description: Use when project policy calls for a human decision or update, a human delivery is pending or failed, or a reply must resume the right work.

---

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.

---

name: openrig-architect

description: Use when designing multi-agent topologies that run ON OpenRig — authoring RigSpec and AgentSpec files for new rigs, creating agent startup content (guidance / skills / culture), or diagnosing why a launched rig's agents aren't behaving as intended. NOT for changing OpenRig itself (use developing-openrig); NOT for ordinary CLI operation of an existing rig (use openrig-user). Covers the full authoring lifecycle from user intent to validated, launchable rig.

---

name: openrig-cmux

description: Use when opening OpenRig fleet terminals into cmux — turning a rig, pod, mission, slice, or saved view into live agent tiles via `rig terminal --provider cmux`, or driving cmux on an agent's request. Same OpenRig view semantics as openrig-herdr (the verbs, honest-partial/degrade, read-only cross-rig, scroll/copy, same-size-only duplicates); cmux is the **best-effort** provider (herdr is the default and the proof-gated one). Prefer openrig-herdr unless cmux is specifically wanted.

---

name: openrig-herdr

description: Use when opening OpenRig fleet terminals as a herdr wall — turning a rig, pod, mission, slice, or saved view into live interactive agent tiles via `rig terminal`, watching another rig read-only, or driving herdr on an agent's request ("open all my rigs + a mission as views"). Covers the `rig terminal open|views|status` verbs, the honest-partial/degrade reading of the result, the read-only-by-construction rail for cross-rig views, scroll/copy out of the box, and the same-size-only duplicate-pane limit. herdr is the default, proof-gated provider.

---

name: openrig-skills

description: Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't know what applies or nothing is projected on cold boot.

---

name: openrig-software-factory

description: Use when a user wants a continuing software team for a real repository, or has a first OpenRig team and needs a repeatable path for reviewed work and later tasks.

---

name: openrig-upgrade

description: Use when an agent is preparing or performing an OpenRig CLI/daemon upgrade and must preserve live seats, verify each mutation, or reconcile managed plugin and skill files without overwriting local work.