CI Failure Triage

When a coding agent's pull request fails its CI checks, CI Failure Triage reads the failed GitHub Actions logs for you and posts a plain-language root-cause hypothesis as a comment on the linked task — automatically, usually within a minute.

It turns the first step of almost every debugging session ("open GitHub Actions, scroll the logs, figure out what broke") into something that's already waiting for you when you open the ticket.

This is an autonomous agent: nobody has to ask it. It reacts to the CI failure event on its own.

What it looks like

Say @claude opens a PR for one of your tasks and the build fails. Shortly after, a comment like this appears on the task:

🔧 CI failure — triage (run)

The cargo check step failed because TeamIssue is missing the duplicate_candidates field in two initializers (db/sprints.rs, db/releases.rs). Most likely a new struct field was added without updating every constructor. Next check: search for TeamIssue { across the crate and confirm each initializer sets the new field.

Automated first-pass triage from the failed job log — a hypothesis, not a verdict.

You stay in control — it's a suggestion, not an action. It never changes code, re-runs anything, or closes the task.

Before you start

Three things need to be in place for a task to get triaged:

Your GitHub account is connected to iKanban. Connecting GitHub already grants iKanban repository access, which is what lets it read your Actions logs — nothing extra to enable. (Settings → GitHub, or Team → GitHub.)
An AI provider key is configured for your workspace — Anthropic, OpenAI, or Google. The agent uses whichever you've set up. (Settings → AI Provider Keys.) Without a key, triage silently does nothing.
The PR was opened by a coding agent (@claude, @copilot, or @gemini) on an iKanban task. That's how iKanban knows which task to comment on. (Pushes with no linked PR aren't triaged — see Limits.)

Setup — there's nothing to configure

If the three things above are in place, CI Failure Triage just works — there's no permission to grant, no app to install, and no setting to flip. iKanban watches your tracked agent PRs in the background and, when one's checks go red, posts the triage comment on its own.

How it notices: iKanban checks your in-flight agent PRs roughly every 30 seconds (the same mechanism that keeps the Agent Activity card in sync), so a triage comment typically lands within a minute of the run failing — not instantly.

How to verify it's working

The quickest end-to-end check:

Open a task and assign it to a coding agent (e.g. comment @claude please fix …).
Let the agent open its PR, and let CI run and fail (a real failing check).
Within a minute or so of the run finishing, refresh the task — a "🔧 CI failure — triage" comment should appear.

If the PR's checks pass, there's nothing to triage and no comment is posted — that's expected.

Troubleshooting

No triage comment appeared after a failed run. Work through these in order:

Symptom	Likely cause	Fix
Nothing ever appears, on any repo	GitHub isn't connected (or the connection lost repo access)	Reconnect GitHub in Settings → GitHub
Appears for some tasks but not others	The person who triggered the agent hasn't connected their GitHub	Triage reads logs with the triggering user's GitHub connection — that user connects GitHub
Failed run had no linked PR	Push-to-branch or a non-PR workflow	Only PR-linked agent runs are triaged (see Limits)
PR wasn't opened by an agent	No linked iKanban task to comment on	Trigger the work via `@claude`/`@copilot`/`@gemini`
Workspace has no AI provider key	The agent can't call a model	Add a key in Settings → AI Provider Keys

The agent is fail-quiet by design: if it can't fetch the log or reach a model, it does nothing rather than posting noise. So "no comment" is always one of the rows above — never a crash.

Good to know / limits

Suggestions only. It posts a hypothesis. It never edits code, re-runs CI, reopens, or closes anything.
First failed job only. It reads the first failing job's log (tailed to the relevant portion) — enough for a focused root cause, not a full transcript.
PR-linked runs only (for now). Runs without an associated pull request — for example a push straight to main — aren't mapped to a task, so they aren't triaged.
It's not tied to one agent. Whether the PR came from @claude, @copilot, or @gemini, a failed check on its linked PR gets the same triage — no per-agent setup. (It applies to PRs iKanban is tracking, i.e. agent-triggered work.) See Coding Agents and the Agent Lifecycle.
It uses your own AI key, so the model and cost are under your control — same provider you picked in Settings → AI Provider Keys.

CI Failure Triage is part of iKanban's wider goal: a project tool for teams where agents do real work, with the board doing the watching so you don't have to. Pair it with duplicate detection at intake and the Agent Lifecycle view for a board that surfaces problems before you go looking for them.