SentryFixer.Skill

sentry-fixer

A Claude Code skill that turns a Sentry issue into a reviewed, approved fix — never the other way around.

What it does

Given a Sentry issue (a URL, a short id like PROJ-4F2, or a numeric id), the skill:

1. Detects which access tier is available (sentry-cli, an API token, or a Sentry MCP server).
2. Fetches the issue and its latest event, and compresses the raw 50–300 KB payload into a short, redacted Markdown summary.
3. Checks that the issue's Sentry project is the one this working tree builds — and stops to ask if it can't tell, rather than analyzing the wrong repo. In a multi-project org, a frame from another service will often resolve to a same-named file here and look like a clean match.
4. Maps every in-app stacktrace frame onto a file in your current working tree.
5. Checks whether the failing code has already changed since the event was captured (current / changed / unknown), before reasoning about the cause — a theory about code that's since moved on isn't a theory about the bug in front of you.
6. Reads the actual source at each frame, reasons about root cause, and writes a fix plan (root cause, blast radius, exact diffs, a named regression test, and the verification command).
7. Stops and waits for your explicit approval of that plan.
8. Only after approval: applies the changes, adds the regression test, runs your test command, and reports the result honestly — pass or fail.

One issue is analyzed and fixed per run. The triage/regression/path modes below exist to help you pick which issue, not to fix several at once.

What it does not do

• Never writes to Sentry. Every call is a GET. Nothing resolves, assigns, mutes, or comments on an issue.
• Never runs any git operation beyond read-only history (git log, git diff, git cat-file, used only for the stale-code check). It does not commit, branch, or push — that stays your call, outside the skill.
• Never edits a file — anywhere in the working tree — before you explicitly approve the plan. This is unconditional: no confidence threshold, no exception for a one-line fix.

Requirements

• Python 3.8+ — standard library only, no extra packages. The script resolves an interpreter by running one, trying python3, then python, then py (the Windows launcher), and keeping the first that reports 3.8 or newer. Set SENTRY_PYTHON to skip the search and name the interpreter yourself.
  • On Windows: the python3 on PATH is very often not Python. %LOCALAPPDATA%\Microsoft\WindowsApps\python3 ships as a Microsoft Store app execution alias — it's on PATH out of the box, it satisfies command -v, and every invocation prints "Python was not found" and exits 49. A python.org install, meanwhile, ships python.exe and no python3.exe. The fallback chain above handles both; if none of the three names works you get exit 4 with a message saying so, never the stub's 49.
• curl — no minimum version. The script reads the HTTP status through --write-out rather than --fail-with-body (which needs curl 7.76+, newer than RHEL 8, Ubuntu 20.04, or macOS 11 ship). Verified end-to-end on curl 7.68.0 and 8.7.1.
• One of the three access options below.

There is deliberately no jq dependency — all JSON handling goes through python3.

Setting up access

Pick one; all three are read-only from the skill's side.

1. Auth token. In Sentry: Settings → Auth Tokens → Create New Token, with scopes event:read, project:read, and org:read. The short-id lookup (GET /organizations/{org}/shortids/{short_id}/) is a plain OrganizationEndpoint, whose default GET permission is org:read — without it, resolving a short id like SHOP-4F2 returns a 403. Then either:

export SENTRY_AUTH_TOKEN=<token>
export SENTRY_ORG=<org-slug>
export SENTRY_PROJECT=<project-slug>

or write it to ~/.sentryclirc:

[auth]
token=<token>

[defaults]
org=<org-slug>
project=<project-slug>

A repo-local ./.sentryclirc works too — the same file sentry-cli picks up per repo. ~/.sentryclirc is checked first, so a repo can supply the org/project/token you haven't set yourself, but can't override one you have.

2. sentry-cli. Install sentry-cli, run sentry-cli login (writes the token into ~/.sentryclirc for you), and confirm with sentry-cli info. Note: even on this tier, issue and event detail are fetched over the same REST API as tier 1, using the token sentry-cli login wrote — sentry-cli's own subcommands don't return a stacktrace or breadcrumbs, so there's nothing to shell out to for those calls.

3. Sentry MCP server. Add a Sentry MCP server to your session (however your client registers MCP servers). The skill discovers its tools by purpose at runtime — it doesn't hardcode tool names, since the Sentry MCP server's tool set has changed between versions.

Self-hosted Sentry

Either export it:

export SENTRY_URL=https://sentry.internal.example.com

…or put it in the same config file that already holds the token and org — sentry-cli reads [defaults] url too, so a self-hosted setup is one file:

[auth]
token=<token>

[defaults]
org=<org-slug>
url=https://sentry.internal.example.com

Resolution order is SENTRY_URL → ~/.sentryclirc → ./.sentryclirc → sentry.properties (defaults.url) → https://sentry.io. Env wins, and $HOME beats the repo-local file, so a checked-out repo can supply a URL you never set but can't redirect one you did.

Don't include /api/0 — the skill appends it itself, and strips any trailing slash.

Install

# Plugin
/plugin marketplace add muhammetsafak/SentryFixer.Skill
/plugin install sentry-fixer

# Manual
git clone https://github.com/muhammetsafak/SentryFixer.Skill.git
cp -r SentryFixer.Skill/skills/sentry-fixer ~/.claude/skills/

The four modes

Mode	Example prompt
Single issue	"Fix SHOP-4F2" or paste a Sentry issue URL
Triage	"What's breaking in production right now?"
Regression	"Anything new since we shipped v2.4.0?"
Path	"Any recent errors in src/payment?"

Triage, regression, and path all end in you picking one issue from a presented table, then converge on the single-issue flow. Every such table names the project each row came from, since results can span services.

Those three modes list issues through sentry.sh list, which queries Sentry's organization issue index:

• Scope. --project all for the whole org, --project <slug> (or a comma-separated list of slugs and/or numeric ids) for a subset. With no flag it uses your configured project if you have one, and the whole org if you don't — so a single-project setup behaves exactly as before, and a multi-project org that deliberately pins nothing gets all of it instead of an error. Slugs are resolved to numeric ids through one extra GET /organizations/{org}/projects/, because the endpoint rejects slugs with HTTP 400.
• Period. Any <number><unit> duration works — 24h, 7d, 90d. An empty period is rejected (exit 64): this endpoint answers 400 Invalid statsPeriod: '', unlike the per-project index, which read empty as "stats window disabled". The script validates the shape but not the range, so an out-of-range duration comes back as Sentry's own 400 rather than a guess about the current limit.

Multi-project orgs

project is optional everywhere. Every endpoint the skill uses is org-scoped, so leaving SENTRY_PROJECT / defaults.project unset is a valid configuration, not an incomplete one — you'll never be asked to pin a project you deliberately left unpinned.

The one thing the skill will ask about is which repo it's in. Before mapping any stacktrace frame, it compares the issue's project against your checkout and stops if it can't confirm they're the same. That check matters most exactly where it's least visible: with two services checked out side by side, a frame like /var/www/html/app/Exceptions/Handler.php from service B falls through every deploy-root prefix, gets basename-searched in service A, matches the single Handler.php there — and the whole analysis proceeds confidently against code that never ran.

Worked example

Fix SHOP-4F2

(fetches the issue and its latest event, pipes the event through summarize_event.py)

This is what the summarizer itself emits — no working-tree paths, no freshness verdict, no fix, because it doesn't know about any of those; it only compresses the raw event JSON. The block below is the unedited, byte-for-byte output of:

python3 skills/sentry-fixer/scripts/summarize_event.py \
  --issue tests/fixtures/issue.json < tests/fixtures/event-js.json

# TypeError: Cannot read properties of undefined (reading 'total')

- **Issue:** SHOP-4F2 (id 5512340987)
- **Project:** shop-frontend
- **Culprit:** applyDiscount(src/checkout/cart)
- **Level:** error | **Platform:** javascript
- **Release:** frontend@1.4.2+a3f21c9 | **Environment:** production
- **Impact:** 1843 events, 612 users
- **Seen:** first 2026-07-18T22:03:00.000Z, last 2026-07-20T10:11:12.000Z
- **This event:** 8f2c1a9b4d5e4f7a8b9c0d1e2f3a4b5c at 2026-07-20T10:11:12.000Z
- **Link:** https://shop-org.sentry.io/issues/5512340987/

## Exception chain

### Raised: TypeError

> Cannot read properties of undefined (reading 'total')

_mechanism: onerror, handled: False_

**In-app frames** (most relevant last, as Sentry orders them):

- `app:///src/checkout/cart.js:88` in **applyDiscount**
  ```
    86 | export function applyDiscount(order, code) {
    87 |   const rule = DISCOUNTS[code];
  > 88 |   return order.summary.total * (1 - rule.rate);
    89 | }
  ```

**Vendor frames** (1):

- `node_modules/react-dom/cjs/react-dom.production.min.js:188` in **invokeGuardedCallback**

## Breadcrumbs (newest first)

- `ui.click` **info** — button#apply-discount
- `auth` **warning** — stale credentials: Bearer [redacted:token] / [redacted:jwt] and leaked [redacted:secret]
- `http` **info** — GET /api/orders/4821 [200]
- `retry` **warning** — retry for [redacted:email] from [redacted:ip]
- `navigation` **info** — /cart -> /checkout

## Request

- POST https://shop.example.com/checkout
- Headers:
  - `Authorization`: [redacted:authorization]
  - `Cookie`: [redacted:cookie]
  - `User-Agent`: Mozilla/5.0
- Body: `{"code": "SUMMER26", "email": "[redacted:email]", "session": false}`
- Cookies: `"[redacted:cookies]"`

## Context

- **browser:** Chrome 126.0.0
- **os:** Mac OS X 14.5
- **User:** {"id": "4821", "email": "[redacted:email]", "username": "[redacted:username]", "ip_address": "[redacted:ip_address]", "ssn": "[redacted:ssn]"}
- **Tags:** `environment=production`, `release=frontend@1.4.2+a3f21c9`, `transaction=/checkout`, `trace=[redacted:hex]`

Everything from here on is the skill's own work (steps 4 onward), not the summarizer's:

• Mapped to src/checkout/cart.js — the frame's reported path, app:///src/checkout/cart.js, resolved via prefix 1 (stripping app:///) against a file that exists in the working tree.
• Code freshness: current — no commits touch src/checkout/cart.js since the release recorded on this event (frontend@1.4.2+a3f21c9).

(reads src/checkout/cart.js in full, walks the breadcrumb trail, reasons about root cause)

Fix plan: SHOP-4F2 — TypeError: Cannot read properties of undefined (reading 'total')

Root cause: applyDiscount (src/checkout/cart.js:88) dereferences order.summary.total with no guard for order.summary being absent. The breadcrumb trail rules out a fetch-still-in-flight race: the order fetch (GET /api/orders/4821, 200) completed before the apply-discount click, not after — so by the time applyDiscount runs, the fetch had already succeeded. Two hypotheses fit the remaining evidence and this event alone doesn't distinguish them:

1. The fetched order genuinely has no summary in this state (e.g. an order with no priced items yet), and nothing gates the discount button on that.
2. The order value applyDiscount reads is a separate, stale reference that predates the fetch, and the fetched result never reached it.

Code freshness: current — no commits touch this file since the event's release.

Blast radius: 1843 events, 612 users, first seen 2026-07-18, last seen 2026-07-20, environment production.

Changes

1. src/checkout/cart.js:88

- return order.summary.total * (1 - rule.rate);
+ return (order.summary?.total ?? 0) * (1 - rule.rate);

Regression test

File: tests/checkout/cart.test.js Asserts: applyDiscount returns 0 instead of throwing when order.summary is undefined.

Verification

npm test

Risks

• This guards the symptom under both hypotheses above but doesn't distinguish them. If hypothesis 2 (stale reference) is right, the discount silently comes back 0 instead of crashing — worth a follow-up issue tracing how order reaches the click handler.

Approve this plan?

yes

(applies the diff, adds the test, runs npm test, reports pass/fail)

Nothing is written to disk until you type something like "yes" to that last question.

Privacy

Redaction is on by default; pass --no-redact to the summarizer to turn it off.

What redaction actually covers: known-sensitive keys (email, username, ip_address, password, token, authorization, cookies, ssn, and similar — the whole value under one of these keys is dropped regardless of its shape), and known credential/PII shapes anywhere else in the payload — email addresses, bearer tokens, JWTs, sk_/pk_/rk_-style secret literals, long hex strings, and IPv4 addresses.

Sentry tags count as keys here: a password tag is dropped by its tag name, whatever its value happens to look like. Custom tags are the main way an application attaches its own identifiers to an event, so this is where a key-based rule earns its keep.

There are exactly two exemptions, and both are narrow. Identifier fields (id, eventID, groupId, …) and release fields (version, release, dist) are skipped by the long-hex rule only — an event id and a full 40-character commit SHA are both long hex strings, and the summary is useless without the first while the stale-code check is disabled without the second. Every other shape rule still runs on them, so an email in user.id (a very common Sentry.setUser({ id }) configuration) is still redacted.

What it does not cover: arbitrary personal data sitting in free text — a customer's name or phone number typed into a breadcrumb message or an exception's own text, for instance, matches none of the above and passes through untouched.

The raw event is fetched into a scratch directory outside your working tree (mode 0700), never into the repo, and is deleted when the run ends — only the redacted summary is read into the conversation.

Treat --no-redact output as unsafe to share under any circumstances. Treat default (redacted) output as reduced risk, not as guaranteed PII-free — it can still carry incidental personal data the redaction layer has no way to recognize. Don't paste either into a public place on the strength of this section.

Troubleshooting

scripts/sentry.sh exit codes:

Exit	Meaning	What to do
0	OK	—
3	No backend available (detect), or no token found when a data command needed one	Set up one of the three access options above, or check for a Sentry MCP server in your session. Don't retry silently.
4	No usable Python 3.8+ interpreter — none of python3, python, py runs and reports 3.8 or newer	Install Python 3.8+ from python.org, or point SENTRY_PYTHON at an existing one. On Windows, this exit usually means the only python3 on PATH is the Microsoft Store stub. Nothing in this workflow can proceed without an interpreter.
5	The request failed — curl itself failed, or the response was non-2xx	Read the stderr message — Sentry's own response body is printed above it and names the actual problem (missing scope on a 403, bad parameter on a 400). Don't retry silently.
6	The reference resolved to no issue id, including an unknown short id — on the short-id lookup path, this exit also absorbs a 403, 400, 5xx, network failure, or validation rejection, the same conditions that report 5 or 64 on the numeric-id path	Check the id, short id, or URL — a typo or the wrong org is the usual cause, but the actual error is always printed on stderr immediately above; don't assume a typo without reading it first.
64	Usage or validation error (bad/missing flag value, unresolved org/project, an unparseable reference, or a rejected character)	The stderr message names exactly what was wrong; fix that input.
130	Interrupted (SIGINT)	The call was cancelled.
143	Terminated (SIGTERM)	The process was terminated externally.

Sponsor

If this saves you time, you can support the work through GitHub Sponsors.

License

MIT. See LICENSE.

---

Türkçe

sentry-fixer, bir Sentry issue'sunu onaylanmış bir düzeltmeye dönüştüren bir Claude Code skill'idir — hiçbir zaman tersi değil.

Ne yapar: Bir Sentry issue verildiğinde (URL, PROJ-4F2 gibi kısa id, ya da numeric id), skill sırasıyla: erişim katmanını tespit eder; issue ile son event'i çeker ve ham 50–300 KB'lık veriyi kısa, redakte edilmiş bir Markdown özetine indirger; issue'nun ait olduğu Sentry project'inin bu çalışma ağacının derlediği project olup olmadığını doğrular ve emin olamıyorsa durup sorar (çok project'li bir org'da başka bir servisin frame'i burada aynı adlı bir dosyaya eşleşir ve temiz bir sonuç gibi görünür); stacktrace'teki her in-app frame'i mevcut çalışma ağacındaki bir dosyaya eşler; kök neden hakkında düşünmeden önce o kodun event'ten bu yana değişip değişmediğini kontrol eder (current / changed / unknown); her frame'deki gerçek kaynağı okuyup kök nedeni açıklayan ve tam diff'ler, adlandırılmış bir regresyon testi ile doğrulama komutu içeren bir düzeltme planı yazar; planı sunup açık onayınızı bekler; onaydan sonra değişiklikleri uygular, regresyon testini ekler, proje testini çalıştırır ve sonucu — geçti ya da geçmedi — olduğu gibi bildirir. Tek bir çalıştırmada tek bir issue analiz edilip düzeltilir; triage/regression/path modları hangi issue'nun ele alınacağını seçmek içindir, birden fazlasını tek seferde düzeltmek için değildir.

Ne yapmaz:

• Sentry'ye asla yazmaz. Her çağrı bir GET'tir; hiçbir issue çözülmez, atanmaz, susturulmaz ya da yorumlanmaz.
• Salt-okunur geçmiş dışında hiçbir git işlemi yapmaz (git log, git diff, git cat-file — yalnızca eskime kontrolü için); commit, branch ya da push işlemi yapmaz, bu her zaman sizin kararınızdır.
• Siz planı açıkça onaylamadan çalışma ağacında hiçbir dosyayı — hiçbir yerde — oluşturmaz, değiştirmez ya da silmez. Bu koşulsuzdur: güven eşiği yoktur, "tek satırlık bariz düzeltme" istisnası yoktur.

Gereksinimler: Python 3.8+ (yalnızca standart kütüphane), curl, ve aşağıdaki üç erişim seçeneğinden biri. Kasıtlı olarak jq bağımlılığı yoktur — tüm JSON işleme Python üzerinden yapılır. Yorumlayıcı, adının var olup olmadığına değil çalışıp çalışmadığına bakılarak seçilir: sırayla python3, python, py (Windows launcher) denenir ve 3.8+ raporlayan ilki kullanılır; SENTRY_PYTHON ile aramayı atlayıp yorumlayıcıyı kendiniz verebilirsiniz. Windows'ta önemli: PATH'teki python3 çoğu zaman Python değildir — %LOCALAPPDATA%\Microsoft\WindowsApps\python3 varsayılan olarak gelen bir Microsoft Store app execution alias'tır, command -v testini geçer ama her çağrıda "Python was not found" yazıp 49 ile çıkar; python.org kurulumu ise python.exe sağlar, python3.exe sağlamaz. Yukarıdaki zincir her iki durumu da karşılar.

Erişim kurulumu:

1. Auth token — Sentry'de Settings → Auth Tokens → Create New Token, kapsamlar event:read, project:read ve org:read (kısa id çözümlemesi, GET /organizations/{org}/shortids/{short_id}/, bir OrganizationEndpoint'tir ve GET için varsayılan olarak org:read gerektirir — bu kapsam olmadan SHOP-4F2 gibi bir kısa id 403 ile döner). SENTRY_AUTH_TOKEN (+ SENTRY_ORG/SENTRY_PROJECT) ortam değişkeni olarak ayarlayın ya da ~/.sentryclirc dosyasına yazın.
2. sentry-cli — kurun, sentry-cli login çalıştırın, sentry-cli info ile doğrulayın. Bu katmanda bile issue/event detayları aynı REST API üzerinden, sentry-cli login'in yazdığı token ile çekilir.
3. Sentry MCP sunucusu — oturumunuza ekleyin; skill, araçları isme göre değil amaca göre çalışma zamanında keşfeder.

Self-hosted Sentry için: SENTRY_URL=https://sentry.internal.example.com (sonunda /api/0 olmadan; script kendisi ekler). Ortam değişkeni yerine, token ve org'un zaten durduğu config dosyasına [defaults] url olarak da yazabilirsiniz — sentry-cli de aynı anahtarı okur, böylece self-hosted bir kurulum tek dosyayla tarif edilir. Çözümleme sırası: SENTRY_URL → ~/.sentryclirc → ./.sentryclirc → sentry.properties (defaults.url) → https://sentry.io. Ortam değişkeni kazanır; $HOME repo-local dosyayı yener, yani bir repo sizin hiç ayarlamadığınız URL'yi sağlayabilir ama ayarladığınızı yeniden yönlendiremez.

Kurulum:

# Plugin
/plugin marketplace add muhammetsafak/SentryFixer.Skill
/plugin install sentry-fixer

# Manuel
git clone https://github.com/muhammetsafak/SentryFixer.Skill.git
cp -r SentryFixer.Skill/skills/sentry-fixer ~/.claude/skills/

Dört mod: Single issue ("Fix SHOP-4F2"), Triage ("Production'da şu an neler kırılıyor?"), Regression ("v2.4.0'dan beri yeni bir şey var mı?"), Path ("src/payment içinde son hatalar?"). Triage/regression/path bir tablo sunar, siz birini seçersiniz, ardından single-issue akışına geçilir. Sonuçlar birden fazla servise yayılabildiği için tabloda her satırın hangi project'ten geldiği de yazar.

Çok project'li org'lar: list, Sentry'nin organization issue index'ini kullanır. Kapsam --project all (tüm org), --project <slug> ya da virgülle ayrılmış slug/numeric id listesiyle belirlenir; flag verilmezse yapılandırılmış project varsa o, yoksa tüm org sorgulanır — yani tek project'li bir kurulum aynen eskisi gibi davranır, hiçbir project pinlememiş bir org ise hata yerine tamamını görür. Slug'lar bir ek GET /organizations/{org}/projects/ çağrısıyla numeric id'ye çevrilir, çünkü endpoint slug'ı HTTP 400 ile reddeder. --period her <sayı><birim> süresini kabul eder (24h, 7d, 90d); boş period ise reddedilir (exit 64) — bu endpoint 400 Invalid statsPeriod: '' yanıtı verir, per-project index'in aksine. project her yerde opsiyoneldir: kullanılan tüm endpoint'ler org kapsamlıdır, dolayısıyla SENTRY_PROJECT / defaults.project boş bırakmak eksik değil geçerli bir yapılandırmadır ve skill sizden project pinlemenizi asla istemez.

Örnek akış: issue özetlenir → kaynak kod okunup kök neden ve plan (diff + regresyon testi + doğrulama komutu) sunulur → siz onaylarsınız → ancak o zaman değişiklik uygulanır, test eklenir, proje test komutu çalıştırılır ve sonuç dürüstçe raporlanır. Siz onaylamadan hiçbir şey diske yazılmaz.

Gizlilik: Redaksiyon varsayılan olarak açıktır; --no-redact ile kapatılabilir. Redaksiyon, bilinen hassas anahtarları (email, password, token, cookies, ssn vb. — değerin tamamı düşürülür) ve bilinen kimlik bilgisi/PII kalıplarını (e-posta, bearer token, JWT, sk_/pk_/rk_ tipi secret'lar, uzun hex, IPv4) kapsar. Sentry tag'leri de anahtar sayılır: password adlı bir tag, değeri ne olursa olsun düşürülür. Yalnızca iki dar istisna vardır — kimlik alanları (id, eventID, …) ve release alanları (version, release, dist) sadece uzun hex kuralından muaftır (event id'si ve 40 karakterlik commit SHA'sı da uzun hex'tir; ilki olmadan özet, ikincisi olmadan eskime kontrolü işe yaramaz); diğer tüm kalıp kuralları bu alanlarda da çalışır, dolayısıyla user.id içindeki bir e-posta yine redakte edilir. Kapsamadığı şey: bir breadcrumb mesajında ya da exception metninde geçen bir müşteri adı ya da telefon numarası gibi serbest metindeki keyfi kişisel veriler — bunlar hiçbir kalıba uymadığı için olduğu gibi geçer. --no-redact çıktısını hiçbir koşulda paylaşılabilir saymayın; varsayılan (redakte edilmiş) çıktıyı da garanti PII'siz değil, yalnızca azaltılmış risk olarak değerlendirin.

Sorun giderme (exit code'a göre):

Exit	Anlamı	Ne yapmalı
0	Sorun yok	—
3	Erişim katmanı yok (detect), ya da veri komutunun ihtiyaç duyduğu token bulunamadı	Yukarıdaki üç erişim seçeneğinden birini kurun ya da oturumda bir Sentry MCP sunucusu arayın. Sessizce yeniden denemeyin.
4	Kullanılabilir Python 3.8+ yorumlayıcısı yok — python3, python, py adlarının hiçbiri çalışıp 3.8+ raporlamıyor	python.org'dan Python 3.8+ kurun ya da SENTRY_PYTHON ile mevcut bir yorumlayıcıyı gösterin. Windows'ta bu exit genellikle PATH'teki tek python3'ün Microsoft Store stub'ı olduğu anlamına gelir.
5	İstek başarısız oldu — curl'ün kendisi hata verdi ya da yanıt 2xx dışıydı	stderr mesajını okuyun — Sentry'nin kendi yanıt gövdesi hemen üstünde basılır ve asıl sorunu adlandırır (403'te eksik kapsam, 400'de hatalı parametre gibi). Sessizce yeniden denemeyin.
6	Referans bir issue id'sine çözülemedi — bilinmeyen bir short id, ya da (short-id çözümleme yolunda) bir 403, 400, 5xx, ağ hatası ya da doğrulama reddi bu exit'e düşer, 5 ya da 64 yerine	id, short id ya da URL'yi kontrol edin, ama önce stderr mesajını okuyun — asıl neden (typo, yanlış org, eksik kapsam, hatalı parametre) her zaman hemen üstünde basılıdır; kontrol etmeden typo varsaymayın.
64	Kullanım ya da doğrulama hatası (hatalı/eksik flag değeri, çözülemeyen org/project, ayrıştırılamayan bir referans, ya da reddedilen bir karakter)	stderr mesajı tam olarak neyin yanlış olduğunu söyler; o girdiyi düzeltin.
130	Kesildi (SIGINT)	Çağrı iptal edildi.
143	Sonlandırıldı (SIGTERM)	Süreç dışarıdan sonlandırıldı.

Destek: Bu proje işinize yarıyorsa GitHub Sponsors üzerinden destek olabilirsiniz.

Lisans: MIT. Bkz. LICENSE.