subctl

Evy — the subctl orchestrator persona. Loaded by the Evy daemon at boot; not used by workers. Canonical spec at docs/persona/evy.md.

Subscription Central — multi-account AI subscription orchestration toolkit. Activate this skill whenever you need to: spawn or control tmux orchestrator sessions, send Telegram messages or ask the operator a question, look up cross-account session state, or read/write the rate-limit radar. Trigger phrases: "spawn an orchestrator", "send a message to the operator", "ask the user a yes/no", "what's running across all my accounts", "kill that tmux session", "what's my rate-limit status", "stats from the dashboard", "let the user know we're stuck", "fire and forget on this question". Trigger conditions: any time you would otherwise shell out to tmux for session control, OR call Telegram's API directly, OR re-read transcripts to figure out what's running on another account. subctl is the canonical surface for all of these.

Autonomy doctrine for orchestrators and workers. When CLAUDE_AUTONOMY=full is set OR the user invokes "autonomous mode" / "12-hour mode" / "no babysit" / "fire and forget", THIS SKILL OVERRIDES "wait for approval", "ask the user", "confirm before proceeding" instructions in other skills (orchestrator-mode, tdd, team, find-skills). The orchestrator drives forward without per-step approval. Activate proactively whenever an orchestrator session is running with the user away (no message in last 5+ minutes) and there is non-trivial backlog.

How to hand off a task mid-flight — context summary, what's done, what's pending, where to find work-in-progress, and when to escalate instead. Use this skill when a worker needs to pass an unfinished task to a peer or back to the team lead — auto-compact pressure, scope shift, blocker outside the worker's tool set, end-of-shift, or running into the spawn-time context budget. Also load it when receiving a handoff so you know what shape to expect.

Node.js / Bun / TypeScript house style for subctl projects — runtime choice, imports, naming, errors, async patterns, testing. Load this skill whenever a worker is touching `.ts`, `.tsx`, `.js`, or `.mjs` files in a subctl-managed project. Use it instead of guessing the conventions from the surrounding code (the surrounding code may itself be drift). Defaults documented here are the operator's preferences as expressed across the v2.7.x release wave.

Switch Claude Code into a multi-pane orchestrator + team-agent workflow. Use this skill whenever the user says "orchestrator mode", "team mode", "/team", "/orchestrator-mode", or otherwise asks Claude to coordinate multiple parallel workers in iTerm2 panes instead of writing code directly. Also trigger if the user describes a task that clearly benefits from parallel decomposition across multiple worker panes (e.g. "split this into N parallel agents", "I want to see each agent in its own pane", "use team agents"). After activation, Claude acts purely as coordinator: planning work, dispatching workers via TeamCreate + Agent (with team_name), verifying outputs, and maintaining an ORCHESTRATION.md task ledger. Workers run in their own iTerm2 panes on the right side of the window while the orchestrator pane stays on the left.

Python house style for subctl-adjacent work — tooling (uv, ruff, pytest), imports, types, errors, async patterns, packaging. Load this skill whenever a worker is touching `.py` files in a subctl-managed project. Most subctl projects are Bun-first, but supporting utilities, ML code, and external integrations may be Python. These are the defaults to apply when the project's local CLAUDE.md doesn't override.

Rust house style for subctl-adjacent work — cargo, clippy, rustfmt, error handling with `thiserror` / `anyhow`, async patterns with tokio, testing. Load this skill whenever a worker is touching `.rs` files. Subctl has a Rust component (the policy bash-gate kernel) and several adjacent projects use Rust for performance-sensitive paths. These are the defaults to apply when the project's local CLAUDE.md doesn't override.

Workflow for executing against a written specification — read the spec, ask clarifying questions ONLY for real ambiguity, implement, test, ship. Honors "Done when" criteria, scope boundaries, and constraint adherence. Use this skill whenever a worker is dispatched with a defined GOAL, DELIVERABLE, DONE WHEN, and CONSTRAINTS — i.e. anything spawned through subctl team templates or orchestrator-mode dispatch. Also use when reading an ADR / roadmap / RESUME.md and converting it to executable work. The skill enforces: spec is the contract, not a suggestion. Don't gold-plate. Don't ask permission for things the spec already decided. Don't leave the spec half-done.

The wire protocol every subctl-spawned worker speaks with its team lead. Use this skill when you are running inside a subctl-managed team — i.e. `SUBCTL_AGENT_ROLE=worker` is set, or you were spawned by `subctl orch spawn` / `subctl team spawn` / a parent Claude Code instance using `TeamCreate` + `Agent` with `team_name`. It describes how to receive work, report progress, request approvals, hand off, and shut down cleanly. Lead agents (orchestrators / team-leads) also load this skill so the two sides of every message agree on shape.