codex-orchestrator 0.1.51 → 2.0.1

package/prompts/workflows/triage.md

@@ -1,149 +0,0 @@
-# Triage Workflow
-
-Move issues through a small issue-tracker triage state machine. Every comment or issue posted during triage must start with:
-
-```markdown
-> *This was generated by AI during triage.*
-```
-
-Use the repository's configured label vocabulary. The canonical roles are below; actual labels may differ by repo policy.
-
-## Roles
-
-Category roles:
-
-- `bug`: something is broken.
-- `enhancement`: new feature or improvement.
-
-State roles:
-
-- `needs-triage`: maintainer needs to evaluate.
-- `needs-info`: waiting on reporter information.
-- `ready-for-agent`: fully specified, ready for AFK agent work.
-- `ready-for-human`: needs human implementation or decision.
-- `wontfix`: will not be actioned.
-
-Every triaged issue should carry exactly one category role and one state role. If state roles conflict, stop and ask the maintainer before changing the issue.
-
-## Needs Attention View
-
-When asked what needs attention, show three buckets, oldest first:
-
-1. Unlabeled issues.
-2. Issues in `needs-triage`.
-3. Issues in `needs-info` with reporter activity since the last triage note.
-
-Show counts and one-line summaries, then let the maintainer choose.
-
-## Triage A Specific Issue
-
-1. Gather context: read the full issue body, comments, labels, reporter, and dates.
-2. Parse prior triage notes to avoid re-asking answered questions.
-3. Explore relevant repo context using domain glossary terms and ADRs.
-4. Read `.out-of-scope/*.md` if present and surface matching prior rejections.
-5. Recommend a category and state with reasoning and a short codebase summary.
-6. For bugs, attempt reproduction before final recommendation: trace code, run focused tests or commands, and report successful repro, failed repro, or insufficient detail.
-7. If the issue needs fleshing out, run a grilling or clarification pass before marking it ready.
-8. Apply the outcome only after the requested action is clear.
-
-## Outcomes
-
-- `ready-for-agent`: post an Agent Brief comment and apply the mapped role.
-- `ready-for-human`: post an Agent Brief-style comment that explains why human work is required.
-- `needs-info`: post triage notes with established facts and specific reporter questions.
-- `wontfix` bug: post a polite explanation and close.
-- `wontfix` enhancement: create or update `.out-of-scope/<concept>.md`, link it from a comment, then close.
-- `needs-triage`: apply the role; comment only if useful.
-
-## Agent Brief
-
-An Agent Brief is the durable contract an AFK agent will work from. The original issue and discussion are context; the brief is the current specification.
-
-Write briefs that are durable, behavioral, complete, and scoped. Avoid file paths and line numbers. Name interfaces, types, commands, contracts, config shapes, and observable behavior when useful.
-
-Template:
-
-```markdown
-## Agent Brief
-
-**Category:** bug / enhancement
-**Summary:** one-line description
-
-**Current behavior:**
-Describe what happens now.
-
-**Desired behavior:**
-Describe what should happen, including edge cases and error conditions.
-
-**Key interfaces:**
-- Interface or contract name - what needs to change and why
-- Config shape or command - expected behavior
-
-**Proof strategy:**
-Proof Strategy: auto / visual / browser-visual / mobile-visual / non-visual-smoke / none
-
-Choose the explicit strategy from the acceptance criteria:
-- `non-visual-smoke` for backend, CLI, telemetry, analytics, event dispatch, data, or logging work where tests, command output, logs, API responses, or machine-readable artifacts prove behavior better than screenshots.
-- `browser-visual` for web UI/layout/copy/responsive work.
-- `mobile-visual` for Android/iOS/Flutter UI behavior where device-backed launch, screenshot, UI dump, or logs are the proof surface.
-- `visual` when visual proof is required but browser vs mobile should be selected from changed paths.
-- `none` only when normal tests/checks are sufficient and no extra acceptance proof artifacts are required.
-- `auto` when no stronger explicit choice is known.
-
-**Acceptance criteria:**
-- [ ] Specific, testable criterion
-- [ ] Specific, testable criterion
-- [ ] Specific, testable criterion
-
-**Out of scope:**
-- Adjacent thing not included
-- Risky interpretation not allowed
-```
-
-## Needs-Info Template
-
-```markdown
-## Triage Notes
-
-**What we've established so far:**
-
-- fact 1
-- fact 2
-
-**What we still need from you (@reporter):**
-
-- specific question 1
-- specific question 2
-```
-
-Capture resolved facts under "established so far" so the work is not lost. Questions must be specific and actionable.
-
-## Out-Of-Scope Knowledge Base
-
-The `.out-of-scope/` directory stores durable records of rejected enhancement requests. One file should represent one concept, not one issue.
-
-File shape:
-
-```markdown
-# Concept Name
-
-## Why this is out of scope
-
-Durable reason, including project scope, architectural constraints, or strategic decision.
-
-## Prior requests
-
-- #123 - Request title
-```
-
-During triage, check existing out-of-scope records by concept similarity. If a new issue matches a prior rejection, surface it and ask whether the maintainer wants to confirm, reconsider, or proceed as distinct.
-
-Only write `.out-of-scope/` records for rejected enhancements, not bugs.
-
-## Quick State Override
-
-If the maintainer explicitly says to move an issue to a state, trust them. Confirm the exact label/comment/close action, then apply it. If moving to `ready-for-agent` without a grilling session, ask whether they want an Agent Brief written.
-
-## Spec Gate Policy
-
-Triage does not create implementation specs. When an issue has a `Spec gate` section, preserve it in the Agent Brief and do not expand it into a file-by-file implementation plan.