Triage issues with an agent

A captured error already names the files that broke. Tiden also knows which requirements those files implement and which tests cover them. This workflow hands all of that to a coding agent so it can fix the error and close the coverage gap that let the error escape.

Before you start:

• Error tracking is connected and receiving events. See Connect error tracking.
• The CLI is authorized and the repository is bound to a product. See Set up the CLI.

1. Install the triage skill

tiden skill install triage-issues

The skill teaches the agent the whole loop below — which command to run at each step, how to rank issues, and when it is allowed to resolve one. Install it into the current repository instead of your home directory with --local:

tiden skill install triage-issues --local

Confirm it is present:

tiden skill list --format text

Then start the agent in the repository and ask it to triage issues. Agents that speak MCP can use the same data through tiden-mcp-server instead of the CLI.

2. Point the agent at an environment

An issue has no environment of its own — its occurrences do. Scope the work to the environment you actually care about:

tiden issue list \
  --environment production \
  --status unresolved \
  --sort times_seen \
  --period 7d

--environment, --release, and --component accept names as well as IDs, so production works without looking anything up.

Rank what comes back by impact (timesSeen), recency (lastSeen), and regression. A non-empty regressedAt means Tiden reopened an issue that had been resolved — the fix did not hold, and that belongs at the top of the list.

3. Read the fix context

This is the call that turns an error into a plan:

tiden issue fix-context <issue-id>

It returns, in one response:

Field	What to do with it
suspectPaths	The repository files the stack trace implicates, in stack order. Open these first.
suspectRequirements	The requirements those files implement, each with the paths that matched it, so a wrong match is visible rather than silent.
coverage	verified, not_run, or no_test for each suspect requirement.
environments	Occurrence counts per environment — a production outage versus dev noise.
component	The component the error was attributed to.
regressed	true when this issue was resolved and came back.
truncationSignals	Names anything left out to keep the response bounded.

Use --branch to resolve requirements against a branch instead of main, and --max-frames to widen or narrow the stack window.

Raw event payloads are omitted throughout the issue commands. Symbolicated stack frames — the part that localizes the bug — are always included. Pass --payload to issue get, issue events, or issue event only if the frames were not enough, and never copy secrets or personal data out of a payload into code, commits, or requirements.

4. Fix the code

Have the agent change the files in suspectPaths. The linked requirements are the specification the broken code was meant to satisfy — read them for the intended behavior before changing it.

5. Add the missing test

If a suspect requirement's coverage is no_test or not_run, that gap is why the error reached production. Fixing only the code leaves the gap open.

Write the regression test, then link it to the requirement so the coverage verdict and the quality gate both see it:

tiden test link-requirement <test-id> --requirement-id <requirement-id>

On a non-main branch this creates a link proposal to review before merge. See Manage branches.

6. Resolve the issue

tiden issue resolve <issue-id>

tiden issue ignore is for issues that are expected and not actionable. tiden issue reopen undoes either. Every status change records who made it, so an agent's decisions stay attributable and reversible — but only resolve an issue that was actually fixed and verified.

Several issues at once:

tiden issue resolve <issue-id> <issue-id> --product-id <product-id>

7. Verify after the next release

A fix is proven by the next release, not by the commit. After the fix ships:

tiden release issues <release-version>

This lists the issues first seen in that release. The issue you resolved should not appear, and no new issue should have taken its place. If it does reappear, Tiden marks it as a regression and it re-enters the loop at step 3.

Finish with the gate before promoting:

tiden gate check --product-id <product-id>