About flutter-observability
A skill for diagnosing Flutter production failures and governing telemetry. It calls for reviewing existing instrumentation and evidence before suggesting conditional fixes, while minimizing collected data and accounting for privacy and backend controls.
Key features
- 01Inspect existing telemetry and release wiring
- 02Define a minimal operational event contract
- 03Address redaction, consent, and sampling
- 04Separate client controls from backend duties
- 05Verify error capture and end-to-end signals
- 06Load only relevant diagnostic references
Use cases
- 01Investigate a Flutter production incident and identify missing evidence
- 02Plan safe logging, tracing, and error telemetry
- 03Check release identifiers, symbolicated stacks, and data redaction
- 04Test behavior when telemetry is offline, rate-limited, or unavailable
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/flutter-observabilityin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
evals/cases.jsonreferences/error-and-crash-capture.mdlogging-tracing-privacy.mdvendor-and-verification.mdDetails
From the project READMEFlutter Observability
Make production failures diagnosable without collecting unnecessary user data. Preserve an existing Sentry, Crashlytics, OpenTelemetry, Dynatrace, Datadog, or other telemetry stack unless the user requests a migration.
Preflight
Read SDK constraints, entrypoints, flavors/environments, and the complete existing telemetry and delivery wiring before diagnosing a cause or prescribing changes: SDK initialization, error hooks, consent/privacy rules, network and navigation instrumentation, isolate usage, obfuscation, symbol retention/upload, CI, and release identity. Do not infer the root cause from dashboard symptoms alone. When repository or backend evidence is unavailable, lead with the exact artifacts and backend evidence still required, state that diagnosis remains pending, and keep any remediation conditional. Start from a concrete diagnostic question or incident; do not instrument every event by default.
Define a small operational event contract: stable event name, severity, timestamp, release/build, environment, platform, correlation identifier, outcome, duration where meaningful, and a bounded set of redacted attributes. Keep user content, tokens, credentials, payment data, and raw request/response bodies out of telemetry.
Every instrumentation plan must explicitly cover all five governance controls: redaction, consent, sampling, backend retention/access, and bounded offline buffering. State which controls live in client code and which must be verified in the backend; do not imply client configuration alone enforces retention or access.
Route the work
- For framework, root-isolate, child-isolate, and async error coverage, read error and crash capture.
- For structured logs, breadcrumbs, traces, correlation, sampling, redaction, and consent, read logging, tracing, and privacy.
- For choosing or preserving a vendor, release metadata, symbols, buffering, and end-to-end proof, read vendor and verification.
Load only the references relevant to the request.
Boundaries
flutter-performanceowns profile-mode measurement and optimization decisions; production traces can reveal a regression or candidate bottleneck but are not proof of an optimization.flutter-product-analyticsowns funnels, attribution, conversion, experiments, and business events; operational telemetry answers reliability and incident-diagnosis questions. State this distinction when instrumenting a user journey so analytics events or UI tracking do not leak into the operational contract.flutter-networkingowns HTTP behavior; this skill defines safe correlation and outcome signals around it.flutter-securityowns a broad security review; this skill enforces telemetry minimization, redaction, consent, retention awareness, and least exposure.flutter-build-releaseowns artifact and symbol production; this skill verifies release/build identifiers and symbol upload linkage.
Verification
Test normalization, redaction, sampling, consent, correlation, and adapter behavior. Exercise a handled error and each required controlled unhandled-error class in a non-production backend/environment, then confirm ingestion exactly once, expected release/build/environment, usable symbolicated stack, and safe attributes in the actual dashboard or query surface. Confirm secrets and disallowed personal data are absent. Verify degraded behavior when telemetry is offline, rate-limited, or unavailable.
Do not claim observability works because initialization compiled. State which signals were observed end to end, which were only unit-tested, and what remains vendor- or device-blocked.