---
name: paradevai-triage-issues
description: "Work through the issues Sazabi opened on its own — rank them by severity and blast radius, find each one's cause in this repository with log evidence, and propose or draft one fix per issue, leaving issues open until a fix ships. Use when the user asks what is broken, what to fix first, to clean up or triage Sazabi issues, or for an on-call or morning review."
license: "NOASSERTION"
metadata:
  decimalai-skill-id: "67d86a3f-9c1e-4ebf-8019-d7d2f66d7824"
  decimalai-version-id: "f9d441c7-0686-4101-9ee8-5f8f915def85"
  decimalai-version: "1"
  decimalai-body-sha256: "7e2cf7ddf8b1ab7d718e1a63f8c17ba29abf21dc2cb37fa9d42517e9271d34f8"
  decimalai-name: "paradevai/triage-issues"
  decimalai-format: "1"
  decimalai-invocation: "model"
  decimalai-category: "devops"
  decimalai-source: "https://app.decimal.ai/s/paradevai-triage-issues@1/SKILL.md"
---
# Fix the right issue first

Sazabi opens issues when it sees new or growing errors. A long list is not a
plan. The job is to pick the issues that matter, tie each to code in this
repository with evidence, and leave the user with a short ranked list of fixes.

## 0. How the tools work

The Sazabi MCP server lists only two tools, `search` and `execute`. Browse
Sazabi's operations with `search` and `namespace: "sazabi"` (an empty query
without a namespace lists connected connectors, not Sazabi operations). Before
calling one, repeat `search` with `namespace: "sazabi"`, the hit's full name as
the query, and `includeInputSchema: true` to load its arguments. Then run it
with `execute` as `{ name, arguments }`, the name copied from the hit (for
example `sazabi/logs.ask`).
List open issues with `sazabi/issues.search`; search for other issue operations (reading one issue, changing its status) before assuming they exist.

## 1. Rank before you read

Pull open issues, then rank by impact, not by age or title:

1. Severity Sazabi assigned.
2. Volume now against before: is it growing?
3. Who it hits: customers, a paying tenant, a critical path (sign-in,
   checkout), or an internal job.
4. Whether this repository owns the failing code. Issues in services you don't
   own get a one-line note and a pointer, not an investigation.

Group issues that share a cause; three issues from one bad deploy are one
item.

## 2. One issue at a time, with evidence

For the top few, ask `sazabi/logs.ask` for the failing lines and their
neighbors, find the first frame or log line this repository emits on that
path, and read that code. Check `sazabi/search.threads` for an earlier
investigation before starting over.

Name one cause per issue, and say how sure you are. "Unknown, here is what
would tell us" is a valid finding.

## 3. Propose fixes, don't hide issues

For each issue write: cause, fix, risk, and how to verify it after deploy. Draft
the code change if the user asked. Leave issues open until the fix is live and
the errors have stopped; closing an issue to make the list shorter erases the
signal that would catch a regression.

## 4. Report

A ranked list: issue, impact, cause, proposed fix, confidence. Put anything
that needs a human decision (data repair, customer contact) at the top.

## Anti-patterns

- **Triage by title.** Two issues with one message can be two bugs; two
  messages can be one bug.
- **Fixing the noisiest issue.** Volume is not impact; a quiet failure in
  checkout beats a loud retry warning.
- **Resolving without a shipped fix.**