chore(repo): Add dogfood-release skill

.agents/skills/dogfood-release/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: dogfood-release
+description: Bump a just-published Sentry JS SDK version across the internal dogfooding repos (sentry, gib-potato, sentry-changelog, sentry-docs, chartcuterie) and open a draft PR per repo. Use after publishing an SDK release, especially a prerelease, to get it running in our own products early. Trigger phrases include "dogfood this release", "dogfood the SDK", "bump the SDK in our repos", "roll out <version> to the consumer repos".
+argument-hint: '<version>  # e.g. 11.0.0-beta.0'
+---
+
+# Dogfood an SDK release in the consumer repos
+
+Bump one SDK version across the internal repos that run it, and open a draft PR per repo.
+
+## Requirements
+
+Only `gh`, authenticated with push access to the `getsentry` org. No local checkout is
+needed: this skill works against a checkout if one happens to exist, and clones into the
+session scratchpad otherwise.
+
+## The repos
+
+- `getsentry/sentry`: the main app, our biggest SDK consumer
+- `getsentry/gib-potato`: internal Vue app
+- `getsentry/sentry-changelog`: Next.js site
+- `getsentry/sentry-docs`: Next.js site
+- `getsentry/chartcuterie`: Node chart rendering service
+
+Bump all of them unless the user named a subset.
+
+## Step 1: survey the repos
+
+Read the current state over the API first, so nothing is cloned before you know what
+each repo needs. Per repo, collect the default branch, `packageManager`, the `scripts`,
+and every `@sentry/*` dependency with its current range:
+
+```bash
+for r in sentry gib-potato sentry-changelog sentry-docs chartcuterie; do
+  echo "## $r  base=$(gh repo view getsentry/$r --json defaultBranchRef --jq .defaultBranchRef.name)"
+  echo "  lock: $(gh api repos/getsentry/$r/contents --jq '.[].name' | grep -xE 'package-lock\.json|yarn\.lock|pnpm-lock\.yaml|bun\.lockb?' | tr '\n' ' ')"
+  gh api repos/getsentry/$r/contents/package.json --jq .content | base64 -d | node -e '
+    let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{
+      const p=JSON.parse(s), d={...p.dependencies,...p.devDependencies};
+      console.log("  pm:", p.packageManager || "none");
+      console.log("  build:", (p.scripts||{}).build || "none");
+      for (const [k,v] of Object.entries(d)) if (k.startsWith("@sentry/")) console.log(`  ${k}: ${v}`);
+    })'
+done
+```
+
+Three things to work out from that:
+
+- **Which deps to bump.** Only the ones already on the SDK version you are moving off.
+  Repos also carry `@sentry/*` packages on their own release trains
+  (`@sentry/conventions`, `@sentry/toolbar`, `@sentry/webpack-plugin`,
+  `@sentry/jest-environment`); those must not move.
+- **How each dep is ranged.** Some repos pin exactly, some use a caret, and a repo can
+  mix both. Take the prefix from the dep you are about to edit and keep it, rather than
+  applying one style across the repo or across the fleet.
+- **Which package manager actually drives the repo.** Prefer `packageManager`, and fall
+  back to the lockfile when it is absent (chartcuterie has no field and a `yarn.lock`).
+  Then check what the `scripts` invoke: a repo whose `build` runs through another tool
+  (gib-potato declares npm but builds with `vp`, from its `vite-plus` dependency) has to
+  be installed with that tool too, or its lockfile is written by the wrong thing.
+
+If a repo has no matching `@sentry/*` dep, it has nothing to bump. Say so and drop it.
+
+## Step 2: get a working tree
+
+A lockfile can only be regenerated by running the repo's package manager, so every
+selected repo needs a working tree. Resolve one per repo, in this order:
+
+1. `$SENTRY_DOGFOOD_WORKSPACE/<repo>`, if that variable is set.
+2. An existing checkout in a common parent (`~/projects`, `~/src`, `~/code`, `~/dev`, `~/workspace`)
+   whose `origin` remote matches the repo. Verify the remote, do not trust the directory name.
+3. Otherwise clone into the session scratchpad:
+
+```bash
+gh repo clone getsentry/$r "$SCRATCH/$r" -- --depth=1 --single-branch --branch $BASE
+```
+
+A checkout found this way may hold someone's uncommitted work, and `git checkout -B`
+would carry it onto the new branch. Run `git status --porcelain` first; if it comes back
+non-empty, leave that checkout untouched and clone into the scratchpad instead. Never
+stash or discard work you did not create.
+
+Note in the final report which repos were cloned fresh and which reused a checkout.
+
+## Step 3: branch and bump
+
+One branch name across all repos, `<gh-login>/bump-sentry-<version-slug>`, matching the
+`<user>/<topic>` convention these repos already use. Take the login from `gh`, never
+hardcode a set of initials:
+
+```bash
+BRANCH="$(gh api user --jq .login)/bump-sentry-<slug>"   # e.g. jane/bump-sentry-11-beta-0
+```
+
+Always branch off a **freshly fetched** base, never off whatever the checkout was left on
+last time.
+
+Anchor the version replacement on the **old version string** so only the deps identified in
+step 1 move, and preserve each existing range prefix:
+
+```bash
+cd "$DIR"                      # resolved in step 2
+git fetch origin $BASE --quiet
+git checkout -B "$BRANCH" origin/$BASE
+
+# node, not `sed -i`, whose in-place flag differs between BSD and GNU
+node -e '
+  const fs = require("fs"), [from, to] = process.argv.slice(1);
+  fs.writeFileSync("package.json",
+    fs.readFileSync("package.json", "utf8").split(`${from}"`).join(`${to}"`));
+  JSON.parse(fs.readFileSync("package.json", "utf8"));   // still valid JSON
+' '<old-version>' '<version>'
+
+git diff package.json
+```
+
+## Step 4: install, build, and adapt
+
+Install with the package manager identified in step 1. How far to go depends on what the
+working tree cost you.
+
+**Reused checkout:** `node_modules` is already warm, so do a full install, then run the
+repo's own build script (and its typecheck script, where it has one).
+
+**Fresh clone:** a full install from cold is slow, and the draft PR's own CI is the real
+gate anyway. Updating the lockfile is enough:
+
+- pnpm: `pnpm install --lockfile-only`
+- npm: `npm install --package-lock-only`
+- yarn 1 has no lockfile-only mode, so it needs a plain `yarn install`
+- anything else: use its normal install and accept the full cost
+
+Say plainly in the report which repos were verified only by CI.
+
+Either way, confirm the lockfile diff is Sentry-only, version moves and nothing else.
+Unrelated entries mean the wrong package manager ran, so reset the lockfile and redo the
+install rather than committing the churn.
+
+### Adapting the consumer
+
+A major or prerelease bump is meant to break things. Finding that breakage and fixing it
+is the job, not a detour from it, so budget for code changes beyond the version numbers.
+
+**Read `MIGRATION.md` for the range you are crossing** before you start guessing at
+errors. It is in `sentry-javascript`, and covers removed options, moved exports and
+renamed build options. Note that a repo two or more prereleases behind crosses every
+change in between, not just the newest one.
+
+**Run the typecheck as well as the build.** They fail on different things, and a build
+that compiles can still be hiding type errors in files it does not check.
+
+**Check build config separately.** `next.config.*`, vite configs and the like are the
+blind spot: they are often plain JavaScript, or typechecked under a module resolution
+that cannot see the SDK's types, so a removed option sits there silently doing nothing
+instead of erroring. Grep the config for every option name the guide lists as removed or
+renamed, rather than trusting a green build.
+
+**Confirm a failure is yours before chasing it.** Re-run the same command on the base
+branch without the bump. Consumer repos fail for their own reasons (a missing env var, a
+broken hook, a full disk), and attributing those to the SDK wastes the run.
+
+**Report anything the guide missed.** A breaking change you had to reverse-engineer from
+a type error is the most valuable thing this exercise produces. Say so explicitly, and
+open a migration-guide PR against `sentry-javascript`.
+
+## Step 5: commit, push, PR
+
+One commit per repo. Match each repo's own commit convention, which you can read off its
+log (`git log origin/$BASE --oneline -20`); they differ (`chore(deps):`, `build(deps):`,
+`build(js):`, plain `chore:`).
+
+Open every PR as a **draft**, `## What` / `## Why` only. When the bump needed code
+changes, say what they were and why the new version required them, so a reviewer who does
+not follow the SDK can tell the adaptation apart from the version numbers:
+
+```bash
+gh pr create --draft --base $BASE \
+  --title "<commit subject>" \
+  --body "## What
+
+Update \`@sentry/x\` to <version>.
+
+## Why
+
+Keep <repo> on the latest v11 prerelease so we catch breaking changes early."
+```
+
+## Report back
+
+A short table: repo, PR link, how it was verified (local build or CI only), and what
+needed adapting. Call out any install or build that failed, and list separately any
+breaking change that was not in `MIGRATION.md`, with the migration-guide PR that fixes
+that.
+
+Delete scratchpad clones once their PRs are open.

agents.toml

@@ -89,3 +89,7 @@ source = "path:.agents/skills/write-tests"
 [[skills]]
 name = "port-span-names"
 source = "path:.agents/skills/port-span-names"
+
+[[skills]]
+name = "dogfood-release"
+source = "path:.agents/skills/dogfood-release"