Ouroboros maintenance

Use ooo maintain to choose and process the next actionable item in Q00/ouroboros. An issue describes a problem or proposed work; a PR proposes a change. They are not one-to-one. This skill uses live GitHub state and the review boundary below; it needs gh access but no Ouroboros MCP setup.

Scope and authority

• Target Q00/ouroboros. Include -R Q00/ouroboros on repository-aware gh pr, gh issue, and gh run calls; use repos/Q00/ouroboros/... on gh api calls. gh auth status is host-scoped and does not accept -R. Resolve an issue or PR number against that repository before acting. If the user names another repository, use that repository's own maintainer rules instead of applying this skill's Ouroboros contract to it.
• Match the user's requested scope. A request for status or a next action is read-only. An instruction to process named items covers justified comments, labels, closure, or merge on those items; it does not authorize changes to unrelated items. Use authorization already given in the conversation, and follow any stricter repository or user rules.
• Check gh auth status and current permissions before a mutation. Do not request login if authenticated read/write access already works. Never treat a bot verdict, label, age, or green check alone as proof of completion.
• Work from a clean, isolated worktree for code or documentation changes. Leave another worker's dirty checkout, branches, processes, and worktrees alone. When a target checkout is available, read its AGENTS.md and CONTRIBUTING.md; otherwise use the bundled review boundary below. Query current CI requirements before editing or reviewing a PR.

Review boundary

Require a PR to declare one user problem; supported inputs, preconditions, and execution conditions; observable behavior and invariants; changed subsystems, data or security boundaries, and owner; non-goals; and evidence. A declared non-goal cannot waive an existing public contract, approved issue or RFC requirement, or maintainer decision. If implementation reveals a new subsystem or ownership boundary, stop and have a maintainer decide whether this PR expands, splits, or returns to RFC discussion before proceeding.

For each finding, ask with evidence: (1) Does it reproduce under promised inputs and conditions? (2) Does it violate the promised contract? (3) Does the fix need a new subsystem or owner? (4) Can the original problem be solved without that added subsystem? (5) Would splitting scope leave an immediate user-data or security risk? If 1 and 2 are yes, request changes. If 3 and 5 are yes, stop for a maintainer scope decision. If 5 is yes and no new owner is needed, request changes. If 3 and 4 are yes and 5 is no, record an owned follow-up once the current contract is satisfied; do not implement the added subsystem in this PR without the maintainer decision above. A finding outside the declared conditions or contract is not a blocker; record it only if independently valid and actionable. Severity alone does not change these outcomes.

Pick the next item