Summary
Exploratory research issue (not a committed feature) to investigate how much of the SDK's issue-handling and incident-response workflow we can automate with agents. Goal: map the design space, ship the cheapest safe slice, and decide what — if anything — is worth productionizing.
There are (at least) two entry points, or triggers, that both converge on the same downstream outcome: a triaged issue, a reproduction, and ultimately a fix PR.
Prior art — how sentry-javascript does it
sentry-javascript already runs this as a two-stage pipeline (.agents/skills/triage-issue, plus triage-issue.yml / auto-fix-issue.yml):
|
Stage 1 — triage |
Stage 2 — auto-fix |
| Trigger |
Auto on issues: [opened], gated to Bug/Feature labels |
Manual dispatch only (auto-run commented out: "until we verified how that works") |
| GitHub perms |
Read-only |
Write — branch, commit, draft PR |
| Output |
Triage report → Linear / job summary |
Draft fix PR |
Mechanics: thin GitHub Action → anthropics/claude-code-action@v1 (via OpenRouter, claude-opus-4-8) running a /triage-issue slash command. The intelligence is a small skill (a SKILL.md workflow + a mandatory prompt-injection gate + a few helper scripts). Issue content is treated as untrusted data, never instructions; tools are a tight allowlist; secrets are fenced in a dedicated CI environment. Notably, even JS's stage 2 only edits code from a report — it does not reproduce anything.
Trigger 1 — GitHub Action (issue-driven)
- Triage — port the JS skill, adapted to RN's reality (hybrid SDK: JS/native/bridge layers, New vs Old arch, iOS/Android, bare vs Expo, bundled native-SDK version). Read-only, low risk.
- Reproduction — the hard, RN-specific part: a faithful repro often needs a real device/simulator across the New/Old × iOS/Android × Expo/bare matrix, which a cheap ubuntu Action can't stand up.
- Fix PR (draft) — for well-localized JS-layer bugs, a draft PR + test, human-gated.
Trigger 2 — Sentry-native (crash-driven)
- A Sentry alert/webhook fires on an SDK-attributed crash or a crash-free-rate regression (SDK Crashes / SDK health).
- Automation opens or enriches a GitHub issue with stack trace, affected SDK/native versions, device/arch breakdown, frequency.
- Feeds the same repro → fix-PR pipeline as Trigger 1.
Open questions: identifying a crash as SDK-caused vs app-caused with acceptable precision; trigger mechanism (Sentry alert webhook / Seer / internal tooling); noise & rate-limiting to avoid PR spam; overlap with existing SDK-health monitoring.
Both paths converge
Trigger 1 (GitHub issue) ─┐
├─→ Triage → Reproduce → Draft Fix PR → human review
Trigger 2 (Sentry crash) ─┘
The reproduction + fix stage is shared and is where most of the risk and value sits.
Feasibility & proposed phasing
- Phase 1 — read-only triage (high feasibility, ~1–2 days). Near-verbatim port of the JS skill; static analysis only (grep + reasoning), never runs the app, can't write anything. This repo already has the plumbing:
agents.toml trust config, the local .agents/skills/ convention, and the OpenRouter access model. A local spike is scaffolded — see checklist.
- Phase 2 — JS-layer-only auto-fix (research). Draft PRs, manual trigger, well-localized bugs only — mirrors where JS is today.
- Phase 3 — automated reproduction on the arch matrix (open question). The genuinely unsolved part, and the natural home for Trigger 2.
Scope of this research
Summary
Exploratory research issue (not a committed feature) to investigate how much of the SDK's issue-handling and incident-response workflow we can automate with agents. Goal: map the design space, ship the cheapest safe slice, and decide what — if anything — is worth productionizing.
There are (at least) two entry points, or triggers, that both converge on the same downstream outcome: a triaged issue, a reproduction, and ultimately a fix PR.
Prior art — how
sentry-javascriptdoes itsentry-javascriptalready runs this as a two-stage pipeline (.agents/skills/triage-issue, plustriage-issue.yml/auto-fix-issue.yml):issues: [opened], gated toBug/FeaturelabelsMechanics: thin GitHub Action →
anthropics/claude-code-action@v1(via OpenRouter,claude-opus-4-8) running a/triage-issueslash command. The intelligence is a small skill (aSKILL.mdworkflow + a mandatory prompt-injection gate + a few helper scripts). Issue content is treated as untrusted data, never instructions; tools are a tight allowlist; secrets are fenced in a dedicated CI environment. Notably, even JS's stage 2 only edits code from a report — it does not reproduce anything.Trigger 1 — GitHub Action (issue-driven)
Trigger 2 — Sentry-native (crash-driven)
Open questions: identifying a crash as SDK-caused vs app-caused with acceptable precision; trigger mechanism (Sentry alert webhook / Seer / internal tooling); noise & rate-limiting to avoid PR spam; overlap with existing SDK-health monitoring.
Both paths converge
The reproduction + fix stage is shared and is where most of the risk and value sits.
Feasibility & proposed phasing
agents.tomltrust config, the local.agents/skills/convention, and the OpenRouter access model. A local spike is scaffolded — see checklist.Scope of this research
ci-triageenv still needed to run)