on-keyday

harness-cli

Use when talking to other agents or the harness from inside a runner-spawned task — messaging peers on the agentboard, replying with --in-reply-to, subscriptions, discovering live agents and topics, and notifying the human operator. Also defines the agentboard conventions (handshake, reply topics, trust model) and why you may not be the first process on your task. Reply delivery is asynchronous via the inbox hook — never block on wait/dispatch from an agent turn. Spawning and driving WORKER sessions is the separate supervising-workers skill.

Code & Development Listed

session-debugging

Use when observing or driving a live harness session's terminal from an agent — reading what a shell / TUI / REPL / claude session is showing, injecting keystrokes, running a shell command inside a live PTY, or diagnosing a worker that looks stuck or unresponsive (harness-cli session snapshot / send / exec).

implementation-pitfalls

Use BEFORE dispatching implementer/reviewer subagents (superpowers:subagent-driven-development) or BEFORE extending a layer in this repo. Catalog of concrete past failure modes specific to this project — subagent dispatch checklists + sibling-code grep obligations + spec problem-statement enforcement.

landing-to-main

Use when landing / pushing / merging a harness task-branch's work to a repo's trunk — AND at the START of a session before you write code, to sync the task branch onto the current trunk FIRST (a branch is cut once and never re-synced, so implementing on a stale base makes you rebuild helpers and "fix" footguns the trunk already landed, and hit avoidable conflicts). Covers both local-trunk-authoritative (FF-mirror) repos and PR-based repos. Universal rule — NEVER cherry-pick to the remote (it manufactures dup-SHA divergence) and rebase the task branch onto the current trunk first. Determine each repo's landing policy once and record it in memory.

Code & Development Listed

independent-review

Use when you want a second opinion that does not inherit your framing — adversarial review of a diff or design, catching plausible-but-wrong work, or questioning whether the whole approach is right. Explains when a built-in subagent suffices vs. when to spawn a truly independent agent. For the harness-cli commands themselves, see the harness-cli skill.

supervising-workers

Use when acting on ANOTHER agent's task from inside a runner-spawned task — spawning / driving / killing worker sessions, one-shot `submit` + `logs` / `watch`, attenuating a child's capabilities with `--caps`, moving files in or out of a worker's worktree, running a command in one with `exec`, or reading a worker's diff. Peer-to-peer messaging, replying and subscriptions live in the `harness-cli` skill instead.