@sentry/junior-sentry 0.248.0 → 0.250.0

package/README.md

@@ -1,6 +1,6 @@
 # @sentry/junior-sentry
 
-Sentry investigations (per-user OAuth plus optional org read access) and signed issue webhooks (internal integration) for Junior.
+Sentry investigations and explicitly requested project, team, and alert changes (per-user OAuth plus optional org read access) and signed issue webhooks (internal integration) for Junior.
 
 ```bash
 pnpm add @sentry/junior @sentry/junior-sentry
@@ -27,10 +27,11 @@ Verified CLI surface (check live `sentry --help` before blocking):
 
 - `sentry issue list|events|explain|plan|view`
 - `sentry org list|view`
+- `sentry project create|list|view`, `sentry team list`, `sentry dsn list`
 - `sentry log list|view`
 - `sentry trace list|view|logs`
 - `sentry alert metrics list|view|create|edit|delete`
-- `sentry api <endpoint>` fallback
+- `sentry api <endpoint>` fallback, with `sentry schema` for endpoint lookup
 
 ## Org read access
 

package/dist/index.js

@@ -104,7 +104,7 @@ function sentryPlugin() {
         domains: SENTRY_API_DOMAINS,
         type: "oauth-bearer"
       },
-      description: "Investigate Sentry telemetry, manage alerting, and receive issue and metric alert webhooks",
+      description: "Investigate Sentry telemetry, manage projects, teams, and alerting, and receive issue and metric alert webhooks",
       displayName: "Sentry",
       envVars: {
         SENTRY_CLIENT_ID: {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sentry/junior-sentry",
-  "version": "0.248.0",
+  "version": "0.250.0",
   "private": false,
   "publishConfig": {
     "access": "public"
@@ -27,7 +27,7 @@
   ],
   "dependencies": {
     "zod": "^4.5.4",
-    "@sentry/junior-plugin-api": "0.248.0"
+    "@sentry/junior-plugin-api": "0.250.0"
   },
   "devDependencies": {
     "@oxlint/plugins": "1.79.0",

package/skills/sentry/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sentry
-description: Query live Sentry telemetry, create explicitly requested Sentry alerts and monitors, and generate Sentry deep links. Use when users ask to investigate Sentry issues, events, logs, traces, organizations, projects, replays, product feature usage, Sentry's own product telemetry, authenticated Sentry API data, or to create alerting. Do not use it for repository/source-code/PR tasks, even when the topic concerns Sentry products.
+description: Query live Sentry telemetry, make explicitly requested Sentry configuration changes (projects, teams, alerts, and monitors), and generate Sentry deep links. Use when users ask to investigate Sentry issues, events, logs, traces, organizations, projects, replays, product feature usage, Sentry's own product telemetry, authenticated Sentry API data, to create or configure Sentry projects and teams, to assign teams to projects, or to create alerting. Do not use it for repository/source-code/PR tasks, even when the topic concerns Sentry products.
 allowed-tools: bash
 ---
 
@@ -18,7 +18,7 @@ Before declaring a Sentry data surface unavailable, verify the current CLI help:
 
 1. Confirm operation and target:
 
-- Determine operation: issue, event, log, trace, org, project, replay/deep-link, Sentry product feature usage, alert/monitor creation, or API query.
+- Determine operation: issue, event, log, trace, org, project, replay/deep-link, Sentry product feature usage, project/team configuration, alert/monitor creation, or API query.
 - Resolve org from channel config: `jr-rpc config get sentry.org`
 - Resolve project from channel config: `jr-rpc config get sentry.project` (optional — many queries span multiple projects).
 - If org is missing and needed, ask the user.
@@ -32,26 +32,36 @@ Before declaring a Sentry data surface unavailable, verify the current CLI help:
 - Read [references/sandbox-runtime.md](references/sandbox-runtime.md) before relying on sandbox credentials.
 - Prefer `--json` when parsing or summarizing results.
 - If no high-level CLI command covers the request, use `sentry api <endpoint>` before claiming the workflow is blocked.
-- Create alerts only when the user explicitly asks. Prefer `sentry alert metrics` for metric-alert list/view/create/edit/delete; before writing, resolve the exact target, check duplicates, run the complete command with `--dry-run`, then execute once and report the created rule URL.
-- Use `sentry api` only when live CLI help confirms the first-class command cannot express the requested alert behavior, such as dynamic anomaly detection.
+- For an explicitly requested write, follow the write workflow below.
+- Prefer `sentry alert metrics` for metric alerts. Use `sentry api` only when live CLI help confirms the first-class command cannot express the requested alert behavior, such as dynamic anomaly detection.
 - If a Sentry API call returns `401`, or clearly says the token is invalid, expired, revoked, or unauthorized, rerun the real Sentry command once and let the runtime trigger a reconnect flow when needed.
 - If a Sentry API call explicitly says `missing scope`, `missing scopes`, or `insufficient scope`, rerun the real Sentry command once and let the runtime trigger a reconnect flow when needed.
 - If a Sentry API call returns a generic `403`, `permission denied`, or otherwise indicates missing org/project access without naming missing scopes, stop and tell the user the current Sentry connection could not access the requested Sentry data.
 - Only mention a specific missing scope when the CLI or API error explicitly names that scope. Do not guess scope names from a generic `403`.
 
-3. Generate deep links:
+3. Make requested writes:
+
+- Read [references/cli-commands.md](references/cli-commands.md) for the write command shapes. Use `sentry schema <resource>` to confirm the current endpoint and fields before an API write.
+- Resolve the exact org, project, team, and member slugs or IDs. Ask when the target is ambiguous; do not guess.
+- Read the current state first. Stop on a likely duplicate (for example, a project or team with the same slug) and report it.
+- Change only the fields the user asked for. Do not reset or rewrite other settings.
+- Run the complete command with `--dry-run` first, then run it once without `--dry-run`.
+- Read the resource again and report what changed (before → after) with the Sentry URL.
+- For a destructive or irreversible change (a delete, removing a team from a project, a slug rename, or a transfer), make sure the user named that exact action in the current request.
+
+4. Generate deep links:
 
 - For user-scoped or entity-specific views, generate URLs instead of CLI calls.
 - Read [references/deep-link-patterns.md](references/deep-link-patterns.md) for URL templates.
 
-4. Report result:
+5. Report result:
 
 - Return issue details, replay links, deep links, or CLI output inline.
 - Include Sentry web URLs for easy navigation.
 
 ## Guardrails
 
-- Default to read-only operations. Only create, edit, or delete alerting resources when the user explicitly requests that exact action and a documented first-class CLI command supports it. Use API fallback only for explicitly requested alert behavior that live CLI help confirms is unsupported.
+- Write only when the user asks for that change.
 - Avoid speculative Sentry CLI subcommands. Use bundled references plus live `sentry --help` output to verify current commands.
 - Do not print credential values.
 - If org is missing and needed, ask the user.

package/skills/sentry/SOURCES.md

@@ -1,6 +1,6 @@
 # Sentry Skill Sources
 
-Last updated: 2026-07-13
+Last updated: 2026-10-16
 
 ## Source inventory
 
@@ -32,7 +32,9 @@ Last updated: 2026-07-13
 | Treat Sentry product feature usage and explicit Sentry telemetry redirects as Sentry skill triggers. | adopted  | Issue 615 showed the previous trigger language under-specified product-introspection queries and let Hex win. |
 | Preserve stale plural subcommands as recommended forms.                                              | rejected | `organizations list` was the root failure; aliases should not be taught as canonical command shapes.          |
 | Create a broad new troubleshooting reference.                                                        | deferred | Current failure modes fit in the focused CLI reference without crowding `SKILL.md`.                           |
-| Permit explicitly requested alert/monitor writes only.                                               | adopted  | `alerts:write` is intentionally narrow; unrelated Sentry mutations remain out of scope.                       |
+| Permit explicitly requested alert/monitor writes only.                                               | replaced | Replaced on 2026-10-16 by the project and team write decision below.                                          |
+| Write when the user asks; do not keep an allowlist of writes in the skill.                           | adopted  | Access limits belong to OAuth scopes, Sentry roles, and egress rules, not skill text.                         |
+| Use `sentry schema` before API writes.                                                               | adopted  | CLI `0.47.0` ships the API schema, so endpoint and field names come from the installed CLI, not memory.       |
 | Prefer first-class `sentry alert metrics` commands.                                                  | adopted  | CLI `0.38.0` supports list, view, create, edit, delete, triggers, and dry-run.                                |
 | Keep API fallback for dynamic anomaly detection.                                                     | adopted  | The current CLI create flags expose threshold triggers but no dynamic/anomaly configuration.                  |
 
@@ -53,6 +55,8 @@ Last updated: 2026-07-13
 
 ## Changelog
 
+- 2026-10-16: Replaced the alert-only write rule with a general write workflow (dry-run, duplicate, and verify steps) and project and team command shapes. The skill no longer lists allowed or denied writes. Checked against CLI `0.47.0` help and `sentry schema` output, and Sentry endpoint permissions (`ProjectPermission`, `ProjectTeamsPermission`, `OrganizationTeamMemberPermission`).
+
 - 2026-07-13: Added CLI-first `sentry alert metrics` guidance, explicit-write and duplicate safeguards, API fallback for unsupported anomaly configuration, and `alerts:write` scope behavior.
 - 2026-06-18: Expanded trigger language for Sentry product telemetry and feature usage, and recorded issue 615 routing evidence.
 - 2026-04-30: Reconciled skill guidance with Sentry CLI `0.30.0`, replaced stale plural command forms, added live-help verification, expanded log/trace/API guidance, updated eval smoke artifacts, and added an org-list command-selection eval.

package/skills/sentry/SPEC.md

@@ -2,8 +2,8 @@
 
 ## Intent
 
-The Sentry skill helps agents investigate live Sentry telemetry and create explicitly requested alerts and monitors through the Sentry CLI using per-user credentials injected by Junior.
-It should produce useful investigation results, safe alerting mutations, or Sentry web links without exposing credentials.
+The Sentry skill helps agents investigate live Sentry telemetry and make explicitly requested project, team, and alerting changes through the Sentry CLI using per-user credentials injected by Junior.
+It should produce useful investigation results, safe configuration changes, or Sentry web links without exposing credentials.
 
 ## Scope
 
@@ -13,26 +13,27 @@ In scope:
 - Investigating Sentry's own product telemetry and product feature usage through Sentry CLI/API data surfaces.
 - Using `sentry api <endpoint>` for authenticated requests when no high-level command exists.
 - Creating explicitly requested metric alerts through `sentry alert metrics` after duplicate checks and dry-run validation, with API fallback only for unsupported alert behavior.
+- Other Sentry API writes the user asks for, such as creating projects, updating project settings, and managing teams, after target resolution, duplicate checks, and dry-run validation.
 - Generating Sentry deep links for user-scoped or entity-specific views.
 - Diagnosing auth, scope, and access failures without guessing missing scopes.
 
 Out of scope:
 
 - Repository, code search, commit, branch, and pull-request work.
-- Mutating Sentry data outside explicitly requested alert or monitor operations.
+- Sentry writes the user did not ask for.
 - Persisting, printing, or transforming Sentry credentials.
 
 ## Users And Trigger Context
 
 - Primary users: Junior users asking Slack or harness agents to investigate Sentry data.
-- Common user requests: "list my Sentry issues", "show error logs", "inspect this trace", "which orgs can I access", "open the issue in Sentry", "use Sentry telemetry", "create a metric alert", and "notify this channel when this monitor fires".
+- Common user requests: "list my Sentry issues", "show error logs", "inspect this trace", "which orgs can I access", "open the issue in Sentry", "use Sentry telemetry", "create a metric alert", "create a project for this service", "give team X access to project Y", "change this project setting", and "notify this channel when this monitor fires".
 - Should not trigger for: source-code tasks, GitHub PRs, repository searches, or generic questions about Sentry SDK implementation.
 
 ## Runtime Contract
 
 - Required first actions: classify the Sentry operation, resolve configured org/project when needed, and verify current CLI help before blocking on an unknown command.
-- Required outputs: concise findings, relevant Sentry URLs or deep links, created alerting resource URLs, and clear access/auth failure messages.
-- Non-negotiable constraints: do not print credentials; default to read-only commands; only perform explicitly requested alerting mutations; check duplicates and dry-run before writing; use canonical current CLI command groups; use `sentry api` before claiming a surface is unavailable.
+- Required outputs: concise findings, relevant Sentry URLs or deep links, changed resource URLs with before/after values, and clear access/auth failure messages.
+- Non-negotiable constraints: do not print credentials; default to read-only commands; write only when the user asks; read current state, check duplicates, and dry-run before writing; change only requested fields; verify after writing; use canonical current CLI command groups; use `sentry api` before claiming a surface is unavailable.
 - Expected bundled files loaded at runtime: `references/cli-commands.md`, `references/deep-link-patterns.md`, and `references/sandbox-runtime.md`.
 
 ## Current CLI Data
@@ -40,10 +41,11 @@ Out of scope:
 - Verified date: 2026-07-13.
 - Verified npm package: `sentry@0.38.0`, installed from the `runtimeDependencies` declared by `sentryPlugin()`.
 - Auth model: Junior injects `SENTRY_AUTH_TOKEN` for authenticated Sentry commands during the requesting user's turn.
-- Canonical command groups: `sentry issue`, `sentry org`, `sentry log`, `sentry trace`, `sentry alert metrics`, and `sentry api`.
+- Canonical command groups: `sentry issue`, `sentry org`, `sentry project`, `sentry team`, `sentry dsn`, `sentry log`, `sentry trace`, `sentry alert metrics`, `sentry schema`, and `sentry api`.
 - Required migration rule: prefer singular command groups such as `sentry org list`; do not teach stale plural command forms such as `sentry organizations list`.
 - Required fallback rule: use `sentry api <endpoint>` when no high-level CLI command covers the requested surface.
 - Alerting write rule: prefer `sentry alert metrics`; use the API fallback only when live CLI help confirms the requested behavior is unsupported.
+- Project and team write rule: use `sentry project create` for new projects; use `sentry api` for settings, project-team, and team writes after `sentry schema` confirms the endpoint.
 
 ## Source And Evidence Model
 
@@ -79,12 +81,14 @@ Data that must not be stored:
 ## Evaluation
 
 - Lightweight validation: run skill validation and grep for stale command forms after CLI updates.
-- Deeper evaluation: add Slack/harness evals for org listing, issue search, log search, trace lookup, API fallback, auth recovery, explicit alert creation, duplicate prevention, and refusal of unrelated mutations.
+- Deeper evaluation: add Slack/harness evals for org listing, issue search, log search, trace lookup, API fallback, auth recovery, explicit alert creation, explicit project creation and team assignment, duplicate prevention, and refusal of unrelated mutations.
 - Holdout examples: requests that mention "organizations list", "orgs", "logs for this trace", and "use the API".
-- Acceptance gates: command guidance matches latest CLI help, stale plural forms are not canonical, read-only fallback is available, alerting writes require explicit intent plus duplicate and dry-run checks, unrelated mutations remain blocked, and credential handling remains private.
+- Acceptance gates: command guidance matches latest CLI help, stale plural forms are not canonical, read-only fallback is available, writes require explicit intent plus duplicate and dry-run checks, unrelated mutations remain blocked, and credential handling remains private.
 
 ## Known Limitations
 
+- This skill does not decide which Sentry requests are allowed. OAuth scopes, the user's Sentry role, and host egress rules (when added) own that limit.
+
 - The skill depends on the runtime-installed npm `sentry` package, which may change independently of this repository.
 - The eval shim is intentionally narrow and is not a full Sentry CLI replacement.
 - Some live Sentry requests require org/project context or product access that the current user may not have.

package/skills/sentry/references/cli-commands.md

@@ -7,11 +7,12 @@ The npm `sentry` package is intentionally installed at runtime by `sentryPlugin(
 
 ## Command selection rules
 
-1. Prefer current canonical singular command groups: `issue`, `org`, `log`, `trace`, and `api`.
+1. Prefer current canonical singular command groups: `issue`, `org`, `project`, `team`, `dsn`, `log`, `trace`, `alert`, and `api`.
 2. Do not use stale plural subcommands such as `sentry organizations list`.
 3. If a command errors as unknown, run `sentry --help` and the nearest subcommand help before declaring the surface unavailable.
 4. Prefer `--json` and, when useful, `--fields` for structured parsing.
-5. Use `sentry api <endpoint>` for authenticated API calls when a high-level command does not cover the request. Default to `GET`; only perform documented alert or monitor mutations when explicitly requested.
+5. Use `sentry api <endpoint>` for authenticated API calls when a high-level command does not cover the request. Default to `GET`; write only when the user asks for the change.
+6. Use `sentry schema <resource>` (for example `sentry schema projects` or `sentry schema --search team`) to find the current endpoint and body fields before an API write.
 
 ## Issue commands
 
@@ -50,6 +51,40 @@ sentry org view ORG [--json]
 
 Views one organization.
 
+## Project and team commands
+
+Read commands:
+
+```bash
+sentry project list ORG/ [--platform PLATFORM] [--json]
+sentry project view ORG/PROJECT [--json]
+sentry team list ORG/ [--json]
+sentry dsn list ORG/PROJECT [--json]
+sentry api projects/ORG/PROJECT/teams/ --json
+sentry api teams/ORG/TEAM/members/ --json
+```
+
+Write commands. Each write runs once with `--dry-run`, then once for real:
+
+| Change                       | Command                                                              | Scope           |
+| ---------------------------- | -------------------------------------------------------------------- | --------------- |
+| Create a project             | `sentry project create ORG/NAME:PLATFORM --team TEAM [--json]`       | `project:write` |
+| Update project settings      | `sentry api projects/ORG/PROJECT/ -X PUT -d '{"FIELD":VALUE}'`       | `project:write` |
+| Add a team to a project      | `sentry api projects/ORG/PROJECT/teams/TEAM/ -X POST`                | `project:write` |
+| Remove a team from a project | `sentry api projects/ORG/PROJECT/teams/TEAM/ -X DELETE`              | `project:write` |
+| Create a team                | `sentry api organizations/ORG/teams/ -X POST -d '{"slug":"TEAM"}'`   | `team:write`    |
+| Update a team                | `sentry api teams/ORG/TEAM/ -X PUT -d '{"name":"NAME"}'`             | `team:write`    |
+| Add a member to a team       | `sentry api organizations/ORG/members/MEMBER_ID/teams/TEAM/ -X POST` | `team:write`    |
+
+Notes:
+
+- Run `sentry platform list` when the platform slug is unclear.
+- `sentry project create` needs `--team` when the org has more than one team. Ask which team when the user did not say.
+- After a project is created, run `sentry dsn list ORG/PROJECT` and report the DSN and the project URL.
+- For a settings update, run `sentry schema updateProject` to confirm the field name. Send only the changed fields. Common fields: `name`, `slug`, `platform`, `isBookmarked`, `resolveAge`, `subjectPrefix`, `highlightTags`, `options[...]`.
+- Changing `slug` changes project URLs and breaks saved links. Treat it as an irreversible change.
+- Resolve `MEMBER_ID` with `sentry api organizations/ORG/members/?query=EMAIL --json`. Do not guess IDs.
+
 ## Log commands
 
 ### List logs
@@ -124,7 +159,7 @@ The current CLI create command exposes threshold triggers but no dynamic/anomaly
 sentry api ENDPOINT [--method METHOD] [--field KEY=VALUE] [--data JSON] [--json]
 ```
 
-Use `sentry api` only when no first-class CLI command covers the requested operation. Default to read-only `GET` requests. For an explicitly requested alerting write, validate with `--dry-run` and verify the current API schema before executing. Do not mutate unrelated Sentry resources.
+Use `sentry api` only when no first-class CLI command covers the requested operation. Default to read-only `GET` requests. For an explicitly requested write, verify the endpoint with `sentry schema`, validate with `--dry-run`, then execute once. Do not mutate unrelated Sentry resources.
 
 ## Common flags
 
@@ -135,19 +170,22 @@ Use `sentry api` only when no first-class CLI command covers the requested opera
 
 ## Common use cases
 
-| User request                                          | Command pattern                                                     |
-| ----------------------------------------------------- | ------------------------------------------------------------------- |
-| "List my orgs"                                        | `sentry org list --json`                                            |
-| "Show issues in frontend"                             | `sentry issue list ORG/frontend --json`                             |
-| "Show unresolved errors across the org"               | `sentry issue list ORG/ --query "is:unresolved level:error" --json` |
-| "Inspect this issue"                                  | `sentry issue view ISSUE --json`                                    |
-| "Show events for this issue"                          | `sentry issue events ISSUE --json`                                  |
-| "Find error logs"                                     | `sentry log list ORG/PROJECT --query "level:error" --json`          |
-| "Inspect a trace"                                     | `sentry trace view ORG/PROJECT/TRACE_ID --json`                     |
-| "Show logs for a trace"                               | `sentry trace logs ORG/TRACE_ID --json`                             |
-| "Call an endpoint not covered by high-level commands" | `sentry api organizations/ --json`                                  |
-| "Create a static metric alert"                       | `sentry alert metrics create ... --dry-run`, then execute           |
-| "Create a dynamic anomaly alert"                     | Verify CLI help; use API fallback only if still unsupported         |
+| User request                                          | Command pattern                                                                   |
+| ----------------------------------------------------- | --------------------------------------------------------------------------------- |
+| "List my orgs"                                        | `sentry org list --json`                                                          |
+| "Show issues in frontend"                             | `sentry issue list ORG/frontend --json`                                           |
+| "Show unresolved errors across the org"               | `sentry issue list ORG/ --query "is:unresolved level:error" --json`               |
+| "Inspect this issue"                                  | `sentry issue view ISSUE --json`                                                  |
+| "Show events for this issue"                          | `sentry issue events ISSUE --json`                                                |
+| "Find error logs"                                     | `sentry log list ORG/PROJECT --query "level:error" --json`                        |
+| "Inspect a trace"                                     | `sentry trace view ORG/PROJECT/TRACE_ID --json`                                   |
+| "Show logs for a trace"                               | `sentry trace logs ORG/TRACE_ID --json`                                           |
+| "Call an endpoint not covered by high-level commands" | `sentry api organizations/ --json`                                                |
+| "Create a project for my Node app"                    | `sentry project create ORG/NAME:node --team TEAM --dry-run`, then execute         |
+| "Give team X access to project Y"                     | `sentry api projects/ORG/Y/teams/X/ -X POST --dry-run`, then execute              |
+| "Change project setting Z"                            | `sentry schema updateProject`, then `sentry api projects/ORG/PROJECT/ -X PUT ...` |
+| "Create a static metric alert"                        | `sentry alert metrics create ... --dry-run`, then execute                         |
+| "Create a dynamic anomaly alert"                      | Verify CLI help; use API fallback only if still unsupported                       |
 
 ## Troubleshooting
 
@@ -163,8 +201,9 @@ Use `sentry api` only when no first-class CLI command covers the requested opera
 | API returns `401` or invalid/expired/revoked token text             | Stale or missing credential                | Rerun the real command once so the runtime can trigger reconnect.                             |
 | API returns explicit missing scope text                             | OAuth grant lacks a named scope            | Rerun the real command once so the runtime can trigger reconnect.                             |
 | API returns generic `403` or permission denied                      | Connected account lacks org/project access | Stop and tell the user the current connection cannot access the requested data.               |
-| Alert write returns an explicit missing-scope error                  | OAuth grant predates alert writes         | Rerun once to trigger reconnect; the connection needs `alerts:write`.                          |
-| Static metric alert requested                                       | First-class CLI command is available       | Use `sentry alert metrics create`; do not drop directly to `sentry api`.                        |
-| Dynamic/anomaly alert flags are unavailable                         | CLI coverage gap                          | Verify live help, then use the current API fallback if needed.                                 |
+| Alert write returns an explicit missing-scope error                 | OAuth grant predates alert writes          | Rerun once to trigger reconnect; the connection needs `alerts:write`.                         |
+| Project or team write returns an explicit missing-scope error       | OAuth grant predates the write scope       | Rerun once to trigger reconnect; the connection needs `project:write` or `team:write`.        |
+| Static metric alert requested                                       | First-class CLI command is available       | Use `sentry alert metrics create`; do not drop directly to `sentry api`.                      |
+| Dynamic/anomaly alert flags are unavailable                         | CLI coverage gap                           | Verify live help, then use the current API fallback if needed.                                |
 
 Use these command shapes during normal skill execution, but treat live CLI help as the final source when this reference and the installed CLI disagree.