zoo

Rant, swear, and insult like Linus Torvalds on the LKML — brutally blunt technical criticism. Use when user asks for Linus review/voice or for swearing.

Terse writing/comm style. Use for agent messages, skills, instructions, memories, docs, comments, commit messages and similar.

Record user feedback for the active task without interrupting work. Use only when explicitly asked to add, remember, or handle later.

Verify browser-visible behavior and capture focused UI evidence. Use after implementation for browser-impact work or when explicitly requested.

Archive completed Zoo spec files and resolved proposal files. Use when cleaning finished `.spec` work, moving completed specs into `archived/`, or moving implemented/rejected proposals into archive while honoring repo-local Zoo path overrides.

Tiered code review gate: tests, scripted checks, narrow parallel checks, broad review. Invokable standalone on any diff or inside Zoo workflow.

Update durable documentation for completed Zoo work. Use when a Zoo docs writer or orchestrator should preserve practical learnings, behavior, or public documentation changes.

Manual deployment-safety validation for unpushed commits or user-specified changes. Use only when explicitly requested, especially in Codex /goal or Claude /loop, to hunt production rollout failures, legacy-data and migration hazards, mixed-version issues, and other real deployment risks before declaring safe or unsafe.

Update, trim, or align Zoo workflow guidance from operational feedback. Use when fixing workflow behavior, skill wording, repo-local .zoo guidance, or agent instructions.

Initialize repo-local .zoo customization files for Zoo from real repository research. Use when setting up Zoo customization for a repository.

Pause a running Zoo workflow at a safe handoff. Use only when explicitly asked to pause, stop, or leave work resumable.

Write durable proposal files for significant cross-cutting work needing human approval before implementation. Use when user asks for a proposal, or when Zoo Refactoring, planning, implementation, or review classifies a finding as proposal-worthy.

Manually publish completed changes by reading repo push instructions, running Zoo Rebase first, and pushing or following repo PR/trunk workflow only when rebase says safe. Use only when explicitly asked to push, publish, open PR, or run Zoo Push.

Rebase completed changes onto upstream, resolve conflicts, rerun validation when incoming changes could affect tests, and decide push safety. Use during Zoo closeout and before Zoo Push.

Classify and route Zoo refactorings, local structural cleanups, and cross-cutting changes to proposals, separate subtasks, or current-task work. Use in Zoo workflows, planning, implementation, tests, and reviews when a needed/suggested change affects pre-existing code outside active task, creates broad mechanism, touches many call sites/files, changes subsystem behavior, introduces one-off local pattern for broader concern, or expands approved scope.

Lightweight spec-driven workflow: collaborative spec, top-level TDD implementation, tiered parallel review gate, one commit per subtask. Use only when explicitly requested.

Review task file spec from all angles: flag omissions, fix uncontroversial problems, punt real decisions to user. Requires task file path.