chore: sync shared ai prompts

.agents/skills/.gitignore

@@ -0,0 +1,2 @@
+# Generated by sync-ai-skills.sh.
+# Keep this file so the directory exists even when no commands are synced yet.

.agents/skills/open-pr/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: open-pr
+description: "Prepare the current worktree branch for a pull request: rebase, self-review, quality checks, and open a draft PR."
+---
+
+# Open PR
+
+Prepare the current worktree branch for a pull request: rebase,
+self-review, quality checks, and open a draft PR.
+
+## Instructions
+
+1. **Verify you are on an isolated feature branch**:
+
+   ```bash
+   CURRENT=$(git branch --show-current)
+   if [ -z "$CURRENT" ] || [ "$CURRENT" = "main" ] || [ "$CURRENT" = "master" ]; then
+     echo "Error: /open-pr must run from an active feature branch."
+     exit 1
+   fi
+   ```
+
+   If on a default branch or detached HEAD, abort and ask the
+   user which feature branch to use.
+
+   Check whether the current checkout is safe to use for PR prep:
+
+   ```bash
+   git status --short
+   ```
+
+   If the checkout is the user's shared root checkout, has
+   unrelated local changes, or the work spans multiple repos or
+   submodules, stop and move to clean worktree(s) before rebasing
+   or committing. Create the worktree from the current feature
+   branch and continue the rest of this skill there; do not
+   rewrite history in the dirty root checkout.
+
+2. **Bootstrap the worktree before trusting failures**:
+
+   Before running lint, typecheck, tests, or hooks, verify that
+   the worktree actually has the repo toolchain available
+   (`bun`, workspace dependencies, `turbo`, `oxlint`, project
+   bins, and env links if the repo expects them).
+
+   If the worktree is missing the toolchain, run the repo's
+   normal install/setup flow first, then rerun the same command.
+   Do not treat missing-bin or module-resolution failures as
+   product-code regressions. Keep setup-only churn such as
+   accidental lockfile changes out of the PR unless the task
+   explicitly requires them.
+
+3. **Rebase onto the remote default branch**:
+
+   ```bash
+   DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's@^origin/@@')"
+   if [ -z "$DEFAULT_BRANCH" ]; then
+     DEFAULT_BRANCH="$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 2>/dev/null)"
+   fi
+   if [ -z "$DEFAULT_BRANCH" ]; then
+     DEFAULT_BRANCH="main"
+   fi
+
+   git fetch origin "$DEFAULT_BRANCH"
+   git rebase "origin/$DEFAULT_BRANCH"
+   ```
+
+   If conflicts arise, resolve them. After resolving, continue
+   the rebase. If a conflict is ambiguous, ask the user.
+
+4. **Self-review against CLAUDE.md conventions**:
+
+   Get the full diff against the default branch:
+
+   ```bash
+   git diff "origin/$DEFAULT_BRANCH" --name-only
+   ```
+
+   Read every changed file in full. Review against the
+   conventions in CLAUDE.md (TypeScript strictness, error
+   handling, security, naming, i18n, patterns). Fix any
+   violations directly; don't just list them. Commit fixes
+   separately with `fix: address self-review findings`.
+
+5. **Run quality checks using the repo's actual commands**:
+
+   Run the checks the repository already defines for linting,
+   typechecking, tests, and non-mutating format verification.
+   If the repo defines `format:check`, use it. If it only
+   defines a mutating `format` script, do not run it as
+   verification unless you also commit the formatter output.
+   Prefer documenting a missing format check in the PR body over
+   inventing a one-off command that is inconsistent with the repo.
+
+   If any check fails, fix the issue and re-run. Commit fixes
+   with `fix: lint/format/type errors`.
+
+6. **Security audit**:
+
+   Run `/security-audit`. Fix any critical or high findings
+   in files changed in this PR before opening it.
+   Commit fixes with `fix: address security audit findings`.
+
+7. **Open the PR as draft**:
+
+   Push the branch and create the PR as a **draft**:
+
+   ```bash
+   git push --force-with-lease -u origin HEAD
+   gh pr create --fill --draft
+   ```
+
+   If `--fill` produces a poor title/body, write a proper one
+   following Conventional Commits (`feat:`, `fix:`, etc.) with
+   a very concise summary. Do not add a separate test plan unless
+   the user explicitly asks for one. Do not mention deployment
+   choices or attribute the motivation for the PR to a specific
+   person's feedback, request, or experience.
+
+   This repository is public. Never include marketing language,
+   internal business context, pricing, competitive analysis,
+   user identities, conversation specifics, deployment specifics,
+   or security architecture beyond what the diff obviously shows.
+   Do not add details that would help a motivated attacker exploit
+   the code, especially a vulnerable previous version being fixed.
+   Assume the PR may be read by hostile adversaries, not only
+   friendly collaborators. When sensitive context would improve
+   readability, omit it by default; ask the user only if omission
+   would make the PR hard to review.

.agents/skills/plan/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: plan
+description: 'Create a new implementation plan in the repo''s planning area.'
+---
+
+# Create Plan
+
+Create a new implementation plan in the repo's planning area.
+
+## Arguments
+
+$ARGUMENTS — A short slug for the plan, ideally kebab-case. If empty,
+derive a reasonable slug from the task.
+
+## Conventions
+
+Prefer this shared planning layout when the repo supports it:
+
+```text
+.agents/ARCHITECTURE.md
+.agents/GOALS.md
+.agents/STATUS.md
+.agents/plans/
+```
+
+If the repo uses a different planning area, adapt to it rather than
+creating duplicate systems.
+
+## Instructions
+
+1. **Read planning context**:
+   - `.agents/ARCHITECTURE.md` if present
+   - `.agents/GOALS.md` if present
+   - recent related plans if present
+
+2. **Determine the plan location**:
+   - prefer `.agents/plans/`
+   - if that directory does not exist, create it only if the repo is
+     clearly adopting the shared planning convention
+   - otherwise ask or use the repo's existing planning area
+
+3. **Determine the next plan number**:
+
+   ```bash
+   ls .agents/plans/
+   ```
+
+   Use the next sequential number when numbered plans are already in use.
+   If the repo does not number plans, follow its established naming.
+
+4. **Research before writing**:
+   - inspect the existing code
+   - read the relevant modules
+   - understand constraints, patterns, and likely blast radius
+
+5. **Write the plan** with this structure:
+
+   ```markdown
+   # Plan: [Feature Name]
+
+   Date: YYYY-MM-DD
+
+   ## Goal
+
+   What are we building and why?
+
+   ## Design Decisions
+
+   - **Decision**: Why this approach over alternatives.
+
+   ## Scope
+
+   **In scope:**
+   - ...
+
+   **Out of scope:**
+   - ...
+
+   ## Implementation
+
+   - `path/to/file` — what changes here
+
+   ## Test Cases
+
+   What needs to be verified.
+
+   ## Open Questions
+
+   Any unresolved decisions.
+   ```
+
+6. **Plan well, do not over-specify**:
+   - focus on _what_ and _why_
+   - avoid locking in incidental implementation details too early
+   - call out migrations, security implications, and rollout risk when relevant
+
+7. **Confirm before finalizing** if the user is still shaping the task.
+   If they asked you to just create the plan, go ahead and write it.

.agents/skills/product-think/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: product-think
+description: 'Shape a feature or problem before implementation. Use this when the request is still fuzzy, when several solutions are possible, or when execution risks outrunning product clarity.'
+---
+
+# Product Think
+
+Shape a feature or problem before implementation. Use this when the
+request is still fuzzy, when several solutions are possible, or when
+execution risks outrunning product clarity.
+
+## Arguments
+
+$ARGUMENTS — Feature idea, problem statement, or change request.
+
+## Instructions
+
+1. **Clarify the problem first**:
+   - who is affected?
+   - what pain or friction exists today?
+   - why does it matter now?
+
+2. **Separate problem from solution**:
+   - write down the user need
+   - write down the proposed solution
+   - check whether the solution actually addresses the need
+
+3. **Define outcome, not just output**:
+   - what should be better if this works?
+   - what user or business behavior should change?
+
+4. **State constraints**:
+   - technical constraints
+   - organizational constraints
+   - compliance or trust constraints
+   - timeline constraints
+
+5. **Explore options**:
+   - simplest viable option
+   - stronger but more expensive option
+   - what not to build yet
+
+6. **Make tradeoffs explicit**:
+   - speed vs correctness
+   - breadth vs depth
+   - automation vs control
+   - flexibility vs clarity
+
+7. **Define scope**:
+   - in scope
+   - out of scope
+   - follow-up ideas that should not block the first version
+
+8. **Define success**:
+   - what would we measure?
+   - what would we observe qualitatively?
+   - what would count as failure?
+
+9. **Produce a short product brief** in prose or markdown, with:
+   - problem
+   - user
+   - goal
+   - options considered
+   - recommendation
+   - risks
+   - success signal
+
+10. **Only move to implementation planning after this is coherent**.

.agents/skills/rabbit-round/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: rabbit-round
+description: 'Process automated PR review comments systematically. Use this for CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.'
+---
+
+# Rabbit Round
+
+Process automated PR review comments systematically. Use this for
+CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.
+
+## Instructions
+
+1. **Get context**:
+
+   ```bash
+   PR_NUMBER=$(gh pr view --json number -q '.number')
+   gh api user --jq '.login'
+   git rev-parse HEAD
+   ```
+
+2. **Fetch review comments** from the PR:
+
+   ```bash
+   gh api repos/{owner}/{repo}/pulls/"$PR_NUMBER"/comments --paginate
+   ```
+
+   Filter for known bot accounts. Do not treat human review comments as bot comments.
+
+3. **Triage each bot comment**:
+   - **Accept** if it improves correctness, safety, maintainability, or follows repo conventions.
+   - **Push back** if it is incorrect, overreaching, or conflicts with documented conventions.
+
+4. **Implement accepted suggestions**:
+   - make the code changes
+   - group related fixes logically
+   - run the relevant project checks
+
+5. **Reply inline** to each bot comment:
+
+   ```bash
+   COMMENT_ID="123456789"
+   gh api -X POST repos/{owner}/{repo}/pulls/"$PR_NUMBER"/comments/"$COMMENT_ID"/replies \
+     -f body="[response]"
+   ```
+
+   Good response patterns:
+   - accepted and implemented
+   - agreed, implemented with a small adjustment
+   - already addressed in commit `{hash}`
+   - pushing back, with a concrete reason and source or repo convention
+
+6. **Never resolve human review threads**. For bot threads, resolve only after:
+   - the change is implemented, or
+   - the pushback is clearly documented
+
+7. **Check nit-level comments too**. Small ones still matter if they improve clarity
+   or remove avoidable friction.
+
+8. **Commit and push** if you made changes:
+   - use a neutral commit message such as `fix: address review comments`
+   - push to the active PR branch
+
+## Decision Guidelines
+
+**Accept when the suggestion:**
+- fixes a bug or real edge case
+- improves type safety
+- adds missing tests
+- aligns with existing repo patterns
+- tightens security or validation appropriately
+
+**Push back when the suggestion:**
+- assumes facts not true in this codebase
+- conflicts with canonical specs or official sources
+- adds complexity for little benefit
+- would undo a deliberate, documented decision
+- is purely stylistic and inconsistent with the repo