codex-orchestrator 2.0.11 → 2.0.13

package/internal-workflow/skills/triage/SKILL.md

@@ -1,134 +0,0 @@
----
-name: triage
-description: Move raw incoming issues and configured external PRs through a triage state machine — categorise, verify, grill if needed, and write durable agent briefs. Do not use for planning-context issues or tickets generated by `$to-tickets`; those publish in their final state.
----
-
-# Triage
-
-Move raw incoming issues on the project tracker through a small state machine.
-Do not process issues marked `Artifact: planning-context` or generated
-`$to-tickets` children: their approved issue bodies are already the durable
-contract and their final states are applied at publication.
-
-If this repo treats external pull requests as a request surface (see the issue-tracker config), triage covers them too: a PR is an issue with attached code. Resolve a bare `#42` to an issue or PR per the tracker config.
-
-Every comment or issue posted to the issue tracker during triage **must** start with this disclaimer:
-
-```
-> *This was generated by AI during triage.*
-```
-
-## Reference docs
-
-- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
-- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope/` knowledge base works
-
-## Roles
-
-Two **category** roles:
-
-- `bug` — something is broken
-- `enhancement` — new feature or improvement
-
-Five **state** roles:
-
-- `needs-triage` — maintainer needs to evaluate
-- `needs-info` — waiting on reporter for more information
-- `ready-for-agent` — fully specified, ready for an AFK agent
-- `ready-for-human` — needs human implementation
-- `wontfix` — will not be actioned
-
-For a PR, the same states read against the attached code: `ready-for-agent` means a brief is attached and an agent should take the next step on the diff; `ready-for-human` means it's ready for a human to merge.
-
-Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
-
-These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `$setup-matt-pocock-skills` if not.
-
-State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
-
-## Invocation
-
-The maintainer invokes `$triage` and describes what they want in natural language. Interpret the request and act. Examples:
-
-- "Show me anything that needs my attention"
-- "Let's look at #42" (issue or PR)
-- "Move #42 to ready-for-agent"
-- "What's ready for agents to pick up?"
-
-## Show what needs attention
-
-Query the issue tracker and present three buckets, oldest first:
-
-1. **Unlabeled** — never triaged.
-2. **`needs-triage`** — evaluation in progress.
-3. **`needs-info` with reporter activity since the last triage notes** — needs re-evaluation.
-
-When PRs are in scope, include external PRs in these buckets and tag each line `[PR]` or `[issue]`. Discovery surfaces only external PRs; a collaborator's in-flight PR is not triage work unless it was named explicitly.
-
-Show counts and a one-line summary per item. Let the maintainer pick.
-
-## Triage a specific issue or PR
-
-1. **Gather context.** Read the full issue or PR (body, comments, labels, author, dates; for a PR, the diff too). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Run two checks against the codebase: redundancy — search for an existing implementation of the requested behavior by domain concept, not just wording, and report where you looked. Prior rejection — read `.out-of-scope/*.md` and surface any prior rejection that resembles this request.
-
-2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the request — including whether it appears already implemented. Wait for direction.
-
-3. **Verify the claim.** Before any grilling, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims — check it out, run the relevant tests or commands. Report what happened: confirmed, failed, or insufficient detail. A confirmed verification makes a much stronger brief.
-
-4. **Grill (if needed).** If the request needs fleshing out, run `$grilling`. It stress-tests the decisions against code and domain docs and records resolved terminology or ADRs inline. Use `$domain-modeling` separately when the task is primarily to establish or repair the domain model.
-
-5. **Apply the outcome:**
-   - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)); include the repo architecture check for code changes.
-   - `ready-for-human` — same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
-   - `needs-info` — post triage notes (template below).
-   - `wontfix` — close, with the comment depending on why:
-     - Already implemented — point to where it lives; do not write to `.out-of-scope/`.
-     - Rejected bug — polite explanation, then close.
-     - Rejected enhancement — write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).
-   - `needs-triage` — apply the role. Optional comment if there's partial progress.
-
-## Quick state override
-
-If the maintainer says "move #42 to ready-for-agent", trust them and apply the role directly. Confirm what you're about to do (role changes, comment, close), then act. Skip grilling. If moving to `ready-for-agent` without a grilling session, ask whether they want to write an agent brief.
-
-## Proportional ready-for-agent policy
-
-When preparing issues for agents, classify the size first, then choose the handoff shape.
-
-Issue size and review risk are independent. A narrow high-risk issue may keep a
-compact brief with stronger proof fields; a broad issue needs separate slices
-only when ownership, release, blockers, or observable behavior differ.
-
-- If several issues describe one deterministic bugfix in the same ownership area, recommend merging them or assigning them as one batch before marking all of them `ready-for-agent`.
-- Agent briefs for narrow fixes should encourage one coherent PR when the code, tests, and verification belong together.
-- For medium/large work, do not compress unrelated workflows into one agent brief. Keep slices separate when they have separate ownership, release sequencing, acceptance criteria, or validation paths.
-- Do not add or imply an implementation-spec requirement unless the issue already has an unresolved `Spec gate` or the acceptance criteria are not deterministic enough for an AFK agent.
-- Live mutation, production repair, or human approval can stay as a separate `ready-for-human` or blocked issue, but only when it truly cannot be verified safely inside the implementation issue.
-- Do not add feature flags, telemetry systems, dashboards, rollout machinery, compatibility paths, or generic fallbacks to make an issue look safer; preserve approved scope.
-
-## Spec-gate policy
-
-Triage does not create implementation specs. When an issue has a `Spec gate`,
-verification contract, or material `Risk / Review` section, preserve its execution metadata in the agent brief and do not expand it into a file-by-file implementation plan. Omit conditional execution fields when they are not material.
-
-## Needs-info template
-
-```markdown
-## Triage Notes
-
-**What we've established so far:**
-
-- point 1
-- point 2
-
-**What we still need from you (@reporter):**
-
-- question 1
-- question 2
-```
-
-Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".
-
-## Resuming a previous session
-
-If prior triage notes exist on the issue or PR, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.

package/internal-workflow/skills/triage/agents/openai.yaml

@@ -1,6 +0,0 @@
-interface:
-  display_name: "Triage"
-  short_description: "Triage raw incoming issues and PRs"
-  default_prompt: "Use $triage to verify, classify, and prepare raw incoming issues or configured external PRs; skip generated planning tickets."
-policy:
-  allow_implicit_invocation: false