Scope
This skill owns evidence-based classification. The repo contract/overlay owns reproduction commands, expected failures, issue conventions and warning severity. Triage does not authorize code publication, reverts, issue/comments or mentions. Load pr-lifecycle when repair changes an authorized PR.
Prerequisites
Identify the run, workflow, exact tested SHA and event. For PRs distinguish the head from the tested merge preview. Use harness-operations when retrieving checks/logs requires a capability mapping. Authentication and log availability must be observed; do not assume all connectors expose the same fields or limitations.
Procedure
- Read run/job status, first failed step and bounded logs through the available GitHub tools. Redact credentials and personal data. If logs are unavailable, retain the status/configuration evidence and report the access limit.
- Compare the tested diff with the previous comparable run, including workflow, inputs, dependencies and environment. An earlier green commit alone does not establish a flake or prove causation. Identify a suspect change with evidence; do not blame an author from the merge-message shape alone.
- Reproduce in an authorized isolated checkout at the exact tested ref or merge result using its own gate commands and fixtures. Do not switch a parked primary checkout to the suspect branch. Browser failures use the repo's browser workflow; another product's routes or fixtures are not interchangeable.
- Classify with the following taxonomy. Missing logs, credentials, tooling or a reproducible environment limit confidence; report them rather than guessing.
- Follow the repo's issue convention only when authorized. If it uses a rolling main-red issue, search for an existing open tracker before creating one. Append concise evidence instead of opening duplicates. Do not notify people merely because a template contains a mention. Close a tracker only with authority and a cited green run for the affected workflow.
- For a repair, hand off to the repo workflow and pre-push/PR lifecycle. For a retry, retain the failed run and compare the same tested inputs. A green retry alone does not justify weakening a required assertion.
Classification
| Bucket | Evidence | Next action |
|---|---|---|
| regression | Deterministic failure tied to the tested change or its merged interaction | Reproduce and repair the demonstrated defect |
| flake | Same comparable inputs alternate outcomes, with evidence of a nondeterministic cause | Record/retry and address the cause |
| infra | Runner, service, network or dependency provisioning failed independently of product assertions | Repair/retry the environment |
| needs-human | Evidence or authority is insufficient for a reliable diagnosis | Gather available evidence; request any pending human decision through the structured question capability in harness-operations |
If a human must choose the next action or supply missing context, use the structured question capability in harness-operations, then wait before dependent work. A plain-text needs-human report alone does not request that decision when the tool is available. If unavailable, state the limitation and use the established handoff channel. Missing infrastructure alone does not require a human choice.
Completion
Report workflow/run URL, tested SHA, first failing step, bucket, confidence, reproduction result, bounded evidence and next action. A blocked reproduction is not a successful local check. Keep check status tied to the exact SHA.