From 3cc54d5394acc2f1f4b4de7ecabd88f2fa5a552e Mon Sep 17 00:00:00 2001 From: Markus Hintersteiner Date: Thu, 26 Mar 2026 10:23:01 +0100 Subject: [PATCH] meta: Add dotagents configuration Sets up dotagents to manage AI agent skills declaratively via agents.toml. Previously committed skills are now managed by dotagents and gitignored. Co-Authored-By: Claude Opus 4.6 (1M context) --- .claude/skills/create-java-pr/SKILL.md | 184 ------------------------- .claude/skills/test/SKILL.md | 85 ------------ .gitignore | 4 + agents.toml | 45 ++++++ 4 files changed, 49 insertions(+), 269 deletions(-) delete mode 100644 .claude/skills/create-java-pr/SKILL.md delete mode 100644 .claude/skills/test/SKILL.md create mode 100644 agents.toml diff --git a/.claude/skills/create-java-pr/SKILL.md b/.claude/skills/create-java-pr/SKILL.md deleted file mode 100644 index 6d5bb34edb3..00000000000 --- a/.claude/skills/create-java-pr/SKILL.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -name: create-java-pr -description: Create a pull request in sentry-java. Use when asked to "create pr", "prepare pr", "prep pr", "open pr", "ready for pr", "prepare for review", "finalize changes". Handles branch creation, code formatting, API dump, committing, pushing, PR creation, changelog, and stacked PRs. ---- - -# Create Pull Request (sentry-java) - -Prepare local changes and create a pull request for the sentry-java repo. - -**Required reading:** Before proceeding, read `.cursor/rules/pr.mdc` for the full PR and stacked PR workflow details. That file is the source of truth for PR conventions, stack comment format, branch naming, and merge strategy. - -## Step 0: Determine PR Type - -Ask the user (or infer from context) whether this is: - -- **Standalone PR** — a regular PR targeting `main`. Follow Steps 1–6 as written. -- **First PR of a new stack** — ask for a topic name (e.g. "Global Attributes"). Create a collection branch from `main`, then branch the first PR off it. The first PR targets the collection branch. -- **Next PR in an existing stack** — identify the previous stack branch and topic. This PR targets the previous stack branch. - -If the user mentions "stack", "stacked PR", or provides a topic name with a number (e.g. `[Topic 2]`), treat it as a stacked PR. See `.cursor/rules/pr.mdc` § "Stacked PRs" for full details. - -## Step 1: Ensure Feature Branch - -```bash -git branch --show-current -``` - -If on `main` or `master`, create and switch to a new branch: - -```bash -git checkout -b / -``` - -Derive the branch name from the changes being made. Use `feat/`, `fix/`, `ref/`, etc. matching the commit type conventions. - -**For stacked PRs:** For the first PR in a new stack, first create and push the collection branch (see `.cursor/rules/pr.mdc` § "Creating the Collection Branch"), then branch the PR off it. For subsequent PRs, branch off the previous stack branch. Use the naming conventions from `.cursor/rules/pr.mdc` § "Branch Naming". - -**CRITICAL: Never merge, fast-forward, or push commits into the collection branch.** It stays at its initial position until the user merges stack PRs through GitHub. Updating it will auto-merge and destroy the entire PR stack. - -## Step 2: Format Code and Regenerate API Files - -```bash -./gradlew spotlessApply apiDump -``` - -This is **required** before every PR in this repo. It formats all Java/Kotlin code via Spotless and regenerates the `.api` binary compatibility files. - -If the command fails, diagnose and fix the issue before continuing. - -## Step 3: Commit Changes - -Check for uncommitted changes: - -```bash -git status --porcelain -``` - -If there are uncommitted changes, invoke the `sentry-skills:commit` skill to stage and commit them following Sentry conventions. - -**Important:** When staging, ignore changes that are only relevant for local testing and should not be part of the PR. Common examples: - -| Ignore Pattern | Reason | -|---|---| -| Hardcoded booleans flipped for testing | Local debug toggles | -| Sample app config changes (`sentry-samples/`) | Local testing configuration | -| `.env` or credentials files | Secrets | - -Restore these files before committing: - -```bash -git checkout -- -``` - -## Step 4: Push the Branch - -```bash -git push -u origin HEAD -``` - -If the push fails due to diverged history, ask the user how to proceed rather than force-pushing. - -## Step 5: Create PR - -Invoke the `sentry-skills:create-pr` skill to create a draft PR. When providing the PR body, use the repo's PR template structure from `.github/pull_request_template.md`: - -``` -## :scroll: Description - - -## :bulb: Motivation and Context - - -## :green_heart: How did you test it? - - -## :pencil: Checklist -- [ ] I added GH Issue ID _&_ Linear ID -- [ ] I added tests to verify the changes. -- [ ] No new PII added or SDK only sends newly added PII if `sendDefaultPII` is enabled. -- [ ] I updated the docs if needed. -- [ ] I updated the wizard if needed. -- [ ] Review from the native team if needed. -- [ ] No breaking change or entry added to the changelog. -- [ ] No breaking change for hybrid SDKs or communicated to hybrid SDKs. - -## :crystal_ball: Next steps -``` - -Fill in each section based on the changes being PR'd. Check any checklist items that apply. - -**For stacked PRs:** - -- Pass `--base ` so the PR targets the previous branch (first PR in a stack targets the collection branch). -- Use the stacked PR title format: `(): [ ] ` (see `.cursor/rules/pr.mdc` § "PR Title Naming"). -- Include the stack list at the top of the PR body, before the `## :scroll: Description` section (see `.cursor/rules/pr.mdc` § "Stack List in PR Description" for the format). -- Add a merge method reminder at the very end of the PR body (see `.cursor/rules/pr.mdc` § "Stack List in PR Description" for the exact text). This only applies to stack PRs, not the collection branch PR. - -Then continue to Step 5.5 (stacked PRs only) or Step 6. - -## Step 5.5: Update Stack List on All PRs (stacked PRs only) - -Skip this step for standalone PRs. - -After creating the PR, update the PR description on **every other PR in the stack — including the collection branch PR** — so all PRs have the same up-to-date stack list. Follow the format and commands in `.cursor/rules/pr.mdc` § "Stack List in PR Description". - -**Important:** When updating PR bodies, never use shell redirects (`>`, `>>`) or pipes (`|`) or compound commands (`&&`). These create compound shell expressions that won't match permission patterns. Instead: -- Use `gh pr view --json body --jq '.body'` to get the body (output returned directly) -- Use the `Write` tool to save it to a temp file -- Use the `Edit` tool to modify the temp file -- Use `gh pr edit --body-file /tmp/pr-body.md` to update - -## Step 6: Update Changelog - -First, determine whether a changelog entry is needed. **Skip this step** (and go straight to "No changelog needed" below) if the changes are not user-facing, for example: - -- Test-only changes (new tests, test refactors, test fixtures) -- CI/CD or build configuration changes -- Documentation-only changes -- Code comments or formatting-only changes -- Internal refactors with no behavior change visible to SDK users -- Sample app changes - -If unsure, ask the user. - -### If changelog is needed - -Add an entry to `CHANGELOG.md` under the `## Unreleased` section. - -#### Determine the subsection - -| Change Type | Subsection | -|---|---| -| New feature | `### Features` | -| Bug fix | `### Fixes` | -| Refactoring, internal cleanup | `### Internal` | -| Dependency update | `### Dependencies` | - -Create the subsection under `## Unreleased` if it does not already exist. - -#### Entry format - -```markdown -- ([#](https://github.com/getsentry/sentry-java/pull/)) -``` - -Use the PR number returned by `sentry-skills:create-pr`. Match the style of existing entries — sentence case, ending with the PR link, no trailing period. - -#### Commit and push - -Stage `CHANGELOG.md`, commit with message `changelog`, and push: - -```bash -git add CHANGELOG.md -git commit -m "changelog" -git push -``` - -### No changelog needed - -If no changelog entry is needed, add `#skip-changelog` to the PR description to disable the changelog CI check: - -1. Get the current body: `gh pr view --json body --jq '.body'` -2. Use the `Write` tool to save the output to `/tmp/pr-body.md`, appending `\n#skip-changelog\n` at the end -3. Update: `gh pr edit --body-file /tmp/pr-body.md` diff --git a/.claude/skills/test/SKILL.md b/.claude/skills/test/SKILL.md deleted file mode 100644 index bdef12364f3..00000000000 --- a/.claude/skills/test/SKILL.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -name: test -description: Run tests for a specific SDK module. Use when asked to "run tests", "test module", "run unit tests", "run system tests", "run e2e tests", or test a specific class. Auto-detects unit vs system tests. Supports interactive mode. -allowed-tools: Bash, Read, Glob, AskUserQuestion -argument-hint: [interactive] [test-class-filter] ---- - -# Run Tests - -Run tests for a specific module. Auto-detects whether to run unit tests or system tests. - -## Step 0: Check for Interactive Mode - -If `$ARGUMENTS` starts with `interactive` (e.g., `/test interactive sentry ScopesTest`), enable interactive mode. Strip the `interactive` keyword from the arguments before proceeding. - -In interactive mode, use AskUserQuestion at decision points as described in the steps below. - -## Step 1: Parse the Argument - -The argument can be either: -- A **file path** (e.g., `@sentry/src/test/java/io/sentry/ScopesTest.kt`) -- A **module name** (e.g., `sentry-android-core`, `sentry-samples-spring-boot-4`) -- A **module name + test filter** (e.g., `sentry ScopesTest`) - -Extract the module name and optional test class filter from the argument. - -**Interactive mode:** If the test filter is ambiguous (e.g., matches multiple test classes across modules), use AskUserQuestion to let the user pick which test class(es) to run. - -## Step 2: Detect Test Type - -| Signal | Test Type | -|--------|-----------| -| Path contains `sentry-samples/` | System test | -| Module name starts with `sentry-samples-` | System test | -| Everything else | Unit test | - -## Step 3a: Run Unit Tests - -Determine the Gradle test task: - -| Module Pattern | Test Task | -|---------------|-----------| -| `sentry-android-*` | `testDebugUnitTest` | -| `sentry-compose*` | `testDebugUnitTest` | -| `*-android` | `testDebugUnitTest` | -| Everything else | `test` | - -**Interactive mode:** Before running, read the test class file and use AskUserQuestion to ask: -- "Run all tests in this class, or a specific method?" — list the test method names as options. - -If the user picks a specific method, use `--tests="*ClassName.methodName"` as the filter. - -With a test class filter: -```bash -./gradlew '::' --tests="**" --info -``` - -Without a filter: -```bash -./gradlew '::' --info -``` - -## Step 3b: Run System Tests - -System tests require the Python-based test runner which manages a mock Sentry server and sample app lifecycle. - -1. Ensure the Python venv exists: -```bash -test -d .venv || make setupPython -``` - -2. Extract the sample module name. For file paths like `sentry-samples//src/...`, the sample module is the directory name (e.g., `sentry-samples-spring`). - -3. Run the system test: -```bash -.venv/bin/python test/system-test-runner.py test --module -``` - -This starts the mock Sentry server, starts the sample app (Spring Boot/Tomcat/CLI), runs tests via `./gradlew :sentry-samples::systemTest`, and cleans up afterwards. - -## Step 4: Report Results - -Summarize the test outcome: -- Total tests run, passed, failed, skipped -- For failures: show the failing test name and the assertion/error message diff --git a/.gitignore b/.gitignore index f232c32db51..217f6178b1c 100644 --- a/.gitignore +++ b/.gitignore @@ -34,3 +34,7 @@ spy.log # Local Claude Code settings/state that should not be committed .claude/settings.local.json .claude/worktrees/ +# Auto-generated by dotagents — do not commit these files. +agents.lock +.agents/.gitignore +.claude/skills/ diff --git a/agents.toml b/agents.toml new file mode 100644 index 00000000000..ba383a16521 --- /dev/null +++ b/agents.toml @@ -0,0 +1,45 @@ +version = 1 + +[[skills]] +name = "dotagents" +source = "getsentry/dotagents" + +[[skills]] +name = "sentry-android-sdk" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-sdk-setup" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-sdk-upgrade" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-workflow" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-fix-issues" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-code-review" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-pr-code-review" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-feature-setup" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-create-alert" +source = "getsentry/sentry-for-ai" + +[[skills]] +name = "sentry-setup-ai-monitoring" +source = "getsentry/sentry-for-ai"