diff --git a/.claude/skills/build/SKILL.md b/.claude/skills/build/SKILL.md new file mode 100644 index 0000000..7ecd711 --- /dev/null +++ b/.claude/skills/build/SKILL.md @@ -0,0 +1,40 @@ +--- +name: build +description: Build the TW-Calc userscript and copy it to the clipboard for testing (paste into Tampermonkey). Use when the user wants to build the script, copy the userscript, or test a change in-game. +--- + +# /build — build the userscript and copy it to the clipboard + +Builds `dist/TW_Calc.user.js` and puts it on the clipboard so it can be pasted straight into Tampermonkey for in-game testing (see `CONTRIBUTING.md` → "Building"). + +`$ARGUMENTS`: + +- empty or `dev` → **dev build** (default): faster, not minified, debug logs enabled — use this for testing. +- `prod` → production build: minified, slower; use only to sanity-check the shipped artifact. + +## Steps + +### 1. Build + copy + +Dev (default) — this is exactly the repo's `build:dev:copy-script` script: + +```shell +npm run build:dev:copy-script +``` + +Prod (when `$ARGUMENTS` is `prod`): + +```shell +npm run build && pbcopy < dist/TW_Calc.user.js +``` + +`pbcopy` is macOS-only (this repo's convention). On Linux substitute `xclip -selection clipboard` or `wl-copy`; on Windows `clip`. + +### 2. Report + +Confirm the build succeeded and the script is on the clipboard, and remind to paste it into Tampermonkey and reload the game. Mention the artifact path (`dist/TW_Calc.user.js`) and the build type used. If the build failed, surface the error instead of claiming it was copied. + +## Notes + +- For testing prefer the **dev** build — debug logs can also be turned on via `?tw-calc--debug=true` in the URL or `localStorage.setItem("TWCalc_DEBUG", "1")`. +- `dist/` is git-ignored, so this never affects the working tree. diff --git a/.claude/skills/new-version/SKILL.md b/.claude/skills/new-version/SKILL.md new file mode 100644 index 0000000..ea4a570 --- /dev/null +++ b/.claude/skills/new-version/SKILL.md @@ -0,0 +1,78 @@ +--- +name: new-version +description: Cut and ship a new TW-Calc release — pick the semver bump, run the gates, version + tag, push, and shepherd the draft GitHub release through publish/deploy. Use when the user wants to release, ship, cut a version, or bump the version. +--- + +# /new-version — release a new version + +Releases follow the process documented in `CONTRIBUTING.md` ("Releasing"). The pipeline is: + +1. `npm version` bumps `package.json`, commits `vX.Y.Z`, and tags `vX.Y.Z`. +2. Pushing the tag triggers **CI** (`.github/workflows/ci.yml`). On `refs/tags/v*` the `release` job builds `dist/TW_Calc.user.js` and creates a **draft** GitHub release with the userscript attached. +3. A human edits the draft with release notes and **publishes** it. +4. Publishing triggers **Deploy** (`.github/workflows/deploy.yml`), which pushes the update to users (in-game dialog). + +`$ARGUMENTS` may be an explicit version (`2.12.0`) or a bump type (`patch` | `minor` | `major`). If empty, propose one from the commits since the last tag. + +## Steps + +### 1. Preflight (stop if any fails) + +- Be on the default branch and up to date: `git checkout main && git fetch origin && git status -sb`. The working tree MUST be clean and not behind `origin/main` (fast-forward first if it is). +- Confirm CI is green on `main` before releasing — don't tag a broken main. + +### 2. Decide the version + +- Current version: read `version` from `package.json`. Latest tag: `git tag --sort=-v:refname | head -1`. +- List changes since the last tag: `git log ..HEAD --oneline`. +- Apply semver per `CONTRIBUTING.md`: + - any `feat:` → **minor** + - only `fix:` / `refactor:` / `perf:` / `chore:` / `docs:` / `style:` / `test:` / `ci:` → **patch** + - a breaking change (`!` or `BREAKING CHANGE`) → **major** +- If `$ARGUMENTS` gave an explicit version or bump type, use it. Otherwise state the proposed version + the reason and **confirm with the user before bumping** (it creates a tag). + +### 3. Local gates (fail fast before tagging — CI runs these too) + +```shell +npm run lint && npm run tsc && npm test && npm run build +``` + +All must pass. `npm run build` proves the production bundle compiles (CI's `build`/`release` jobs depend on it). + +### 4. Version + tag + +Use the documented command (note the `v%s` message format that matches the tag history): + +```shell +npm version -m "v%s" # e.g. npm version -m "v%s" 2.11.4 +``` + +This makes the `vX.Y.Z` commit and tag on `main`. (You can also pass `patch`/`minor`/`major` instead of an explicit version.) + +### 5. Push commit + tag + +```shell +git push --follow-tags # pushes the vX.Y.Z commit and its tag +``` + +(Equivalent fallback: `git push && git push --tags`.) + +### 6. Wait for the draft release + +- The tag push starts CI. Watch it: `gh run watch` (or `gh run list --branch `). The `release` job only runs on `refs/tags/v*` and needs `build` to pass. +- When CI is green, a **draft** release `Release refs/tags/vX.Y.Z` appears with `TW_Calc.user.js` attached: `gh release view vX.Y.Z`. +- If CI fails, diagnose and fix on `main`; you may need to delete the tag (`git push origin :refs/tags/vX.Y.Z` and `git tag -d vX.Y.Z`), fix, and re-tag. + +### 7. Release notes + publish — CONFIRM FIRST + +- Draft notes from `git log .. --oneline`, grouped by type (Features / Fixes / Other). Offer to set them: `gh release edit vX.Y.Z --notes "…" --title "vX.Y.Z"`. +- **Publishing deploys to all users.** Do NOT publish autonomously — present the notes and get explicit user approval. On approval: `gh release edit vX.Y.Z --draft=false`. + +### 8. Deploy + +- Publishing triggers `.github/workflows/deploy.yml`. Confirm it succeeds: `gh run list --workflow=Deploy`. Report the result; the rollout reaches users via the in-game update dialog. + +## Guardrails + +- Never tag/push/publish without the working tree clean and on an up-to-date `main`. +- Treat tag push and especially release publish as outward-facing — confirm the version (step 2) and the publish (step 7) with the user before doing them.