agents

Entry point for the devflow workspace lifecycle. Load this first when the user asks to run a devflow stage, create or inspect devflow artifacts, decide what stage comes next, generate RFC/spec/plan/tasks, run a feature through AFK work, or finish/archive a feature.

Minimal tmux workflow for running long-lived commands in named sessions: create a session, send commands, inspect recent output, stop a process, kill a session, and keep names consistent for search and cleanup. Use when an agent needs a durable terminal session for servers, watchers, REPLs, or commands that may need later inspection.

Practical Codex session forensics quickstart. Use when the user wants to inspect Codex dialogue logs captured by this repo's harness Codex hooks, locate the current or recent Codex conversation, extract user/assistant dialogue, audit file/tool activity, or fall back to raw Codex rollout JSONL sessions when the stable dialogue log is missing.

Practical Pi session forensics quickstart. Use when the user wants to inspect Pi .jsonl session files, locate recent sessions, extract conversation text, audit tool usage, check costs, or debug this repo's subagent-session manifests. Defers to official Pi docs for authoritative session schema and lifecycle.

Practical Claude Code session forensics quickstart. Use when the user wants to inspect Claude Code .jsonl session transcripts, locate a session from a message they saw in the UI, extract user/assistant messages, audit tool calls (reads, edits, writes, bash), pull a tool result for a given request, or check session cost/usage (deferred to ccusage). Covers the on-disk session schema, the ~/.claude (or CLAUDE_CONFIG_DIR) layout, and the harness plugin's stable dialogue log for clean user/assistant Q&A extraction.

Render a long-form or visually-structured response as a single self-contained HTML file and open it in the browser, instead of printing >50 lines to the terminal. Use when the response would benefit from diagrams (Mermaid or Graphviz), wide tables, side-by-side comparisons, diffs, callouts, or collapsible detail. Triggers on phrases like "rich response", "open this in the browser", "render as HTML", "give me a doc", "diagram this", or whenever the response would otherwise exceed roughly 50 lines of terminal output.

Create git commit(s) with a well-crafted conventional commit message

Guide for authoring well-structured agent skills using a knowledge/procedures/decisions taxonomy. Use when users want to create a new skill, improve an existing skill's structure, or convert a workflow into a skill. Triggers on phrases like "create a skill", "write a skill", "turn this into a skill", "structure this skill", "improve this skill", or any request to encode a workflow, runbook, or process as a reusable SKILL.md. Also use when a user asks how to organise skill content, or wants to add state-machine logic to an existing skill.

Pitfalls to avoid when writing Mermaid diagrams. Use whenever generating a `mermaid` code block, a `<pre class="mermaid">` block, or troubleshooting a Mermaid render error. Assumes you already know Mermaid syntax — this skill only covers the gotchas that silently break renders.

Squash-merges a local branch or linked git worktree into the branch currently checked out in this repository, then removes the merged worktree (if any) and deletes the merged local branch. Use when the user says "merge <branch>", "merge this worktree", "squash merge and clean up", or asks to fold a feature branch/worktree into the current trunk branch.

Guidance on how to write robust-enough software without defensive noise. TRIGGER when: handling review comments about edge cases, failure modes, fallback behavior, graceful degradation, retries, validation, or error handling. SKIP when: making a purely happy-path change with no new failure behavior.

Decide whether and how to write tests: when a test earns its keep, what to cover, what to leave to the type system or schemas, and how to lean on surrounding patterns. TRIGGER whenever authoring a new test or test file, adding test cases to an existing file, covering code with tests, writing a regression test for a bug fix, or about to create test scaffolding/fixtures/mocks — unless the user has given clear direction on exactly what to test (specific cases, assertions, or boundaries named). SKIP only when: the user has spelled out the test cases to write, or editing an existing test that already follows a clear local pattern (mirror the pattern instead).