Agent Skills

---

name: orchestration-team

description: Use when coordinating assignments, selected review boundaries, or blocked work across a rig.

---

name: oversight-team

description: Use when you are a seat on the oversight pod (a standing monitor-mode rig that keeps OTHER rigs healthy), configuring or running the drift detectors, or choosing whether to intervene vs escalate. Covers the pull-not-poll posture, the v0 detectors (premature-park, process-drift, off-task, token-burn), the intervention ladder (orchestrator-ping -> refocus -> human escalation), and the cheap+deep model economics. NOT for orchestrating your OWN rig (orchestration-team) and NOT the intervention primitive mechanics (watchdog).

---

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.

---

name: requirements-writer

description: Use when converting PM intake into a slice SPEC.md with observable acceptance outcomes, explicit scope, and advisory sibling build dependencies.

---

name: rig-bundles-and-shareable-artifacts

description: Use when authoring or installing a rig bundle (packaged, shareable artifact that instantiates an opinionated OpenRig topology + workflow), reasoning about the bundle vs extension boundary, or auditing a bundle for portability. Covers the 4 failure modes that prevent bundles from working anywhere but the operator's machine, and the inspect-before-install discipline.

---

name: rig-lifecycle

description: Use when reasoning about the rig lifecycle operations family (create / start / stop / resume / restore / snapshot / release / unclaim / destroy), reading or trusting `rig ps` / lifecycle projections after recovery, or designing proof for a lifecycle scenario. Covers the 4 failure modes (auto-restore creates partial rig; projections report healthier than reality; provider auth treated as impl work; resume succeeds for one runtime fails another) plus the restore-honesty rule (failed resume is FAILED loudly — no auto fresh fallback).

---

name: rigs

description: Use when the user mentions OpenRig, rigs or the rig command, or wants a team of coding agents (Claude Code, Codex) on their project. That includes installing, setting up, starting or updating OpenRig, seeing or getting back to their OpenRig agents, TUI or operator, starting or sharing a team, and joining this session to one.

---

name: session-source-fork

description: Use when authoring a rig spec member or `rig expand` payload that needs to start a new managed seat from a prior runtime conversation source — `session_source: { mode: fork, ref: { kind, value } }`. v1 supports `mode: fork` with `ref.kind: native_id` for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild.

---

name: specification-system

description: Use when authoring rig specs, agent specs, workflow specs, startup/context fragments, operating-mode declarations, or designing the user spec library. Covers the 4 failure modes (spec instantiates topology but not workflow/mode; spec depends on local paths and fails on another host; agents modify specs as one-off files instead of preserving reusable intent; validation proves YAML shape but not whether topology can run) and the validation-vs-runtime-realization distinction.

---

name: topology-mutation-and-seat-management

description: Use when changing a rig while it is alive — `rig grow` / `rig expand` / `rig shrink` / `rig launch` / `rig remove` / `rig discover` / `rig bind` / `rig adopt` / `rig attach`. Covers the 4 failure modes (newly created seat lacks queue/startup/role; edges and permissions not updated; adopt/bind succeeds at tmux but not OpenRig identity; shrink/remove leaves stale topology references) and the rule that mutation must work while the rig is active, not just in clean fixtures.

---

name: ui-mockup

description: Create UI mockups at three fidelity levels — ASCII wireframes for quick iteration, standalone HTML mockups for delivery with requirements, and live prototypes for interaction testing.

---

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.

---

name: agent-first-screenshots

description: Agent-first screenshots — an agent drives the real app via CDP and produces clean, defect-free product screenshots (newsletters, landing pages, social, decks, PR). Dual-channel verification (DOM + pixels + vision) in a capture loop. Use for any "take/redo screenshots of the app" task.

---

name: create-plugin

description: Create an OpenCode plugin for iPolloWork. Scaffolds the plugin file with the correct API shape, tool definitions, and hook registration. Use when the user asks to 'create a plugin', 'write a plugin', or 'make a plugin that does X'.

---

name: daytona-chrome-cdp

description: Launch and control standalone Chrome in a Daytona sandbox via CDP. Use for web sign-in, OAuth, Den Web setup, browser-only flows, or when the app should not be driven through Electron CDP.

---

name: daytona-cloud-server

description: Daytona cloud server, Den sandbox, desktop plus cloud e2e, marketplace server, worker proxy, cloud auth, org policies, connect Electron to Den. Use for server-side setup in validated flows.

---

name: daytona-dev

description: Daytona development environment overview. Use when the user asks about Daytona setup, Daytona toolbox, dev environment, noVNC, CDP, server sandbox, secrets volume, Electron sandbox, standalone Chrome, validation, or artifacts volume.

---

name: daytona-electron-den

description: Electron and Den, desktop plus cloud, two-sandbox e2e, cloud auth, marketplace, org policy, worker proxy, provider sync, desktop handoff. Validate Electron against a Daytona Den server with unified proof.

---

name: daytona-recording-artifacts

description: frame proof, HTML frames, screenshots, recording, PR proof, e2e evidence, validate visually. Daytona artifacts workflow for validated screenshots and optional videos.

---

name: daytona-windows-cert

description: test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating iPolloWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox.

---

name: fraimz

description: create a fraimz, make fraimz, prove it works, frame proof, PR proof, validate experience, e2e evidence, fraimz.html. The full fraimz loop — frame the claim, drive the real app via CDP, validate/repair, output fraimz.html. Use whenever a task ends with "please create a fraimz" or any change needs end-to-end proof.

---

name: get-env-var

description: get an env var, fetch a secret, missing env var, missing token/API key, load secrets from Infisical, infisical. Fetch secrets from the team's Infisical workspace into the shell environment so subsequent commands can use them.

---

name: github-sync-pr-flow

---

name: image-editing

description: Edit an image from the active iPolloWork Image Studio selection or mask without overwriting the source image.