longrun

Close out a completed Lighto task: full validation, final report, rebase. Requires the task file path as input.

Tiered Lighto code review gate: scripted checks, parallel narrow checks, broad review. Invokable standalone on any diff, or as part of the Lighto workflow.

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

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

Execute one Lighto subtask: plan, TDD, validate, browser-verify, review gate, commit. Requires the task file path and subtask number as input; use only on an existing Lighto task file.

Record user feedback for the active Zoo spec without interrupting current work. Use only when explicitly requested, especially when the user gives feedback to address later during Zoo Heavy, Zoo Lite, Zoo Zero, or another running Zoo workflow.

Verify browser-visible Zoo behavior and capture focused UI evidence. Use only when explicitly requested.

Archive completed Zoo spec files and resolved proposal files. Use when Codex is asked to clean up finished `.spec` work, move completed specs into an `archived/` subfolder, or move fully implemented/rejected proposals into an archive, while honoring repo-local Zoo path overrides.

Implement the smallest correct code change for an approved Zoo active subtask plan. Use only when explicitly requested.

Review Zoo implementation changes for correctness, regressions, evidence, simplicity, and missing tests. Use only when explicitly requested.

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

Manual deployment-safety validation for unpushed commits by default, or user-specified changes. Use only when explicitly requested, especially inside Codex /goal or Claude /loop, to de-risk deployment by adversarially hunting missed production rollout failures, legacy-data and migration hazards, mixed-version issues, and other real-world deployment risks before producing a firm safety guarantee or concrete proof of unsafety.

Spec-based Zoo 2.1 workflow with subagent for each step. Use only when explicitly requested.

Use when updating, tuning, debugging, or aligning Zoo workflow guidance from operational feedback. Prefer updating repo-local .zoo/*.md files; edit main skills or subagents only when explicitly instructed.

Research a repository and initialize real project-specific Zoo and Lighto customization files under .zoo, then verify Bureau MCP access. Use when setting up Zoo or Lighto workflow customization for a repository.

Spec-based Zoo 2.1 workflow with subagent for research, review and browsing. Use only when explicitly requested.

Pause a running Zoo workflow as soon as the current step reaches a safe handoff. Use only when explicitly requested, especially to stop after in-flight subagent work without running final Zoo Report.

Review Zoo Workflow specs and active-subtask implementation plans for correctness, completeness, evidence, and clarity. Use only when explicitly requested.

Plan Zoo Workflow subtasks by researching code, maintaining the spec contract, and producing detailed tactical HOW for the active subtask. Use only when explicitly requested.

Investigate Zoo workflow blockers and root causes through focused debugging and evidence. Use only when explicitly requested.

Write durable Zoo proposal files for significant cross-cutting work that needs human approval before implementation. Use when the user asks for a proposal, or when Zoo Refactoring, planning, implementation, code review, plan review, uberreview, or another Zoo workflow classifies a finding as proposal-worthy instead of current-task implementation.

Manually publish completed Zoo workflow changes by reading repo push instructions, running Zoo Rebase first, and pushing or following the repo's prescribed PR/trunk workflow only when Zoo Rebase reports that the repo is safe to push. Use only when the user explicitly asks to push, publish, open a PR, or run Zoo Push.

Rebase completed trackable Zoo workflow changes onto the upstream branch, resolve conflicts, rerun validation when incoming changes could affect tests, write a Bureau rebase report, and decide whether the repo is safe to push. Use automatically during Zoo Heavy, Zoo Lite, Zoo Zero, and other Zoo workflow closeout after all docs updates and commits are finished but before the final report; also use when Zoo Push needs a pre-push rebase gate.

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 or suggested change affects pre-existing code outside the active task, creates a broad mechanism, touches many call sites/files, changes subsystem behavior, introduces a one-off local pattern for a broader concern, or would otherwise expand the task beyond its approved scope.

Produce the final user-facing report for completed Zoo workflow runs. Use at the end of Zoo Heavy, Zoo Lite, Zoo Zero, or another top-level Zoo workflow after required implementation, review, validation, docs, and commits are complete, just before the agent exits or sends its final response to the user.

Write or update tests that define expected behavior for a Zoo active subtask. Use only when explicitly requested.

Run a super-comprehensive multi-agent review based on the repository instructions. Use after normal review; for code changes, enforce a single orchestrator-owned final-state validation gate and keep reviewer subagents focused on review instead of rerunning the same suites.

Direct execution followed by review+fix iterations. Use only when explicitly requested.