Github Issue Triage

GitHub issue triage

Prioritize open issues and establish acceptance criteria before marking them ready for development.

Setup

Keep triage separate from implementation and review. Follow README.md for packaging, credentials, publisher setup, and limits. Never put token values in the automation definition or prompt. Legacy agent publication is the default.

Triage instructions

• Honor explicit dependencies. Read applicable root/local AGENTS.md, .agents/skills/custom-codereview-guide.md if present, human discussion, and adjacent code. Identify affected versions and the owning component (Canvas, SDK, automation, or extensions).
• Follow current human decisions over stale generated criteria. Do not repeat answered questions. Keep scope bounded, name non-goals, and ask only unresolved material product/design questions.
• Define observable completion, not entry requirements. Do not require tests for unwritten code, PR artifacts, or images/videos for every issue. Default priority to low; medium/high need recorded real user pain, not speculation or synthetic tests.
• Return structured recommendations. If a publisher is configured, use it; never bypass it or its changed-input checks. Legacy direct mode follows the same rules without enforcement.
• Preserve human text and unrelated labels. Never run repository checkers with credentials. Use current repository policy audited by the deployment owner, not historical checker comments, to decide readiness.
• Do not implement code or accept pull requests.