ref(skills): replace sentry-create-alert with sentry-create-monitor

[evanpurkhiser]

sentry-create-alert only covered the response half of Sentry's monitors-and-alerts model. A request like "alert me when p95 latency crosses 800ms" has no answer there — a monitor has to open the issue before an alert can act on it. This replaces it with sentry-create-monitor, covering both stages.

Why it points at the live schema

The old skill froze a copy of the workflow-engine payload schema into itself, and it had already drifted — the condition table was missing event_attribute, latest_release and percent_sessions_*, plus the trigger types real orgs actually use (new_high_priority_issue, seer_activity_trigger).

Sentry serves its API reference as Markdown (docs.sentry.io/api/monitors/<slug>.md), so the skill fetches the endpoint page before building any payload. The alert condition catalog alone is ~20k characters and ships new types without notice; a frozen copy is a liability. The skill carries the procedure and the traps, the reference carries the fields.

Why the reference isn't enough on its own

Verified against getsentry/sentry, several things the reference implies are wrong or incomplete:

The reference suggests	Actually
metric_issue is the only creatable monitor type	The endpoint accepts any type with a registered detector validator — uptime (uptime_domain_failure), cron (monitor_check_in_failure) and mobile builds (preprod_size_analysis) are all creatable
PUT needs the full payload	Detector updates run partial=True; PUT {"enabled": false} is complete. But any array you send is authoritative — "actionFilters": [] deletes every filter and action
config.frequency is one of a list of values	{"type": "integer", "minimum": 0}. The list is the UI's presets
Priority 50 is "Low"	It's medium. supported_condition_results is {75, 50, 0} — 25 is rejected outright

The skill also documents four endpoints absent from the reference: /detector-types/, /available-actions/ (the only source for a PagerDuty service targetIdentifier), /test-fire-actions/ for proving a notification route before committing to it, and the legacy-alert-rule ID mappers.

The auth-token trap

OrgAuthTokenAuthentication resolves to AnonymousUser, and organization_detector_index.py guards every method with if not request.user.is_authenticated while organization_workflow_index.py has no such guard. So an organization token creates alerts fine but 401s on listing monitors — which reads as a scope problem and isn't. The skill calls for a user token and spells out that 401 means wrong token type, 403 means missing scope.

Uptime monitors bypass the API

The MCP has create_uptime_monitor / update_uptime_monitor / delete_uptime_monitor, so uptime needs neither a token nor a hand-assembled payload. The skill routes there and only falls back to /detectors/ if the tools are absent.

Also in here

• references/concepts/monitors.md gains the naming mismatch that makes this API hard to navigate: monitors are detectors in the URL, alerts are workflows, and /organizations/{org}/monitors/ is the legacy Crons API that shouldn't be used. Its coverage and MCP claims are corrected too.
• sentry-get-started's menu claimed monitors/alerts and OTel weren't built as skills; both now route properly.

Verified with scripts/lint.sh, including built-links against the hydrated tree.

[saponifi3d]

lgtm - def moves the ball forward and improves creating alerts, thanks for updating all this!! 🙏 (s/o to the plans and troubleshooting table in the skill.md, i feel like that will be a great way to steer the LLMs too)

[saponifi3d]

just a heads up that this detector doesn't use datasources; it's storing everything in the config as well.