[pull] main from tw93:main

.agents/skills/code-review/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: code-review
+description: Pake project adapter for Waza check/code-review. Use for TypeScript CLI, Rust/Tauri, release artifact, and CI review.
+version: 1.2.0
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+disable-model-invocation: true
+---
+
+# Pake Code Review Adapter
+
+Use Waza `/check` for the generic review method. This adapter adds Pake-specific commands, hard stops, and artifact rules.
+
+## Pake-Specific Hard Stops
+
+- [ ] Changes under `bin/` rebuild and commit `dist/cli.js` with `pnpm run cli:build`.
+- [ ] Changes to package metadata embedded by Rollup (`package.json` name/version/repository/bin/scripts/exports) rebuild and commit `dist/cli.js`.
+- [ ] Release version bumps keep `package.json`, `src-tauri/Cargo.toml`, `src-tauri/Cargo.lock`, and `src-tauri/tauri.conf.json` in sync.
+- [ ] npm release workflow changes preserve Trusted Publishing: `.github/workflows/npm-publish.yml`, `id-token: write`, canonical `git+https://github.com/tw93/Pake.git`, and `scripts/check-release-version.mjs`.
+- [ ] Release/status changes keep npm registry, GitHub Release/assets, workflow run state, and issue closeout as separate truth surfaces.
+- [ ] `workflow_dispatch` release logic does not infer the release tag from `headBranch`, run title, or compare UI; use an explicit tag/ref and verify the package `gitHead`.
+- [ ] No new `tauriConf: any` or other untyped config objects; use `PakeTauriConfig`.
+- [ ] No user-reachable `panic!` or `.unwrap()` on config, CLI, or event paths.
+- [ ] Silent `catch {}` blocks surface the real error through `logger.warn`.
+- [ ] New helper in `bin/utils/` or `bin/helpers/` has a matching `tests/unit/<basename>.test.ts`.
+- [ ] Binary parsers have a round-trip test, not only builder assertions.
+- [ ] Linux WebKit/AppImage runtime flag changes keep the default conservative, add or update tests for the decision logic, and update `docs/faq*.md` when users need a fallback command.
+- [ ] macOS `--new-window` or auth URL changes include targeted tests for popup/auth routing in `src-tauri/src/inject/event.js`.
+
+## Quick Review Commands
+
+```bash
+# Get PR diff
+gh pr diff
+
+# Format check
+pnpm run format:check
+
+# Run unit tests (fast, sub-second)
+npx vitest run
+
+# Full suite without the slow real build
+pnpm test -- --no-build
+
+# Build CLI and catch TypeScript errors
+pnpm run cli:build
+```
+
+## Review Output Format
+
+Follow Waza `/check`: findings first, ordered by severity, with tight file/line references. Keep summaries brief.

.agents/skills/github-ops/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: github-ops
+description: GitHub issue, PR, and release operations via gh CLI. Not for code review or release builds.
+version: 1.1.0
+allowed-tools:
+  - Bash
+  - Read
+---
+
+# GitHub Operations Skill
+
+Use this skill when working with GitHub issues, PRs, and releases for Pake.
+
+## Golden Rule
+
+**ALWAYS use `gh` CLI** for GitHub operations. Never use the web UI or make assumptions about state — always query first.
+
+## Issue Operations
+
+```bash
+# View a specific issue
+gh issue view 123
+
+# List open issues
+gh issue list --state open
+
+# List issues with a label
+gh issue list --label bug
+
+# Add a comment (only with explicit user request)
+gh issue comment 123 --body "..."
+
+# Close an issue
+gh issue close 123
+```
+
+## PR Operations
+
+```bash
+# List open PRs
+gh pr list
+
+# View a PR
+gh pr view 456
+
+# Check PR status and CI checks
+gh pr checks 456
+
+# View PR diff
+gh pr diff 456
+
+# Read inline review comments on a PR
+gh api repos/tw93/Pake/pulls/456/comments
+
+# Merge a PR (only with explicit user request)
+gh pr merge 456 --squash
+
+# Create a PR
+gh pr create --title "..." --body "..."
+```
+
+## Release Operations
+
+```bash
+# List releases
+gh release list
+
+# View a specific release
+gh release view V3.10.0
+
+# Check CI runs for a tag
+gh run list --workflow=release.yml
+gh run list --workflow=npm-publish.yml
+
+# Watch a running CI job
+gh run watch
+
+# View CI run logs
+gh run view <run-id> --log
+
+# Verify npm registry state after publish
+npm view pake-cli version
+npm view pake-cli@<version> dist.tarball
+```
+
+## CI / Workflow Operations
+
+```bash
+# List recent workflow runs
+gh run list
+
+# Filter by workflow
+gh run list --workflow=release.yml
+gh run list --workflow=quality-and-test.yml
+
+# Re-run failed jobs
+gh run rerun <run-id> --failed-only
+```
+
+## Safety Rules
+
+1. **ALWAYS** draft the reply first and show it to the user for approval before calling any write operation (`gh issue comment`, `gh pr comment`, `gh pr merge`, `gh issue close`, `gh release create`, etc.). Approval of one draft does not extend to future comments.
+2. **NEVER** merge, close, or modify without explicit user request.
+3. **ALWAYS** query current state before taking action — never assume.
+4. Before replying to an issue or PR, read the body to confirm the author's language; match their language in the reply. This applies to the author, not to arbitrary thread commenters.
+5. Before replying that a fix is released, verify the public artifact first: `npm view pake-cli version` for CLI releases or `gh release view <tag>` for app releases.
+6. Before closing an issue after release, confirm the target with `gh issue view <id> --json number,title,state,author,url` and include the concrete version or upgrade command in the comment.

.agents/skills/release/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: release
+description: Prepare, validate, and publish a Pake release. Not for version bumps without release intent.
+version: 1.1.0
+allowed-tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
+disable-model-invocation: true
+---
+
+# Release Skill
+
+Use this skill when preparing or executing a Pake release.
+
+## Version Files
+
+Four files must be updated in sync — never update one without the others:
+
+- `package.json` → `"version"`
+- `src-tauri/Cargo.toml` → `version` under `[package]`
+- `src-tauri/Cargo.lock` → `version` for package `pake`
+- `src-tauri/tauri.conf.json` → `"version"`
+
+## Release Checklist
+
+### Pre-Release
+
+1. [ ] Confirm the new version number (check current: `cat package.json | jq .version`)
+2. [ ] Confirm the version is not already on npm: `npm view pake-cli@X.Y.Z version` should return 404 before publishing
+3. [ ] Update all four version files above
+4. [ ] Run `pnpm run format` — must pass cleanly
+5. [ ] Run `pnpm test` — must pass cleanly. If the release workflow step fails with `pnpm install ... exit code 1` against the CN mirror, re-run once; a single transient flake is acceptable, two consecutive failures is not.
+6. [ ] Run `pnpm run cli:build` — Rollup + TS must pass (catches type errors that `format` misses).
+7. [ ] Run `pnpm run release:check` — verifies version sync, package contents, and npm dry-run
+8. [ ] No uncommitted changes: `git status`
+9. [ ] Commit version bump with message: `chore: bump version to VX.X.X`
+
+### Tagging (triggers CI)
+
+```bash
+git tag -a VX.X.X -m "Release VX.X.X"
+git push origin VX.X.X
+```
+
+Tag format: uppercase `V` prefix (e.g. `V3.11.0`), not `v3.11.0`.
+
+### Post-Tag Verification
+
+1. [ ] Confirm CI triggered: `gh run list --workflow=release.yml`
+2. [ ] Watch CI status: `gh run watch`
+3. [ ] Verify GitHub Release was created: `gh release view VX.X.X --json tagName,url,assets`
+4. [ ] Confirm npm workflow exists and is active: `gh workflow list --all | grep "Publish npm Package"`
+5. [ ] Confirm npm Trusted Publishing triggered: `gh run list --workflow=npm-publish.yml`
+6. [ ] Verify npm published the exact package: `npm view pake-cli@X.Y.Z version gitHead dist.tarball --json`
+7. [ ] Verify latest now resolves to the release: `npm view pake-cli version`
+8. [ ] Record Quality & Testing status separately: `gh run list --workflow=quality-and-test.yml --limit 3`
+
+npm publishes through Trusted Publishing from `.github/workflows/npm-publish.yml`. Configure npm package settings with GitHub Actions, `tw93/Pake`, workflow file `npm-publish.yml`, and no environment. Local `npm publish` is only a fallback if CI or registry state blocks the trusted path.
+
+Keep release surfaces separate in the final status:
+
+- npm registry: the authority for `pake-cli` installability and CLI/npm issue closeout.
+- GitHub Release/assets: the authority for app installers and popular-app artifact availability.
+- Quality workflow: the authority for post-push CI health, but it can continue after npm has already shipped.
+- Source/tag: the authority for what code was intended to ship.
+
+Do not collapse these into "released" without naming which surface was verified. If GitHub Release assets are visible while `gh run list` still reports the release workflow as queued or in progress, trust `gh release view` for asset state and report the workflow state separately.
+
+## Trusted Publishing Notes
+
+- The first real Trusted Publishing test must use a new version and a new `V*` tag; do not retry an already-published version.
+- npm package settings should use the strict publishing option: require two-factor authentication and disallow tokens. Trusted Publishing still works with this setting.
+- If local fallback is unavoidable, prefer `npm exec --yes --package=pnpm@10.26.2 -- npm publish --registry=https://registry.npmjs.org` so `prepublishOnly` can find the pinned pnpm version.
+- Do not reply to GitHub issues or close them as released until `npm view pake-cli@X.Y.Z version` returns the expected version. `npm view pake-cli version` alone is not enough because `latest` can point at a different commit than the fix under review.
+- A `workflow_dispatch` run may execute on `main`; do not treat `headBranch`, run title, or compare UI as the release tag. Check the pushed tag and published package `gitHead`.
+- If CI creates `chore: update contributors [skip ci]` after the tag is pushed, fast-forward local `main` after the release. Do not retag just to include generated contributor art.
+
+## Build Commands (local only)
+
+```bash
+# Current platform
+pnpm build
+
+# macOS universal binary
+pnpm build:mac
+```
+
+Cross-platform builds (Windows/Linux) are handled by CI, not locally.
+
+## Safety Rules
+
+1. **NEVER** auto-commit or auto-push without explicit user request
+2. **NEVER** tag before all checks pass
+3. **ALWAYS** verify the four version files are in sync before tagging