{"owner":"CherryHQ","repo":"cherry-studio","hasSkills":true,"totalSkillsCount":129,"totalTokensCount":60046,"categories":["anthropic-skill","claude-rule","plugin-manifest","subagent-persona"],"hasMcp":true,"mcpConfig":{"mcpServers":{"cherry-studio":{"command":"npx","args":["-y","@modelcontextprotocol/server-cherry-studio"]}}},"found":[".agents/skills/gh-create-pr/SKILL.md",".agents/skills/create-skill/SKILL.md",".agents/skills/vercel-react-best-practices/SKILL.md",".agents/skills/gh-create-issue/SKILL.md",".agents/skills/gh-pr-review/SKILL.md",".agents/skills/prepare-release/SKILL.md","resources/builtin-agents/cherry-assistant/.claude/skills/skills-manager/SKILL.md","resources/builtin-agents/cherry-assistant/.claude/skills/issue-reporter/SKILL.md","resources/builtin-agents/cherry-assistant/.claude/skills/faq-collector/SKILL.md","resources/skills/find-skills/SKILL.md","resources/skills/skill-creator/SKILL.md","resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md","CLAUDE.md",".claude/skills/.gitignore",".claude/skills/README.md",".claude/skills/README.zh.md",".agents/skills/README.md",".agents/skills/README.zh.md","packages/extension-table-plus/CHANGELOG.md","packages/extension-table-plus/CHANGELOG-OLD.md","packages/extension-table-plus/package.json","packages/extension-table-plus/README.md","packages/extension-table-plus/tsconfig.json","packages/aiCore/CHANGELOG.md","packages/aiCore/package.json","packages/aiCore/README.md","packages/aiCore/tsconfig.json","packages/ai-sdk-provider/CHANGELOG.md","packages/ai-sdk-provider/package.json","packages/ai-sdk-provider/README.md","packages/ai-sdk-provider/tsconfig.json",".agents/skills/vercel-react-best-practices/AGENTS.md",".agents/skills/vercel-react-best-practices/README.md","docs/en/references/app-upgrade.md","docs/en/references/feishu-notify.md","docs/en/references/fuzzy-search.md","docs/zh/references/app-upgrade.md","docs/zh/references/code-execution.md","docs/zh/references/database.md","docs/zh/references/feishu-notify.md","docs/zh/references/fuzzy-search.md","docs/zh/references/lan-transfer-protocol.md","docs/zh/references/message-system.md","docs/zh/references/services.md",".agents/skills/gh-create-pr/agents/openai.yaml",".agents/skills/gh-pr-review/references/checklist-evolution.md",".agents/skills/gh-pr-review/references/code-checklist.md",".agents/skills/gh-pr-review/references/diagnosis.md",".agents/skills/gh-pr-review/references/doc-checklist.md",".agents/skills/gh-pr-review/references/judgment-matrix.md",".agents/skills/gh-pr-review/references/local-review.md",".agents/skills/gh-pr-review/references/pr-review.md",".agents/skills/gh-pr-review/references/teams-review.md",".agents/skills/gh-pr-review/agents/openai.yaml",".agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md",".agents/skills/vercel-react-best-practices/rules/advanced-init-once.md",".agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md",".agents/skills/vercel-react-best-practices/rules/async-api-routes.md",".agents/skills/vercel-react-best-practices/rules/async-defer-await.md",".agents/skills/vercel-react-best-practices/rules/async-dependencies.md",".agents/skills/vercel-react-best-practices/rules/async-parallel.md",".agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md",".agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md",".agents/skills/vercel-react-best-practices/rules/bundle-conditional.md",".agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md",".agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md",".agents/skills/vercel-react-best-practices/rules/bundle-preload.md",".agents/skills/vercel-react-best-practices/rules/client-event-listeners.md",".agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md",".agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md",".agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md",".agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md",".agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md",".agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md",".agents/skills/vercel-react-best-practices/rules/js-cache-storage.md",".agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md",".agents/skills/vercel-react-best-practices/rules/js-early-exit.md",".agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md",".agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md",".agents/skills/vercel-react-best-practices/rules/js-index-maps.md",".agents/skills/vercel-react-best-practices/rules/js-length-check-first.md",".agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md",".agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md",".agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md",".agents/skills/vercel-react-best-practices/rules/rendering-activity.md",".agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md",".agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md",".agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md",".agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md",".agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md",".agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md",".agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md",".agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md",".agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md",".agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md",".agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md",".agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md",".agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md",".agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md",".agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md",".agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md",".agents/skills/vercel-react-best-practices/rules/rerender-memo.md",".agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md",".agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md",".agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md",".agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md",".agents/skills/vercel-react-best-practices/rules/rerender-transitions.md",".agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md",".agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md",".agents/skills/vercel-react-best-practices/rules/server-auth-actions.md",".agents/skills/vercel-react-best-practices/rules/server-cache-lru.md",".agents/skills/vercel-react-best-practices/rules/server-cache-react.md",".agents/skills/vercel-react-best-practices/rules/server-dedup-props.md",".agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md",".agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md",".agents/skills/vercel-react-best-practices/rules/server-serialization.md","docs/en/references/components/code-block-view.md","docs/en/references/components/image-preview.md","docs/zh/references/cherryclaw/channels.md","docs/zh/references/cherryclaw/mcp-claw.md","docs/zh/references/cherryclaw/overview.md","docs/zh/references/cherryclaw/scheduler.md","docs/zh/references/components/code-block-view.md","docs/zh/references/components/image-preview.md","resources/skills/skill-creator/agents/analyzer.md","resources/skills/skill-creator/agents/comparator.md","resources/skills/skill-creator/agents/grader.md","resources/skills/skill-creator/references/schemas.md","src/main/services/agents/README.md"],"skills":{".agents/skills/gh-create-pr/SKILL.md":"---\nname: gh-create-pr\ndescription: Create or update GitHub pull requests using the repository-required workflow and template compliance. Use when asked to create/open/update a PR so the assistant reads `.github/pull_request_template.md`, fills every template section, preserves markdown structure exactly, and marks missing data as N/A or None instead of skipping sections.\n---\n\n# GitHub PR Creation\n\n## Stack tooling\n\nThis repository ships `.agents/skills/gh-stack/SKILL.md` as a public project skill; developers do not install the agent skill separately. Read it before operating on stacked branches or PRs. Agents that consume `.agents/skills/` discover it directly. If a Claude checkout is missing `.claude/skills/gh-stack`, run `pnpm skills:sync` followed by `pnpm skills:check`; do not download a separate global copy.\n\nBefore the first `gh stack` command in a task, verify the GitHub CLI and install the official extension if it is missing:\n\n```bash\ncommand -v gh >/dev/null 2>&1 || {\n echo \"GitHub CLI is required: https://cli.github.com/\" >&2\n exit 1\n}\ngh auth status\nif ! gh stack --help >/dev/null 2>&1; then\n gh extension install github/gh-stack\nfi\ngh stack --help >/dev/null\n```\n\nStop if authentication, installation, or the final verification fails. Do not infer a stack with ad hoc Git commands. For human-authored Cherry PRs, use `gh stack push`, create each compliant PR through this skill from bottom to top, then link the existing PRs with `gh stack link`; `gh stack submit --auto` creates PRs outside the template-compliant body flow and must not bypass this workflow.\n\n## Workflow\n\n1. Read `.github/pull_request_template.md` before drafting the PR body.\n2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content). Resolve the live base and run `pnpm change:scope --base `; do not infer scope from the latest commit alone.\n3. Read `.agents/notes/README.md` and classify the change:\n - Fill `Agent Note` with the repository path, or `N/A — ` for a local/mechanical change.\n - For a Spec PR, fill `Spec PR: This PR` and list every AC.\n - For an implementation layer, link the Spec PR and list only the AC IDs covered by this layer. Verify an `APPROVED` review whose `commit_id` equals the current Spec head; a stale approval does not authorize implementation.\n - For a direct bug fix with durable rationale, link its implemented `bug-fix` note and use `Spec PR: N/A`.\n - Automation-authored PRs (repository workflows and Dependabot) are exempt from these metadata fields. Do not make their bodies imitate a human-authored PR.\n4. For an implementation PR, complete the stack tooling preflight, then run `gh stack view --json`. If it exits 2, follow the `gh-stack` skill's remote-discovery procedure; missing local metadata does not prove the PR is standalone. Inspect every downstack implementation PR and aggregate only ACs backed by actual verification. Keep the note proposed on intermediate layers. If the current PR is the final layer and cumulative evidence covers the complete approved Spec, move the bilingual triplet to `implemented/` and run `pnpm agent-notes:check-transition --base ` before publishing.\n5. Fill `Verification` with commands and scenarios actually run. Never present a planned, pending, skipped, or CI-only check as passed.\n6. Check if the current branch has been pushed to remote. If not, push it first:\n - Default remote is `origin`, but ask the user if they want to use a different remote.\n ```bash\n git push -u \n ```\n7. Determine the base branch:\n - Inspect the head branch before applying any default. If the head is `release/v`, stop: never open a pull request from a release branch, especially not to `main`. Put an isolated fix on a topic branch and target the release branch, or let Post Release create the metadata sync branch.\n - Before defaulting an arbitrary topic branch to `main`, inspect its merge base and upstream. A product-code fix that started from `release/v` must stop and be recreated from `main` as a hotfix; only a release-only repair or explicit backport recovery topic may target that exact release branch.\n - A `backport/v/pr-` head must target the matching `release/v` base and its body must contain `` on its own line for the exact source hotfix PR. A `release-sync/v` head must target `main`, use the exact title `chore(release): sync v metadata`, retain the `release-metadata-boundary: v` body marker, and be squash-merged.\n - For official repo(CherryHQ/cherry-studio) as `origin`: default base is `main` from `origin`, but allow the user to explicitly indicate a base branch.\n - `main` is the active development line, including hotfix PRs. Do not target an old maintenance branch unless the user explicitly requests it.\n - Only classify a PR as a release hotfix when the user explicitly says it must be included in the active draft release. Use the title `hotfix: ` or `hotfix(): ` with a lowercase alphanumeric kebab-case scope, exactly one space after the colon, and a non-empty description. The title grammar synchronizes the `hotfix` label automatically. Merging opens a separate backport PR only when exactly one draft semantic-version release has a matching active `release/v` branch; otherwise automation stops without guessing a target.\n - If the hotfix is user-facing, provide one release-note line in each language so automation can update the active draft and stable release history. Put this exact structure inside the template's existing `release-note` fence; do not include bullet prefixes:\n ```text\n \n [Component] English description.\n \n [组件] 中文说明。\n \n ```\n - If the hotfix has no user-facing release note, keep `NONE` in the template's `release-note` fence. The code is still backported, but release metadata is unchanged. A provided bilingual block must satisfy the exact structure above.\n - For fork repo as `origin`: check available remotes with `git remote -v`, default base may be `upstream/main` or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.\n - Ask the user to confirm the base branch if it's not the default.\n8. Create a temp file and write the PR body using a single Bash heredoc\n (avoids `mktemp` + `Write` tool path-mismatch on Windows):\n ```bash\n pr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\n cat > \"$pr_body_file\" <<'EOF'\n ...filled template body...\n EOF\n ```\n Fill content using the template structure exactly (keep section order,\n headings, checkbox formatting). If not applicable, write `N/A` or `None`.\n9. Inspect the temp file content via Bash `cat \"$pr_body_file\"` (the `Read`\n tool can fail on `/tmp/...` paths on Windows). If the user requests a preview\n or confirmation, show the full body and follow that request; otherwise,\n proceed with the authorized PR creation.\n10. Create the PR, adding `--draft` when the user requests a draft:\n ```bash\n gh pr create --base --head --title \"\" --body-file \"$pr_body_file\"\n ```\n For a release hotfix, use an exact classifier-compatible title so the workflow synchronizes the label and separately validates any provided bilingual note:\n ```bash\n gh pr create --base main --head <head> --title \"hotfix: <description>\" --body-file \"$pr_body_file\"\n ```\n After creation, verify that the classifier added `hotfix`; if it did not, fix the title instead of adding the label manually. Also fix any malformed optional release-note block reported by the workflow.\n11. Clean up the temp file: `rm -f \"$pr_body_file\"`\n12. Report the created PR URL and summarize title/base/head, Agent Note/Spec, AC coverage, actual verification, and any required follow-up.\n\n## Constraints\n\n- Never skip template sections.\n- Never rewrite the template format.\n- Keep content concise and specific to the current change set.\n- PR title and body must be written in English.\n- Never use a `hotfix` title or label for an ordinary bug fix. It opts the PR into an automatic backport PR after merge when one matching draft release is active.\n- A release hotfix may use `NONE` when it has no user-facing release note. Never provide a partial, single-language, or otherwise malformed bilingual note; the backport workflow fails closed on malformed content.\n- Never default a `release/v<version>` head to `main`; a release branch is not a pull request source branch.\n- Never publish an implementation PR as ready when its current Spec head lacks an exact-head Approval. A Spec may remain unmerged and serve as the stack base.\n- Every human-authored PR fills `Agent Note`, `Spec PR`, and `Acceptance criteria`; `N/A` requires a concise reason. Automation-authored PRs (repository workflows and Dependabot) are exempt from this metadata requirement.\n- **Release note & Documentation checkbox** — both are driven by whether the change is **user-facing**. Use the table below:\n\n | Change type | Release note | Docs `[x]` |\n |---|---|---|\n | New user-facing feature / setting / UI | Describe the change | ✅ |\n | Bug fix visible to users | Describe the fix | ✅ if behavior changed |\n | Behavior change / default value change | Describe + `action required` | ✅ |\n | Security fix in a user-facing dependency | Describe the fix | ✅ if usage changed |\n | CI / GitHub Actions changes | `NONE` | ❌ |\n | Internal refactoring (user cannot tell) | `NONE` | ❌ |\n | Dev / build tooling changes | `NONE` | ❌ |\n | Dev-only dependency bump | `NONE` | ❌ |\n | Test-only / code style changes | `NONE` | ❌ |\n\n## Command Pattern\n\n```bash\n# read template\ncat .github/pull_request_template.md\n\n# prepare and inspect the PR body\npr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\ncat > \"$pr_body_file\" <<'EOF'\n...filled template body...\nEOF\ncat \"$pr_body_file\"\n\n# create the authorized PR; add --draft when requested\ngh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\nrm -f \"$pr_body_file\"\n```\n",".agents/skills/create-skill/SKILL.md":"---\nname: create-skill\ndescription: Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills.\n---\n\n# Create Skill\n\nCreate a new skill in `.agents/skills/<skill-name>/` following the workflow defined in `.agents/skills/README.md`.\n\n## Workflow\n\n### Step 1: Gather Intent\n\nBefore creating anything, ask the user:\n\n1. **Skill name**: What should the skill be called? (lowercase, digits, hyphens only, e.g., `gh-create-pr`, `prepare-release`)\n2. **Description**: What should this skill do? Include specific trigger contexts (e.g., \"Use when user asks to create PRs\")\n3. **Is this a public skill?**: Should it be synced to `.claude/skills/` for shared use? (default: no, private only)\n4. **Test cases** (optional): Does the user want to set up evals for this skill?\n\nIf the user provides partial info (e.g., just a name), proceed with reasonable defaults and ask to confirm.\n\n### Step 2: Read Guidelines\n\nAlways read `.agents/skills/README.md` before creating a new skill to ensure compliance with the current workflow.\n\n### Step 3: Create Skill Structure\n\nCreate the following directory structure:\n\n```\n.agents/skills/<skill-name>/\n└── SKILL.md\n```\n\n**SKILL.md template:**\n\n```markdown\n---\nname: <skill-name>\ndescription: <description>\n---\n\n# <Skill Name>\n\n[Instructions for the skill]\n```\n\n**Frontmatter fields:**\n- `name`: Skill identifier (lowercase, digits, hyphens)\n- `description`: When to trigger (what the skill does + specific contexts)\n\n### Step 4: Sync (if public)\n\nIf the user wants a **public skill**, before validation:\n\n1. Add the skill name to `.agents/skills/public-skills.txt` (one per line, no inline comments)\n2. Run sync:\n ```bash\n pnpm skills:sync\n ```\n\nThis creates a symlink at `.claude/skills/<skill-name>/` pointing to `.agents/skills/<skill-name>/`.\n\n**Note**: `pnpm skills:check` primarily validates public skills (those in `public-skills.txt`) and also verifies related governance files, so you must sync first before validating.\n\n### Step 5: Validate\n\nRun the validation command:\n\n```bash\npnpm skills:check\n```\n\nIf there are issues, fix them and re-run.\n\n### Step 6: Summary\n\nPresent the user with:\n- Created files\n- Validation result\n- Next steps (how to use the skill)\n\n## Naming Rules\n\n- Use lowercase letters, digits, and hyphens only\n- Prefer short, action-oriented names (e.g., `gh-create-pr`)\n\n## Public vs Private Skills\n\n| Type | Location | Sync | Requires |\n|------|----------|------|----------|\n| Private | `.agents/skills/` | No | Just create the folder |\n| Public | Both | Yes | Add to `public-skills.txt` + run `pnpm skills:sync` |\n\n## Commands Reference\n\n```bash\n# Validate skill structure\npnpm skills:check\n\n# Sync public skills to Claude\npnpm skills:sync\n```\n\n## Constraints\n\n- Never create skills outside `.agents/skills/<skill-name>/`\n- Always run `pnpm skills:check` before completing\n- Public skills require both adding to `public-skills.txt` AND running `pnpm skills:sync`\n- If the skill-creator skill is available, you may use it for advanced skill development (evals, iterations), but this skill handles the basic creation workflow.\n",".agents/skills/vercel-react-best-practices/SKILL.md":"---\nname: vercel-react-best-practices\ndescription: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.\nlicense: MIT\nmetadata:\n author: vercel\n version: \"1.0.0\"\n---\n\n# Vercel React Best Practices\n\nComprehensive performance optimization guide for React and Next.js applications, maintained by Vercel. Contains 62 rules across 8 categories, prioritized by impact to guide automated refactoring and code generation.\n\n## When to Apply\n\nReference these guidelines when:\n- Writing new React components or Next.js pages\n- Implementing data fetching (client or server-side)\n- Reviewing code for performance issues\n- Refactoring existing React/Next.js code\n- Optimizing bundle size or load times\n\n## Rule Categories by Priority\n\n| Priority | Category | Impact | Prefix |\n|----------|----------|--------|--------|\n| 1 | Eliminating Waterfalls | CRITICAL | `async-` |\n| 2 | Bundle Size Optimization | CRITICAL | `bundle-` |\n| 3 | Server-Side Performance | HIGH | `server-` |\n| 4 | Client-Side Data Fetching | MEDIUM-HIGH | `client-` |\n| 5 | Re-render Optimization | MEDIUM | `rerender-` |\n| 6 | Rendering Performance | MEDIUM | `rendering-` |\n| 7 | JavaScript Performance | LOW-MEDIUM | `js-` |\n| 8 | Advanced Patterns | LOW | `advanced-` |\n\n## Quick Reference\n\n### 1. Eliminating Waterfalls (CRITICAL)\n\n- `async-defer-await` - Move await into branches where actually used\n- `async-parallel` - Use Promise.all() for independent operations\n- `async-dependencies` - Use better-all for partial dependencies\n- `async-api-routes` - Start promises early, await late in API routes\n- `async-suspense-boundaries` - Use Suspense to stream content\n\n### 2. Bundle Size Optimization (CRITICAL)\n\n- `bundle-barrel-imports` - Import directly, avoid barrel files\n- `bundle-dynamic-imports` - Use next/dynamic for heavy components\n- `bundle-defer-third-party` - Load analytics/logging after hydration\n- `bundle-conditional` - Load modules only when feature is activated\n- `bundle-preload` - Preload on hover/focus for perceived speed\n\n### 3. Server-Side Performance (HIGH)\n\n- `server-auth-actions` - Authenticate server actions like API routes\n- `server-cache-react` - Use React.cache() for per-request deduplication\n- `server-cache-lru` - Use LRU cache for cross-request caching\n- `server-dedup-props` - Avoid duplicate serialization in RSC props\n- `server-hoist-static-io` - Hoist static I/O (fonts, logos) to module level\n- `server-serialization` - Minimize data passed to client components\n- `server-parallel-fetching` - Restructure components to parallelize fetches\n- `server-after-nonblocking` - Use after() for non-blocking operations\n\n### 4. Client-Side Data Fetching (MEDIUM-HIGH)\n\n- `client-swr-dedup` - Use SWR for automatic request deduplication\n- `client-event-listeners` - Deduplicate global event listeners\n- `client-passive-event-listeners` - Use passive listeners for scroll\n- `client-localstorage-schema` - Version and minimize localStorage data\n\n### 5. Re-render Optimization (MEDIUM)\n\n- `rerender-defer-reads` - Don't subscribe to state only used in callbacks\n- `rerender-memo` - Extract expensive work into memoized components\n- `rerender-memo-with-default-value` - Hoist default non-primitive props\n- `rerender-dependencies` - Use primitive dependencies in effects\n- `rerender-derived-state` - Subscribe to derived booleans, not raw values\n- `rerender-derived-state-no-effect` - Derive state during render, not effects\n- `rerender-functional-setstate` - Use functional setState for stable callbacks\n- `rerender-lazy-state-init` - Pass function to useState for expensive values\n- `rerender-simple-expression-in-memo` - Avoid memo for simple primitives\n- `rerender-move-effect-to-event` - Put interaction logic in event handlers\n- `rerender-transitions` - Use startTransition for non-urgent updates\n- `rerender-use-ref-transient-values` - Use refs for transient frequent values\n- `rerender-no-inline-components` - Don't define components inside components\n\n### 6. Rendering Performance (MEDIUM)\n\n- `rendering-animate-svg-wrapper` - Animate div wrapper, not SVG element\n- `rendering-content-visibility` - Use content-visibility for long lists\n- `rendering-hoist-jsx` - Extract static JSX outside components\n- `rendering-svg-precision` - Reduce SVG coordinate precision\n- `rendering-hydration-no-flicker` - Use inline script for client-only data\n- `rendering-hydration-suppress-warning` - Suppress expected mismatches\n- `rendering-activity` - Use Activity component for show/hide\n- `rendering-conditional-render` - Use ternary, not && for conditionals\n- `rendering-usetransition-loading` - Prefer useTransition for loading state\n- `rendering-resource-hints` - Use React DOM resource hints for preloading\n- `rendering-script-defer-async` - Use defer or async on script tags\n\n### 7. JavaScript Performance (LOW-MEDIUM)\n\n- `js-batch-dom-css` - Group CSS changes via classes or cssText\n- `js-index-maps` - Build Map for repeated lookups\n- `js-cache-property-access` - Cache object properties in loops\n- `js-cache-function-results` - Cache function results in module-level Map\n- `js-cache-storage` - Cache localStorage/sessionStorage reads\n- `js-combine-iterations` - Combine multiple filter/map into one loop\n- `js-length-check-first` - Check array length before expensive comparison\n- `js-early-exit` - Return early from functions\n- `js-hoist-regexp` - Hoist RegExp creation outside loops\n- `js-min-max-loop` - Use loop for min/max instead of sort\n- `js-set-map-lookups` - Use Set/Map for O(1) lookups\n- `js-tosorted-immutable` - Use toSorted() for immutability\n- `js-flatmap-filter` - Use flatMap to map and filter in one pass\n\n### 8. Advanced Patterns (LOW)\n\n- `advanced-event-handler-refs` - Store event handlers in refs\n- `advanced-init-once` - Initialize app once per app load\n- `advanced-use-latest` - useLatest for stable callback refs\n\n## How to Use\n\nRead individual rule files for detailed explanations and code examples:\n\n```\nrules/async-parallel.md\nrules/bundle-barrel-imports.md\n```\n\nEach rule file contains:\n- Brief explanation of why it matters\n- Incorrect code example with explanation\n- Correct code example with explanation\n- Additional context and references\n\n## Full Compiled Document\n\nFor the complete guide with all rules expanded: `AGENTS.md`\n",".agents/skills/gh-create-issue/SKILL.md":"---\nname: gh-create-issue\ndescription: Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.\n---\n\n# GitHub Create Issue\n\nUse this skill when the user requests to create an issue. Must follow the repository's issue template format.\n\n## Workflow\n\n### Step 1: Determine Template Type\n\nAnalyze the user's request to determine the issue type:\n- If the user describes a problem, error, crash, or something not working -> Bug Report\n- If the user requests a new feature, enhancement, or additional support -> Feature Request\n- If the user is asking a question or needs help with something -> Questions & Discussion\n- If the user describes engineering work with no user-facing behavior change (a follow-up deferred from a pull request, technical debt, refactoring, tooling or CI work) -> Engineering Task\n- Otherwise -> Others\n\nEngineering Task is not a GitHub issue form and is not offered to regular users. Only select it when the request clearly describes internal engineering work.\n\n**If unclear**, ask the user which template to use. Do not default to \"Others\" on your own.\n\n#### Eligibility Check (Engineering Task only)\n\nEngineering Task is meant for maintainers and collaborators with write access. This is a request,\nnot an access control — nothing prevents anyone from calling `gh issue create` directly, and this\nskill does not try to. The check below is here so that a contributor without write access learns\nthat early and gets pointed somewhere more useful.\n\nBefore collecting any information, read the authenticated user's permission level:\n\n```bash\nrepo=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\nuser=\"$(gh api user --jq .login)\"\npermission=\"$(gh api \"repos/$repo/collaborators/$user/permission\" --jq .permission 2>/dev/null)\"\ncase \"$permission\" in\n admin | write) echo \"eligible\" ;;\n *) echo \"not eligible\" ;;\nesac\n```\n\nOnly `admin` and `write` are eligible (`maintain` reports as `write`). Always compare the returned\nvalue: on a public repository this endpoint answers `read` for any user, including one who is not a\ncollaborator at all, so a successful call proves nothing on its own. Do not use\n`repos/{owner}/{repo}/collaborators/{user}` here — it answers `204` for `read`- and `triage`-only\ncollaborators, who are not the intended audience for this template.\n\nIf the result is anything else, do not use this template. Explain that it is meant for maintainers\nwith write access, politely ask the contributor to use one of the public templates instead, and\noffer to help them file it there — their report is welcome, just not under this template. Do not\nquietly switch templates while keeping the Engineering Task labels or issue type.\n\n### Step 2: Read the Selected Template\n\n1. Read the corresponding template file from `.github/ISSUE_TEMPLATE/` directory.\n2. Identify required fields (`validations.required: true`), title prefix (`title`), labels (`labels`, if present), and issue type (`type`, if present).\n\nFor Engineering Task, read [references/engineering-task.md](references/engineering-task.md) instead — it lives outside `.github/ISSUE_TEMPLATE/` on purpose and carries its own title prefix, labels, issue type, and body structure.\n\n### Step 3: Collect Information\n\nBased on the selected template, ask the user for required information only. Follow the template's required fields and option constraints (for example, Platform and Priority choices).\n\n### Step 4: Build and Preview Issue Content\n\nCreate a temp file and write the issue content:\n- Use `issue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"`\n- Use the exact title prefix from the selected template.\n- Fill content following the template body structure and section order.\n- Apply labels exactly as defined by the template.\n- Keep all labels when there are multiple labels.\n- If template has no labels, do not add custom labels.\n- Apply the issue type exactly as defined by the template's `type` field.\n\nPreview the temp file content. **Show the file path** (e.g., `/tmp/gh-issue-body-XXXXXX.md`) and ask for confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).\n\n### Step 5: Create Issue\n\nUse `gh issue create` command to create the issue.\n\nUse a unique temp file for the body:\n\n```bash\nissue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"\ncat > \"$issue_body_file\" <<'EOF'\n...issue body built from selected template...\nEOF\n```\n\nCreate the issue using values from the selected template:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\"\n```\n\nIf the selected template includes labels, append one `--label` per label:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --label \"<label_1_from_template>\" --label \"<label_2_from_template>\"\n```\n\nIf the selected template has no labels, do not pass `--label`.\n\nIf the selected template declares a `type`, pass it as well. `--body-file` does not carry the issue type over on its own, so omitting this leaves the issue untyped:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --type \"<type_from_template>\"\n```\n\n`--template` and `--web` resolve against `.github/ISSUE_TEMPLATE/` on the default branch, so neither works for Engineering Task. Build the body locally for it.\n\nFor the other templates you may use `--template` as a starting point (use the exact template name from the repository):\n\n```bash\ngh issue create --template \"<template_name>\"\n```\n\nUse the `--web` flag to open the creation page in browser when complex formatting is needed:\n\n```bash\ngh issue create --web\n```\n\nClean up the temp file after creation:\n\n```bash\nrm -f \"$issue_body_file\"\n```\n\n## Notes\n\n- Must read template files under `.github/ISSUE_TEMPLATE/` (or `references/` for Engineering Task) to ensure following the correct format.\n- Treat template files as the only source of truth. Do not hardcode title prefixes, labels, or issue types in this skill.\n- Title must be clear and concise, avoid vague terms like \"a suggestion\" or \"stuck\".\n- Provide as much detail as possible to help developers understand and resolve the issue.\n- If user doesn't specify a template type, ask them to choose one first.\n",".agents/skills/gh-pr-review/SKILL.md":"---\nname: gh-pr-review\ndescription: Automated Cherry Studio review for local branches, PRs, commits, files, architecture docs, and repository skills. Use for code or documentation reviews that need project-specific naming, main/renderer/shared placement and dependency rules, IpcApi and DataApi boundaries, lifecycle/service ownership, renderer hooks, React/UI conventions, and tests. Review depth adapts to diff size and runtime subagent capability (single-agent or multi-agent reviewer-verifier). Report-only by default; code fixes and GitHub submission each require explicit invocation-time authorization (`fix` / `submit`). Normal-review prompts and safe interruption behavior follow the interaction contract below. To diagnose gaps in the skill after a review session, run `/gh-pr-review diag`.\n---\n\n<!-- Based on https://github.com/Tencent/tgfx/tree/main/.codebuddy/skills/cr -->\n<!-- Adapted for agent runtimes and the Cherry Studio tech stack -->\n\n# /gh-pr-review — Code Review\n\nAutomated code review for local branches, PRs, commits, and files. Detects\nthe review target from arguments, then picks the review engine from diff size\nand runtime capability. Small diffs use single-agent review\n(`references/local-review.md`). Large diffs use the multi-agent\nreviewer–verifier flow (`references/teams-review.md`) only when independent\nsubagents are available; otherwise they fall back to single-agent review with\nthat limitation disclosed. PR targets add worktree setup and GitHub submission\n(`references/pr-review.md`) around the same engine-selection contract.\n\nCherry Studio-specific review rules live in\n`references/cherry-review-guidance.md`. Target review flows must load that file\nfor code, mixed, architecture-doc, and project-skill reviews so reviewers can\napply DataApi, service-boundary, renderer hook, React, UI, and type-contract\nchecks without relying on memory. That reference also defines which internal\ndocs, internal skills, external skills, and official websites to consult for\neach changed area; load only the relevant subset.\n\nAll user-facing text matches the user's language.\n\n## Interaction and interruption contract\n\nApart from the declared categories below, normal review is prompt-free: never\nask for mode selection, fix confirmation, finding selection, or submission\npreview. A leaf flow may request input only when it explicitly declares one of\nthese categories:\n\n- **Product decision** — in an interactive session, the Product Demand gate may\n ask the current user for a decision the review cannot derive. In an automated\n session, record the impact and open decision without deciding for the user.\n- **Safety or environment blocker** — continuing would require destructive\n action, new authority, or missing external configuration. Declared examples\n are a dirty/mismatched review worktree, a missing canonical remote, cleanup\n of unexplained changes, removal of a failed fix patch, and a pending review\n draft holding comments this run did not confirm. In an interactive session,\n preserve state and ask only for the decision needed to proceed.\n- **Explicit maintenance mode** — `diag` and separately requested checklist\n maintenance are interactive selection flows outside normal review. They may\n ask for the declared edit selection or persistent checkout/branch target.\n\nAn automated session never waits for user input. At a product decision it\ncontinues record-only as specified below. At a safety/environment blocker it\npreserves state, stops the affected flow safely, and reports the exact blocker\nand required decision. In an explicit maintenance mode it reports candidates\nor missing destination information, applies no selection-dependent edits, and\nstops safely. No leaf flow may introduce another prompt category.\n\n## Review Stages\n\nEvery review runs these stages in order. A later stage reviews only what\nsurvived the earlier ones, so a stage never re-litigates an earlier verdict.\n\nThis table is the single source of truth for stage scope and references; a\nleaf flow may not widen, narrow, or re-reference a stage.\n\n| # | Stage | Applies to | Reference |\n|---|-------|-----------|-----------|\n| 1 | **Product Demand** (gate) | any change whose semantics affect the product | below |\n| 2 | **Consumer** | any change that adds or expands shared surface | `references/consumer-review.md` |\n| 3 | **Architecture-First** | code, mixed, Cherry architecture docs, project skills | `references/cherry-review-guidance.md` |\n| 4 | **Implementation** | code, mixed | `references/code-checklist.md` (A/B) |\n| 4 | **Implementation** | docs | `references/doc-checklist.md` (A/B) |\n| 5 | **Style / conventions** | code, mixed | `references/code-checklist.md` (C) |\n| 5 | **Style / conventions** | docs | `references/doc-checklist.md` (C) |\n\nStage applicability follows the changed content, not the commit label: a\ndocumentation-only diff still runs stages 3–5 when it changes Cherry\narchitecture docs or project skills, and a code diff that also edits docs runs\nboth reference sets for stages 4–5.\n\n### Stage 1: Product Demand gate\n\nFirst inspect the semantics actually expressed or constrained by the change,\nthen decide whether it affects **product semantics, user-visible behavior, or\nproduct direction**. Change labels are not sufficient evidence: internal\nrefactors and non-user-facing fixes often have no product impact, while\nuser-facing fixes, docs, tests, or tooling can record, lock, or alter product\nbehavior.\n\nWhen there is product impact, determine whether the direction is already\nestablished in the current review context. Treat it as established only when\nthe current user explicitly decided it or an authoritative project artifact\nexplicitly records the accepted behavior and its approval by the responsible\nproject authority, such as a specification, an ADR, or an issue containing a\nmaintainer decision that settles the expected behavior. Do not infer acceptance\nfrom issue state, labels, milestone, assignment, or a link from the PR. A change\nlabel, PR body, implementation, or test demonstrates author intent or current\nbehavior but does not establish product approval on its own.\n\nClassify the gate into exactly one state:\n\n- **No product impact**: skip this stage entirely in both interactive and\n automated runs; say nothing about the skipped gate.\n- **Established direction**: compare the change with the recorded decision. If\n it aligns, continue without asking for another product decision. If it\n conflicts, report the product-direction mismatch and **stop the whole review\n immediately** — do not run Consumer, Architecture, Implementation, or Style\n stages, and do not report code findings. Applying an existing decision is\n not making a new one.\n- **Open product decision**:\n - **Interactive session (default)**: summarize the change's effect on\n product functionality and semantics, and ask the current user for the\n unresolved product decision. Do not infer automation from PR authorship,\n review ownership, or whether the user authored the change. If the user\n rejects the direction, stop the whole review as above; if the user\n approves it, continue with the remaining stages.\n - **Automated session (explicit only)**: use this mode only when the\n invocation prompt or workflow context explicitly identifies a headless,\n CI, batch, or other automated run. Make no product decision on the user's\n behalf. Run the remaining stages, and in the final report summarize the\n product impact, the direction the change takes, and the points needing\n human confirmation. Never phrase this as product approval having been\n obtained.\n\n## Authority model\n\nA review request authorizes analysis and reporting only. The review target,\nreview depth, and reviewer–verifier confidence never grant execution\nauthority; authority is granted explicitly at invocation time, and execution\nis prompt-free only after it has been granted:\n\n- **Report-only (default)**: every review, any target — findings are reported\n with fix guidance. No working-tree edits, no GitHub writes.\n- **Fix (explicit)**: granted only by the invocation — `fix` in `$ARGUMENTS`\n or equivalent explicit user wording (\"review and fix …\"). Local targets\n only. What each risk level then permits is owned by\n `references/judgment-matrix.md` § Handling by Risk Level; this section grants\n the authority and never restates the mapping.\n Applying fixes makes the session a coding task, so it must end with the\n validation selected per § Validation after applied fixes below.\n- **Submit (explicit)**: granted only by the invocation — `submit` in\n `$ARGUMENTS` or equivalent explicit user wording. PR flows then submit all\n confirmed findings without per-comment prompts. Approving or merging always\n requires its own explicit request.\n\n## Validation after applied fixes\n\nNever run local lint, test, or format during a review that edited nothing.\nWhen fixes were applied, select the validation matching the changed surface,\nfollowing `AGENTS.md` § Operational Rules (\"Check what you changed, not the\nwhole repo\"), and report the results:\n\n- Docs/markdown-only fixes — including this skill's own files — run\n `pnpm docs:check`.\n- Code fixes run `pnpm lint` (which already ends with `pnpm format`, so never\n invoke `format` again) plus the tests covering the change: a per-project\n wrapper such as `pnpm test:main <file>` or `pnpm exec vitest run <file>`.\n Never `pnpm test <path>` — that script chains several vitest invocations and\n the path reaches only the last one.\n- Reserve the full `pnpm test` for a broad change whose affected tests cannot\n be named, and use `pnpm test:lint` when the CI-equivalent lint gate matters\n (`pnpm lint` tolerates oxlint warnings that CI denies).\n\n## Route\n\nFirst strip authority modifiers from `$ARGUMENTS` (equivalent explicit user\nwording in the conversation counts the same; both default to `false`). Call\nthe remainder `REVIEW_TARGET` — every rule below, and every leaf flow, reads\n`REVIEW_TARGET`, never the raw `$ARGUMENTS`:\n\n- `fix` → `AUTHORIZED_FIX = true` (meaningful for local targets)\n- `submit` → `AUTHORIZED_SUBMIT = true` (meaningful for PR targets)\n\nBefore choosing a review engine, inspect the runtime's exposed coordination\ncapabilities. Set `HAS_SUBAGENTS = true` only when it can launch an independent\nreviewer and a fresh independent verifier. Parallel execution is not required;\nsequential subagents still satisfy the isolation contract.\n\n### Rules\n\nMatch the **first** applicable rule top-to-bottom:\n\n1. `REVIEW_TARGET` is `diag` → `references/diagnosis.md`.\n2. `REVIEW_TARGET` is `checklist`, or the user explicitly asks to adopt the\n proposed checklist candidates → `references/checklist-evolution.md`,\n entering at its Step 2. Maintenance runs only in the session that produced\n the candidates; it reviews nothing.\n3. `REVIEW_TARGET` is a PR number or URL containing `/pull/` →\n `references/pr-review.md` (pass `AUTHORIZED_SUBMIT` and `HAS_SUBAGENTS`;\n the wrapper collects the exact PR scope before selecting the engine).\n4. Everything else: derive the scope and `SMALL_SCOPE` per § Scope derivation\n below, then select the engine.\n - `SMALL_SCOPE = true` → `references/local-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = true` →\n `references/teams-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = false` →\n `references/local-review.md`; pass `LIMITED_SINGLE_AGENT = true` so the\n report explicitly states that a large diff received single-agent review\n without independent adversarial verification.\n - Pass `AUTHORIZED_FIX` (commit and range targets are immutable history —\n always report-only regardless of the flag).\n\nEach `→` means: `Read` the target file and follow it as the sole remaining\ninstruction for how to obtain diffs, apply fixes, and submit results. Do NOT\nreview from memory or habit. The skill-wide sections — § Review Stages,\n§ Authority model, § Validation after applied fixes, and § Scope derivation —\nstay binding; the leaf flows reference them by name.\n\nNever ask the user anything to route. Pass `REVIEW_TARGET`, the resolved\nscope, `SMALL_SCOPE`, and the authority flags to the target file.\n\n### Scope derivation\n\nReached only from Rule 4 above; `diag` and `checklist` targets never enter this\nsubsection. It is the **sole owner** of how a review scope and its size are\nderived — leaf flows reference it and never restate it.\n\nResolve `REVIEW_TARGET` into the review scope:\n\n| `REVIEW_TARGET` | Scope |\n|---|---|\n| empty, uncommitted changes exist | uncommitted changes only — `git diff HEAD` (staged + unstaged tracked files), plus untracked (`??`) files from `git status --porcelain`, reviewed as new code |\n| empty, clean tree | branch diff against the base: `git merge-base origin/{main\\|master} HEAD`, then `git diff <merge-base-sha>`, plus untracked files |\n| commit hash | validate with `git rev-parse --verify`, then `git show` |\n| commit range (`A..B` / `A...B`) | validate both endpoints, then `git diff A~1..B` |\n| file/directory paths | verify each path exists, then the full contents of the resolved files |\n| PR number or `/pull/` URL | the PR's merge-base diff, collected by `references/pr-review.md` |\n\nThe **resolved review scope**, not a diff, decides whether there is work: for a\npath target it is the set of files resolved from the given paths; for every\nother target it is the diff. A clean tree does not make a path target empty.\nIf the resolved scope is empty, show the usage examples below and exit.\n\nThen measure what the leaf flow will actually read — a diff for diff-shaped\ntargets, full file text for path targets:\n\n- **Diff-shaped targets** (uncommitted changes, branch/merge-base diff, a\n commit, a commit range, a PR): `CHANGED_LINES` is the sum of numeric\n additions and deletions from `git diff --numstat` for the complete review\n scope, and `CHANGED_FILES` is the number of unique changed paths in it.\n- **File/directory path targets**: the leaf flow reviews full contents, so\n measure full contents — `CHANGED_FILES` is the number of files resolved\n from the given paths (directories expand recursively, excluding ignored\n paths), and `CHANGED_LINES` is the total line count of those files. A\n clean tree never makes a path target small by default.\n- **Untracked text files** in a diff-shaped scope count as one file each with\n their full line count as additions.\n- Generated files count normally in both totals; do not exclude them because\n they are generated.\n- Any binary file — a binary diff (`-`/`-` in `--numstat`), an untracked\n binary, or a binary resolved from a path target — counts as a file and makes\n the scope non-small, because its line size is unknown.\n\nSet `SMALL_SCOPE = true` only when `CHANGED_LINES <= 1000`,\n`CHANGED_FILES <= 20`, and the scope contains no binary file. Both numeric\nconditions must hold. `SMALL_SCOPE` is the name every flow uses for this\nresult.\n\n### Usage examples\n\nPrint this list when the resolved scope is empty:\n\n```\n/gh-pr-review review uncommitted changes, else the branch diff\n/gh-pr-review a1b2c3d review a commit\n/gh-pr-review a1b2c3d..e4f5g6h review a commit range\n/gh-pr-review src/foo.ts review files or directories\n/gh-pr-review 123 review a PR (also accepts a /pull/ URL)\n/gh-pr-review <target> fix also apply low-risk fixes (local targets)\n/gh-pr-review <pr> submit also publish the review to GitHub\n/gh-pr-review checklist adopt this session's proposed checklist items\n/gh-pr-review diag diagnose gaps in this skill\n```\n",".agents/skills/prepare-release/SKILL.md":"---\nname: prepare-release\ndescription: Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch. Use when asked to prepare/create a release, bump version, or run `/prepare-release`.\n---\n\n# Prepare Release\n\nAutomate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch → trigger CI/CD.\n\n## Arguments\n\nParse the version intent from the user's message. Accept any of these forms:\n- Bump type keyword: `patch`, `minor`, `major`\n- Exact version: strict `x.y.z` or `x.y.z-<prerelease>` without build metadata (e.g. `1.8.0`, `1.8.0-beta.1`, `1.8.0-rc.1`)\n- Natural language: \"prepare a beta release\", \"bump to 1.8.0-rc.2\", etc.\n\nDefaults to `patch` if no version is specified. Always echo the resolved target version back to the user before proceeding with any file edits.\n\n- `--dry-run`: Preview only, do not create a release branch.\n\n## Workflow\n\n### Step 1: Determine Version\n\n1. For an interactive local run, fetch `origin/main` and all tags, then verify that the checkout is a clean `main` at exactly `origin/main`:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test -z \"$(git status --porcelain)\"\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n ```\n Stop before editing files if any check fails. This prevents a standalone run from creating a release branch from an arbitrary or stale checkout.\n In GitHub Actions, use the workflow's frozen dispatch SHA and leave checkout validation to the workflow. Do not fetch or compare the later `origin/main` head.\n2. Read the current version from `package.json`. Use it for version increments even if that release has since been withdrawn; never reuse the withdrawn version.\n3. Select the latest published, non-draft GitHub Release whose tag is strict `v<semver>` as the release-note baseline. Non-semver preview releases and drafts are never a baseline:\n ```bash\n gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty'\n ```\n Stop if no published baseline exists or its Git tag is missing (`git rev-parse --verify refs/tags/{baseline-tag}`). Compare its version with the current package version using `semver`: if main is behind, stop and require the latest Post Release metadata PR to be merged. If main is ahead, allow preparation using the published baseline for release notes and the package version for version increments. For example, after withdrawing 2.1.1, main at 2.1.1 with a published baseline of 2.1.0 prepares 2.1.2 and includes changes since 2.1.0.\n In GitHub Actions, use the workflow-provided baseline tag and collection base without repeating these checks.\n4. Compute the new version based on the argument:\n - `patch` / `minor` / `major`: bump from the current version.\n - An exact version must match `^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\.[0-9A-Za-z-]+)*)?$` and pass `semver.valid`; build metadata such as `+build.1` is not accepted.\n - In both cases, require the result to be strictly greater than the current version according to semver precedence. Reject equal versions and downgrades.\n\n### Step 2: Collect Commits\n\n1. Determine the release-note collection base from the published baseline selected in Step 1, not from the package version:\n - If the baseline tag is an ancestor of `HEAD`, use the tag.\n - Otherwise, use the latest commit whose full message contains the exact marker `release-metadata-boundary: <baseline-tag>`. This machine marker is added to the Post Release pull request body and survives the required squash merge.\n - For metadata pull requests created before the machine marker existed, accept a subject exactly equal to `chore(release): sync <baseline-tag> metadata` or that subject followed only by GitHub's squash suffix ` (#<PR-number>)`.\n - Stop with an error if the tag is not an ancestor and its metadata sync commit is missing; otherwise already-released hotfixes could be included again.\n2. List all commits since that base:\n ```bash\n git log <collection-base>..HEAD --format=\"%H %s\" --no-merges\n ```\n3. For each commit, get the full body:\n ```bash\n git log <hash> -1 --format=\"%B\"\n ```\n4. Extract the content inside `` ```release-note `` code blocks from each commit body.\n5. Extract the conventional commit type from the title (`feat`, `fix`, `refactor`, `perf`, `docs`, etc.).\n6. **Skip** these commits as standalone release-note candidates, but still inspect their effects when reconciling candidates with the final code in Step 3:\n - Titles starting with `🤖 Daily Auto I18N`\n - Titles starting with `Merge`\n - Titles starting with `chore(deps)`\n - Titles starting with `chore: release`\n - Titles starting with `chore(release)`\n - Commits where the release-note block says `NONE`\n\n### Step 3: Generate Bilingual Release Notes\n\nGenerate release notes in **both English and Chinese** from the final user-visible changes relative to the published baseline. Commit titles and `release-note` blocks are candidate descriptions, not proof that a change will ship.\n\n**Reconcile net changes before drafting:**\n\n1. Inspect `git diff --name-status <baseline-tag> <release-head>`, then read the relevant patches and code at both endpoints. `<release-head>` is the source `HEAD` before release preparation (the frozen dispatch SHA in CI). Compare the two endpoint trees, not a three-dot merge-base diff. The collection base is only for discovering commits; when it differs from the published tag, also inspect user-visible differences missing from that commit range.\n2. Group candidates by user-visible behavior and trace related patches in chronological order, including commits excluded in Step 2. Detect explicit reverts, manual undoing, replacements, partial reversals, and reintroductions from the code; do not rely on commit wording or matching hashes alone.\n3. Omit a change introduced and fully undone during this cycle, including fixes that only addressed that temporary change. For partial reversals, replacements, or reintroductions, describe only the final outcome that differs from the published baseline, once per distinct user-visible change.\n4. If a reversal removes or changes behavior that already existed in the published baseline, describe the resulting user-visible removal or restoration. Do not discard all revert commits indiscriminately. An implementation rewrite that preserves the same user-visible behavior does not by itself justify a release-note entry.\n5. Verify each proposed item against the endpoint diff and final code, and ensure the English and Chinese versions describe the same outcome. If the claimed effect cannot be substantiated, omit it and report the uncertainty in the preparation summary rather than inventing a release-note claim.\n\n**Recommended format:**\n\n```\n<!--LANG:en-->\nCherry Studio {version} - {Brief English Title}\n\n✨ New Features\n- [Component] Description\n\n🐛 Bug Fixes\n- [Component] Description\n\n💄 Improvements\n- [Component] Description\n\n⚡ Performance\n- [Component] Description\n\n<!--LANG:zh-CN-->\nCherry Studio {version} - {简短中文标题}\n\n✨ 新功能\n- [组件] 描述\n\n🐛 问题修复\n- [组件] 描述\n\n💄 改进\n- [组件] 描述\n\n⚡ 性能优化\n- [组件] 描述\n<!--LANG:END-->\n```\n\nThe language markers are the machine-readable contract: include each marker once, keep them in order, and provide non-empty English and Chinese sections. Titles and surrounding explanatory text are presentation choices, not validation requirements.\n\n**Rules:**\n- Only include categories that have entries (omit empty categories).\n- Each distinct surviving user-visible change appears once in the appropriate category; combine related commits and omit canceled or superseded claims.\n- Prefer wording from the `release-note` field, or otherwise the commit title, only when it matches the verified final outcome.\n- Component tags should be short: `[Chat]`, `[Models]`, `[Agent]`, `[MCP]`, `[Settings]`, `[Data]`, `[Build]`, etc.\n- Chinese translations should be natural, not machine-literal.\n- Do NOT include commit hashes or PR numbers.\n- Read the **existing** release notes in `electron-builder.yml` as a style reference before writing.\n\n**IMPORTANT: User-Focused Content Only**\n\nRelease notes are for **end users**, not developers. Exclude anything users don't care about:\n\n- **EXCLUDE** internal refactoring, code cleanup, or architecture changes\n- **EXCLUDE** CI/CD, build tooling, or test infrastructure changes\n- **EXCLUDE** dependency updates (unless they add user-visible features)\n- **EXCLUDE** documentation updates\n- **EXCLUDE** developer experience improvements\n- **EXCLUDE** technical debt fixes with no user-visible impact\n- **EXCLUDE** overly technical descriptions (e.g., \"fix race condition in Redux middleware\")\n\n**INCLUDE** only changes that users will notice:\n- New features they can use\n- Bug fixes that affected their workflow\n- UI/UX improvements they can see\n- Performance improvements they can feel\n- Security fixes (simplified, without implementation details)\n\n**Keep descriptions simple and non-technical:**\n- ❌ \"Fix streaming race condition causing partial tool response status in Redux state\"\n- ✅ \"Fix tool status not stopping when aborting\"\n- ❌ \"Auto-convert reasoning_effort to reasoningEffort for OpenAI-compatible providers\"\n- ✅ \"Fix deep thinking mode not working with some providers\"\n\n### Step 4: Update Files\n\n1. **`package.json`**: Update the `\"version\"` field to the new version.\n2. **`electron-builder.yml`**: Replace the content under `releaseInfo.releaseNotes: |` with the generated notes. Preserve the 4-space YAML indentation for the block scalar content.\n3. **`resources/cherry-studio/release-history.json`**: Never edit by hand; the notes must match `electron-builder.yml` byte for byte. Run `node scripts/release/sync-release-history.js --target-version {version}`, which prepends (or replaces) the entry for a stable release and leaves the file untouched for a prerelease. In GitHub Actions, the workflow runs this itself after the Claude step.\n4. **Validate source metadata**: For an interactive local run, run `node scripts/release/validate-prepared-release.js --target-version {version}` before generating the product manifest, and stop if it rejects the changed paths, version ordering, bilingual sections, or stable history. In GitHub Actions, leave validation to the workflow step that runs after Claude.\n5. **Built-in knowledge**: For an interactive local run, run `pnpm build:builtin-knowledge` after validation. This refreshes `resources/builtin-agents/cherry-assistant/product-manifest.json` with the new package version. Never edit the generated manifest by hand. In GitHub Actions, do not run the generator: the workflow runs the same validator first, then runs the trusted generator itself.\n\n### Step 5: Present for Review\n\nShow the user:\n- The new version number.\n- The full generated release notes.\n- A summary of which files were modified.\n\nIf `--dry-run` was specified, stop here.\n\nOtherwise, ask the user to confirm before proceeding to Step 6.\n\n### Step 6: Create Release Branch\n\n1. For an interactive local run, repeat Step 1 items 1-3 immediately before creating the branch, reading the original package version from `HEAD:package.json`. Require the published baseline to still match the one used to collect release notes; otherwise regenerate the notes before proceeding. Because Step 4 has intentionally prepared and validated release metadata, replace Step 1's clean-worktree assertion with `git status --short` and stop unless every listed path is one of the four allowed release metadata files. Then create and push a signed, DCO-compliant release commit:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n test \"$(node -p \"require('./package.json').version\")\" = \"{version}\"\n CURRENT_VERSION=\"$(git show HEAD:package.json | jq -r .version)\"\n LATEST_PUBLISHED=\"$(gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty')\"\n test \"$LATEST_PUBLISHED\" = \"{baseline-tag}\"\n git rev-parse --verify \"refs/tags/$LATEST_PUBLISHED\"\n node -e \"const semver = require('semver'); process.exit(semver.gte(process.argv[1], process.argv[2]) ? 0 : 1)\" \"$CURRENT_VERSION\" \"${LATEST_PUBLISHED#v}\"\n REPO=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\n gh api --paginate --slurp \"repos/$REPO/releases?per_page=100\" | TAG=\"v{version}\" node scripts/release/validate-release-state.js prepare\n test -z \"$(git ls-remote --heads origin refs/heads/release/v{version})\"\n git status --short\n UNEXPECTED_RELEASE_PATHS=\"$(git status --porcelain | cut -c4- | grep -Ev '^(package\\.json|electron-builder\\.yml|resources/cherry-studio/release-history\\.json|resources/builtin-agents/cherry-assistant/product-manifest\\.json)$' || true)\"\n test -z \"$UNEXPECTED_RELEASE_PATHS\"\n git checkout -b release/v{version}\n git add package.json electron-builder.yml resources/cherry-studio/release-history.json resources/builtin-agents/cherry-assistant/product-manifest.json\n git commit -S --signoff -m \"chore(release): prepare v{version}\"\n git cat-file commit HEAD | grep -q '^gpgsig '\n git log -1 --format=%B | grep -q '^Signed-off-by: '\n git push -u origin release/v{version}\n ```\n2. In GitHub Actions, stop after updating `package.json` and `electron-builder.yml`. Temporary helper files and local Git operations are allowed; the workflow extracts those two file changes, restores the frozen source SHA, and discards everything else. It then derives the release history, validates, generates the product manifest, creates the branch, and uses GitHub's API to create and verify the signed, DCO-compliant commit. Never push from the Claude step.\n3. Report the release branch and next steps. Do not create a PR yet: the release must be built and published from this branch first.\n\n## CI Trigger Chain\n\n- Wait for the **CI** push run on the new `release/v{version}` commit to succeed. **`auto-release-build.yml`** revalidates that exact live branch head and dispatches **`release.yml`** with `all`; it builds macOS, Windows, and Linux and creates or updates the draft GitHub Release. Use **`release.yml`** manually only to retry a failed all-platform build or one platform for the unchanged tagged commit.\n- While a single draft semantic-version release is active, **`backport-release-fixes.yml`** opens a backport PR for the first merged `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` PR from `main`, applies any optional bilingual release note, then appends consecutive hotfixes and source markers to that same open topic branch. It manages every source PR's `hotfix` and backport-status labels and reports failures on the source PR; never merge `main` into the release branch.\n- Review the backport PR, wait for its CI, and merge it. After the resulting release-branch push passes CI, the exact-head all-platform draft rebuild starts automatically.\n- A successful exact-head all-platform build starts **`publish-release.yml`**. Approve the `release` Environment deployment after inspecting the draft. Publication then acquires the release-state lock, revalidates the approved run, release branch, tag, draft, artifacts, open PRs, and pending hotfixes, and publishes only if they still agree. The draft body contains the bilingual `electron-builder.yml` notes followed by GitHub's generated changes. The final fetched `main` SHA is the hotfix cutoff; a hotfix merged after that snapshot belongs to the next release. Publication triggers **`post-release.yml`**, which uses the published tag as its source, applies only the release metadata delta to the latest `main`, and creates a `release-sync/v{version}` metadata-only PR.\n- The metadata PR synchronizes only `package.json`, `electron-builder.yml`, release history, and the generated product manifest. It triggers **`ci.yml`**; merge it only after CI passes.\n- When squash-merging the metadata PR, set the commit title to exactly `chore(release): sync v{version} metadata` with only GitHub's optional PR-number suffix, and keep `release-metadata-boundary: v{version}` on its own line in the squash commit body so the next release can find the boundary reliably.\n\n## Constraints\n\n- Always read `electron-builder.yml` before modifying it to understand the current format.\n- Never retain changes outside `package.json`, `electron-builder.yml`, `resources/cherry-studio/release-history.json`, and the generated `resources/builtin-agents/cherry-assistant/product-manifest.json`.\n- Never push directly to `main`.\n- Never create the release metadata PR before the GitHub Release is published; `post-release.yml` owns that step.\n- Always show the generated release notes to the user before creating the release branch (unless running in CI with no interactive user).\n","resources/builtin-agents/cherry-assistant/.claude/skills/skills-manager/SKILL.md":"---\nname: skills-manager\ndescription: '搜索、安装或创建 Agent Skill；用户说“find a skill”“搜索技能”“帮我做个 skill”或想扩展能力时使用。'\n---\n\n# Skills Manager\n\n## 搜索和安装\n\n**优先复用**: `find-skills` 可用时先调用它完成搜索、质量检查和安装确认；只有不可用时才执行下面的 CLI 降级流程。\n\n**运行时检测**: 优先 `npx skills`，备选 `$CHERRY_STUDIO_BUN_PATH x skills`，都没有则提示安装 Node.js\n\n**搜索**: 理解需求→提取关键词→`npx skills find [query]`→展示名称/功能/来源\n\n**安装**: Skills 是第三方代码有完整权限，必须: 展示安全警告→提供源码链接→用户确认→`npx skills add <owner/repo@skill> -y`。位置: 项目级 `.claude/skills/` 或用户级 `~/.claude/skills/`\n\n**无结果**: 告知→先尝试直接完成→可复用流程再建议创建自定义 Skill\n\n## 创建 Skills\n\n1. 先确认现有 Skill 无法满足需求，并判断这是不是值得复用的流程；一次性任务直接完成，不强行创建 Skill。\n2. 检查可用 Skill 列表。`skill-creator` 可用时必须调用它，并完整遵循其需求澄清、初始化、编辑、验证和迭代流程；不要绕过它直接手写 `SKILL.md`。\n3. 只有 `skill-creator` 确实不可用时，才明确告诉用户正在降级，然后用 `npx skills init <skill-name>` 初始化，保持 `SKILL.md` 精简，并按需加入 `scripts/`、`references/`、`assets/`。\n4. 创建后至少验证 frontmatter、触发描述和一个真实用例；验证失败就修正后重跑。\n\n**参考**: https://skills.sh/ | `npx skills find/add/init`\n","resources/builtin-agents/cherry-assistant/.claude/skills/issue-reporter/SKILL.md":"---\nname: issue-reporter\ndescription: '仅在用户点名 GitHub Issue、Bug Report 或 Feature Request 时使用；未点名 GitHub 的反馈改用 cherry-studio-feedback。'\n---\n\n# Issue Reporter\n\n## 触发边界\n\n只有用户明确要求提交到 GitHub，才能继续本流程。不得从“提交问题”“反馈”“bug”或“功能建议”推断 GitHub；未明确点名 GitHub 时立即转交 `cherry-studio-feedback`，不得运行 `gh auth status`、搜索仓库或发起任何 GitHub 操作。\n\n## 检测 GitHub 登录\n\n每次提交前: `gh auth status 2>&1`。成功→GitHub模式，失败→本地模式。\n\n## GitHub 模式\n\n**Bug Report**: 收集信息(描述/复现步骤/期望/平台/版本) → 查重 `gh search issues \"[关键词]\" --repo CherryHQ/cherry-studio --state open --limit 5` → 读模板 `.github/ISSUE_TEMPLATE/0_bug_report.yml` → 预览给用户 → 确认后 `gh issue create` → 告知链接\n\n**Feature Request**: 确认需求→查重→读模板 `1_feature_request.yml`→预览→确认→提交→记录到 `.cherry-assistant/feature-requests.md`\n\n## 本地模式\n\nBug 存 `.cherry-assistant/bug-reports.md`，Feature 存 `feature-requests.md`：\n```markdown\n### [Bug/Feature]: [标题]\n- **日期**: YYYY-MM-DD | **平台**: OS | **版本**: vX.X.X\n- **描述**: ... | **复现步骤**: 1... 2... | **期望**: ...\n- **状态**: 待提交\n---\n```\n\n存档后引导: GitHub(推荐) https://github.com/CherryHQ/cherry-studio/issues | 论坛 linux.do | 飞书表单 https://mcnnox2fhjfq.feishu.cn/share/base/form/shrcnsjfFkx4gy6wx9LQ70tMaKe\n\n**批量提交**: 有权限时可说「帮我把待提交的都提交了」→读文件→筛待提交→逐个查重预览确认→更新状态为「已提交 #号」\n\n## 注意\n\n- 提交前必须用户确认\n- 脱敏日志中 token/key\n- Redux/IndexedDB schema 变更标记 Blocked: v2\n","resources/builtin-agents/cherry-assistant/.claude/skills/faq-collector/SKILL.md":"---\nname: faq-collector\ndescription: 将成功解决的用户问题收录到 FAQ 知识库。问题解决后自动判断是否收录。也可以在用户说\"收录到 FAQ\"、\"记录这个问题\"、\"add to FAQ\"时手动触发。\n---\n\n# FAQ Collector\n\n**收录标准**: 通用性高、有明确方案、配置/操作类、非直觉问题。不收录: 纯个人环境问题、已有相同条目、未解决问题。\n\n**文件**: `<project_root>/.cherry-assistant/faq.md`（目录不存在则 `mkdir -p .cherry-assistant` 创建）\n\n**条目格式**（追加到末尾）:\n```markdown\n### Q: [通用化问题表述]\n**A:** [简洁方案]\n[分步骤操作]\n- **关键词**: [逗号分隔]\n- **相关文件/Issue**: [路径或#编号]\n- **版本**: vX.X.X | **收录日期**: YYYY-MM-DD\n---\n```\n\n**流程**: 问题解决→判断收录标准→读FAQ查重→无重复则通用化后追加→有相似但更好则更新\n\n**搜索匹配**: 用户提问时先读FAQ关键词匹配→命中直接给答案→未命中走正常诊断\n\n**与 Issue Reporter 协作**: 先收录FAQ(记录方案)→如果是Bug再提Issue→FAQ记关联Issue编号\n","resources/skills/find-skills/SKILL.md":"---\nname: find-skills\ndescription: 'Find and install agent skills when the user asks for a capability that may already exist as a skill.'\nversion: 1.0.0\n---\n\n# Find Skills\n\nThis skill helps you discover and install skills from the open agent skills ecosystem.\n\n## When to Use This Skill\n\nUse this skill when the user:\n\n- Asks \"how do I do X\" where X might be a common task with an existing skill\n- Says \"find a skill for X\" or \"is there a skill for X\"\n- Asks \"can you do X\" where X is a specialized capability\n- Expresses interest in extending agent capabilities\n- Wants to search for tools, templates, or workflows\n- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)\n\n## The skill tools\n\nCherry gives you two built-in tools for skills — use them, and do NOT shell out to\n`npx skills`, `git`, or any package manager:\n\n- **`search_skills(query)`** — search the marketplace by keyword. Returns matches, each with an\n opaque `install_source` value.\n- **`install_skill(install_source)`** — install ONE skill into Cherry's managed\n library and enable it for this agent. Cherry clones the repo, installs just that one skill,\n and registers it in a single deterministic step. Permission handling follows the active Claude\n permission mode (Step 6).\n\n**Browse skills at:** https://skills.sh/\n\n## How to Help Users Find Skills\n\n### Step 1: Understand What They Need\n\nWhen a user asks for help with something, identify:\n\n1. The domain (e.g., React, testing, design, deployment)\n2. The specific task (e.g., writing tests, creating animations, reviewing PRs)\n3. Whether this is a common enough task that a skill likely exists\n\n### Step 2: Check the Leaderboard First\n\nBefore running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.\n\nFor example, top skills for web development include:\n- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each)\n- `anthropics/skills` — Frontend design, document processing (100K+ installs)\n\n### Step 3: Search for Skills\n\nIf the leaderboard doesn't cover the user's need, call the `search_skills` tool:\n\n- User asks \"how do I make my React app faster?\" → `search_skills(\"react performance\")`\n- User asks \"can you help me with PR reviews?\" → `search_skills(\"pr review\")`\n- User asks \"I need to create a changelog\" → `search_skills(\"changelog\")`\n\nEach result includes an opaque `install_source`, source registry, review URL,\ninstall count, and available star count. Pass the exact `install_source` value\nto `install_skill`.\n\n### Step 4: Verify Quality Before Recommending\n\n**Do not recommend a skill based solely on search results.** Always verify:\n\n1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100.\n2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors.\n3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.\n\n### Step 5: Present Options to the User\n\nWhen you find relevant skills, present them to the user with:\n\n1. The skill name and what it does\n2. The install count and source\n3. That you can install it for them into Cherry\n4. A link to learn more at skills.sh\n\nExample response:\n\n```\nI found a skill that might help! The \"react-best-practices\" skill provides\nReact and Next.js performance optimization guidelines from Vercel Engineering.\n(185K installs)\n\nI can install it into Cherry's skill library for you — want me to go ahead?\n\nLearn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices\n```\n\n### Step 6: Install (Uses the Active Permission Mode)\n\n**⚠️ Security:** Skills are third-party code that runs with full agent\npermissions. A malicious skill could read, modify, or delete files on your\nsystem.\n\nBefore installing any skill:\n\n1. **Show a security warning** — tell the user that the skill is third-party\n code and will run with full agent permissions.\n2. **Provide a review link** — the skills.sh page (or source repository) so\n the user can review the skill's SKILL.md and any scripts it contains.\n3. **Require install intent** — call `install_skill` only when the user asked to install the skill\n or accepted a presented option. A search-only request must not mutate the skill library.\n\nOnce the user has expressed install intent, call `install_skill` with the exact `install_source`\nfrom the search result. Do not add another model-level confirmation step: Claude's active permission\nmode is the authority. Default and accept-edits modes may prompt through the SDK; bypass-permissions\nmode runs directly.\n\n- `install_skill(\"claude-plugins:vercel-labs/agent-skills/skills/react-best-practices\")`\n\nDo **not** run `npx skills add`, `git clone`, or any shell command to install — that would\ninstall the whole repo (dozens of skills), scatter symlinks across other tools, and land\noutside Cherry's library. `install_skill` installs **only that one skill** into Cherry's\nmanaged library in one deterministic step. The Claude Agent SDK applies the configured permission\nmode before it runs. Once done it is registered and listed in the app — nothing is left elsewhere.\n\n## Common Skill Categories\n\nWhen searching, consider these common categories:\n\n| Category | Example Queries |\n| --------------- | ---------------------------------------- |\n| Web Development | react, nextjs, typescript, css, tailwind |\n| Testing | testing, jest, playwright, e2e |\n| DevOps | deploy, docker, kubernetes, ci-cd |\n| Documentation | docs, readme, changelog, api-docs |\n| Code Quality | review, lint, refactor, best-practices |\n| Design | ui, ux, design-system, accessibility |\n| Productivity | workflow, automation, git |\n\n## Tips for Effective Searches\n\n1. **Use specific keywords**: \"react testing\" is better than just \"testing\"\n2. **Try alternative terms**: If \"deploy\" doesn't work, try \"deployment\" or \"ci-cd\"\n3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`\n\n## When No Skills Are Found\n\nIf no relevant skills exist:\n\n1. Acknowledge that no existing skill was found\n2. Offer to help with the task directly using your general capabilities\n3. Offer to author a custom skill for the task (the skill-creator skill handles this)\n\nExample:\n\n```\nI searched for skills related to \"xyz\" but didn't find any matches.\nI can still help you with this task directly! Would you like me to proceed?\n\nIf this is something you do often, I can author a custom skill for you — just ask\nme to \"create a skill for <task>\" and I'll write one into Cherry's skills directory.\n```\n","resources/skills/skill-creator/SKILL.md":"---\nname: skill-creator\ndescription: 'Create, edit, evaluate, and optimize skills, including benchmarking and description tuning for better triggering.'\nversion: 1.0.0\n---\n\n## Cherry Studio workflow (READ FIRST — overrides packaging / install steps below)\n\nYou are running inside Cherry Studio. Skills live in a managed registry that Cherry\nkeeps in sync with the filesystem automatically — there is **no** install or register\ntool to call, and you should **ignore** any `package_skill.py` / `.skill` packaging\nsteps mentioned later in this file (they apply to Claude Code / Claude.ai, not here).\n\n**To create a new skill, write it straight into Cherry's managed skills directory:**\n\n1. Resolve the directory once by running `echo \"$CHERRY_STUDIO_SKILLS_DIR\"` in Bash.\n That folder is Cherry's managed skill library.\n2. Create `$CHERRY_STUDIO_SKILLS_DIR/<skill-folder-name>/` and write `SKILL.md` plus any\n supporting files (`scripts/`, `references/`, `assets/`) into it with your normal file\n tools.\n3. That's it. Cherry's skill sync detects the new directory, registers it in the catalog,\n and lists it in the app — no register step. You can re-edit the files in place at any\n time and the changes are picked up on the next sync.\n\nUse a lowercase, hyphenated `<skill-folder-name>` (e.g. `my-cool-skill`). The `name:`\nfield inside your `SKILL.md` frontmatter must match the folder name and use only\nlowercase letters, numbers, and hyphens (e.g. `name: my-cool-skill` with folder\n`my-cool-skill`), per the Agent Skills spec — it is not a free-form display name.\n\nEval / test workspaces (`<skill-name>-workspace/`, `iteration-*/`, etc.) from the\nevaluation loop described below must be created **outside** that skills directory —\ne.g. as a sibling under the user's workspace — so they don't get bundled into the\nskill. The evaluation loop itself still applies; only the packaging and install\nmechanics change.\n\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nAt a high level, the process of creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft of the skill\n- Create a few test prompts and run claude-with-access-to-the-skill on them\n- Help the user evaluate the results both qualitatively and quantitatively\n - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)\n - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics\n- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like \"I want to make a skill for X\". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.\n\nOn the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.\n\nOf course, you should always be flexible and if the user is like \"I don't need to run a bunch of evaluations, just vibe with me\", you can do that instead.\n\nThen after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.\n\nCool? Cool.\n\n## Communicating with the user\n\nThe skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google \"how to install npm\". On the other hand, the bulk of users are probably fairly computer-literate.\n\nSo please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:\n\n- \"evaluation\" and \"benchmark\" are borderline, but OK\n- for \"JSON\" and \"assertion\" you want to see serious cues from the user that they know what those things are before using them without explaining them\n\nIt's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.\n\n---\n\n## Creating a skill\n\n### Capture Intent\n\nStart by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say \"turn this into a skill\"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.\n\n1. What should this skill enable Claude to do?\n2. When should this skill trigger? (what user phrases/contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.\n\n### Interview and Research\n\nProactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.\n\nCheck available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.\n\n### Write the SKILL.md\n\nBased on the user interview, fill in these components:\n\n- **name**: Skill identifier\n- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All \"when to use\" info goes here, not in the body. Note: currently Claude has a tendency to \"undertrigger\" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit \"pushy\". So for instance, instead of \"How to build a simple fast dashboard to display internal Anthropic data.\", you might write \"How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **compatibility**: Required tools, dependencies (optional, rarely needed)\n- **the rest of the skill :)**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled Resources (optional)\n ├── scripts/ - Executable code for deterministic/repetitive tasks\n ├── references/ - Docs loaded into context as needed\n └── assets/ - Files used in output (templates, icons, fonts)\n```\n\n#### Progressive Disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description) - Always in context (~100 words)\n2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)\n3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)\n\nThese word counts are approximate and you can feel free to go longer if needed.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.\n- Reference files clearly from SKILL.md with guidance on when to read them\n- For large reference files (>300 lines), include a table of contents\n\n**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:\n```\ncloud-deploy/\n├── SKILL.md (workflow + selection)\n└── references/\n ├── aws.md\n ├── gcp.md\n └── azure.md\n```\nClaude reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nThis goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a \"roleplay as an XYZ\" are OK though.\n\n#### Writing Patterns\n\nPrefer using the imperative form in instructions.\n\n**Defining output formats** - You can do it like this:\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** - It's useful to include examples. You can format them like this (but if \"Input\" and \"Output\" are in the examples you might want to deviate a little):\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n### Writing Style\n\nTry to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.\n\n### Test Cases\n\nAfter writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.\n\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\n \"id\": 1,\n \"prompt\": \"User's task prompt\",\n \"expected_output\": \"Description of expected result\",\n \"files\": []\n }\n ]\n}\n```\n\nSee `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.\n\nPut results in `<skill-name>-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: <path-to-skill>\n- Task: <eval prompt>\n- Input files: <eval files if any, or \"none\">\n- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/\n- Outputs to save: <what the user cares about — e.g., \"the .docx file\", \"the final CSV\">\n```\n\n**Baseline run** (same prompt, but the baseline depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.\n- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r <skill-path> <workspace>/skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.\n\nWrite an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just \"eval-0\". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.\n\n```json\n{\n \"eval_id\": 0,\n \"eval_name\": \"descriptive-name-here\",\n \"prompt\": \"The user's task prompt\",\n \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.\n\nUpdate the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:\n\n```json\n{\n \"total_tokens\": 84852,\n \"duration_ms\": 23332,\n \"total_duration_seconds\": 23.3\n}\n```\n\nThis is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.\n\n2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:\n ```bash\n python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>\n ```\n This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.\nPut each with_skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the \"Analyzing Benchmark Results\" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n ```bash\n nohup python <skill-creator-path>/eval-viewer/generate_review.py \\\n <workspace>/iteration-N \\\n --skill-name \"my-skill\" \\\n --benchmark <workspace>/iteration-N/benchmark.json \\\n > /dev/null 2>&1 &\n VIEWER_PID=$!\n ```\n For iteration 2+, also pass `--previous-workspace <workspace>/iteration-<N-1>`.\n\n **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks \"Submit All Reviews\". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.\n\nNote: please use generate_review.py to create the viewer; there's no need to write custom HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): collapsed section showing last iteration's output\n- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.\n\nNavigation is via prev/next buttons or arrow keys. When done, they click \"Submit All Reviews\" which saves all feedback to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user tells you they're done, read `feedback.json`:\n\n```json\n{\n \"reviews\": [\n {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n ],\n \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.\n\nKill the viewer server when you're done with it:\n\n```bash\nkill $VIEWER_PID 2>/dev/null\n```\n\n---\n\n## Improving the skill\n\nThis is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.\n\n3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.\n\n4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.\n\nThis task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply your improvements to the skill\n2. Rerun all test cases into a new `iteration-<N+1>/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and tell you they're done\n5. Read the new feedback, improve again, repeat\n\nKeep going until:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n---\n\n## Advanced: Blind comparison\n\nFor situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks \"is the new version actually better?\"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.\n\nThis is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n---\n\n## Description Optimization\n\nThe description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n {\"query\": \"the user prompt\", \"should_trigger\": true},\n {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nFor the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.\n\nFor the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.\n\nThe key thing to avoid: don't make should-not-trigger queries obviously irrelevant. \"Write a fibonacci function\" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.\n\n### Step 2: Review with user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read the template from `assets/eval_review.html`\n2. Replace the placeholders:\n - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)\n - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file (e.g., `/tmp/eval_review_<skill-name>.html`) and open it: `open /tmp/eval_review_<skill-name>.html`\n4. The user can edit queries, toggle should-trigger, add/remove entries, then click \"Export Eval Set\"\n5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)\n\nThis step matters — bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take some time — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run in the background:\n\n```bash\npython -m scripts.run_loop \\\n --eval-set <path-to-trigger-eval.json> \\\n --skill-path <path-to-skill> \\\n --model <model-id-powering-this-session> \\\n --max-iterations 5 \\\n --verbose\n```\n\nUse the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.\n\nWhile it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.\n\nThis handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.\n\n### How skill triggering works\n\nUnderstanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like \"read this PDF\" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.\n\nThis means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like \"read file X\" are poor test cases — they won't trigger skills regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.\n\n---\n\n### Package and Present (only if `present_files` tool is available)\n\nCheck whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:\n\n```bash\npython -m scripts.package_skill <path/to/skill-folder>\n```\n\nAfter packaging, direct the user to the resulting `.skill` file path so they can install it.\n\n---\n\n## Claude.ai-specific instructions\n\nIn Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:\n\n**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.\n\n**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: \"How does this look? Anything you'd change?\"\n\n**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.\n\n**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.\n\n**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.\n\n**Blind comparison**: Requires subagents. Skip it.\n\n**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.\n\n**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).\n- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.\n- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.\n\n---\n\n## Cowork-Specific Instructions\n\nIf you're in Cowork, the main things to know are:\n\n- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)\n- You don't have a browser or display, so when generating the eval viewer, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.\n- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!\n- Feedback works differently: since there's no running server, the viewer's \"Submit All Reviews\" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).\n- Packaging works — `package_skill.py` just needs Python and a filesystem.\n- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.\n- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.\n\n---\n\n## Reference files\n\nThe agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.\n\n- `agents/grader.md` — How to evaluate assertions against outputs\n- `agents/comparator.md` — How to do blind A/B comparison between two outputs\n- `agents/analyzer.md` — How to analyze why one version beat another\n\nThe references/ directory has additional documentation:\n- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.\n\n---\n\nRepeating one more time the core loop here for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill\n- Run claude-with-access-to-the-skill on test prompts\n- With the user, evaluate the outputs:\n - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them\n - Run quantitative evals\n- Repeat until you and the user are satisfied\n- Package the final skill and return it to the user.\n\nPlease add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put \"Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases\" in your TodoList to make sure it happens.\n\nGood luck!\n","resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md":"# cherry-assistant-guide\n\nPath: `resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md)","CLAUDE.md":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/CLAUDE.md)",".claude/skills/.gitignore":"# Claude Directive: .gitignore\n\nPath: `.claude/skills/.gitignore`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/.gitignore)",".claude/skills/README.md":"# Skills Skill\n\nPath: `.claude/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.md)",".claude/skills/README.zh.md":"# Skills Skill\n\nPath: `.claude/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.zh.md)",".agents/skills/README.md":"# Skills Skill\n\nPath: `.agents/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.md)",".agents/skills/README.zh.md":"# Skills Skill\n\nPath: `.agents/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.zh.md)","packages/extension-table-plus/CHANGELOG.md":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG.md)","packages/extension-table-plus/CHANGELOG-OLD.md":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/CHANGELOG-OLD.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG-OLD.md)","packages/extension-table-plus/package.json":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/package.json)","packages/extension-table-plus/README.md":"# extension-table-plus Documentation\n\nPath: `packages/extension-table-plus/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/README.md)","packages/extension-table-plus/tsconfig.json":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/tsconfig.json)","packages/aiCore/CHANGELOG.md":"# AiCore Skill\n\nPath: `packages/aiCore/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/CHANGELOG.md)","packages/aiCore/package.json":"# AiCore Skill\n\nPath: `packages/aiCore/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/package.json)","packages/aiCore/README.md":"# aiCore Documentation\n\nPath: `packages/aiCore/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/README.md)","packages/aiCore/tsconfig.json":"# AiCore Skill\n\nPath: `packages/aiCore/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/tsconfig.json)","packages/ai-sdk-provider/CHANGELOG.md":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/CHANGELOG.md)","packages/ai-sdk-provider/package.json":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/package.json)","packages/ai-sdk-provider/README.md":"# ai-sdk-provider Documentation\n\nPath: `packages/ai-sdk-provider/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/README.md)","packages/ai-sdk-provider/tsconfig.json":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/tsconfig.json)",".agents/skills/vercel-react-best-practices/AGENTS.md":"# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/AGENTS.md)",".agents/skills/vercel-react-best-practices/README.md":"# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/README.md)","docs/en/references/app-upgrade.md":"# References Skill\n\nPath: `docs/en/references/app-upgrade.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/app-upgrade.md)","docs/en/references/feishu-notify.md":"# References Skill\n\nPath: `docs/en/references/feishu-notify.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/feishu-notify.md)","docs/en/references/fuzzy-search.md":"# References Skill\n\nPath: `docs/en/references/fuzzy-search.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/fuzzy-search.md)","docs/zh/references/app-upgrade.md":"# References Skill\n\nPath: `docs/zh/references/app-upgrade.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/app-upgrade.md)","docs/zh/references/code-execution.md":"# References Skill\n\nPath: `docs/zh/references/code-execution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/code-execution.md)","docs/zh/references/database.md":"# References Skill\n\nPath: `docs/zh/references/database.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/database.md)","docs/zh/references/feishu-notify.md":"# References Skill\n\nPath: `docs/zh/references/feishu-notify.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/feishu-notify.md)","docs/zh/references/fuzzy-search.md":"# References Skill\n\nPath: `docs/zh/references/fuzzy-search.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/fuzzy-search.md)","docs/zh/references/lan-transfer-protocol.md":"# References Skill\n\nPath: `docs/zh/references/lan-transfer-protocol.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/lan-transfer-protocol.md)","docs/zh/references/message-system.md":"# References Skill\n\nPath: `docs/zh/references/message-system.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/message-system.md)","docs/zh/references/services.md":"# References Skill\n\nPath: `docs/zh/references/services.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/services.md)",".agents/skills/gh-create-pr/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/gh-create-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-pr/agents/openai.yaml)",".agents/skills/gh-pr-review/references/checklist-evolution.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/checklist-evolution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/checklist-evolution.md)",".agents/skills/gh-pr-review/references/code-checklist.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/code-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/code-checklist.md)",".agents/skills/gh-pr-review/references/diagnosis.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/diagnosis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/diagnosis.md)",".agents/skills/gh-pr-review/references/doc-checklist.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/doc-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/doc-checklist.md)",".agents/skills/gh-pr-review/references/judgment-matrix.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/judgment-matrix.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/judgment-matrix.md)",".agents/skills/gh-pr-review/references/local-review.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/local-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/local-review.md)",".agents/skills/gh-pr-review/references/pr-review.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/pr-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/pr-review.md)",".agents/skills/gh-pr-review/references/teams-review.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/teams-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/teams-review.md)",".agents/skills/gh-pr-review/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/gh-pr-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/agents/openai.yaml)",".agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md)",".agents/skills/vercel-react-best-practices/rules/advanced-init-once.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md)",".agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md)",".agents/skills/vercel-react-best-practices/rules/async-api-routes.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-api-routes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-api-routes.md)",".agents/skills/vercel-react-best-practices/rules/async-defer-await.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-defer-await.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-defer-await.md)",".agents/skills/vercel-react-best-practices/rules/async-dependencies.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-dependencies.md)",".agents/skills/vercel-react-best-practices/rules/async-parallel.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-parallel.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-parallel.md)",".agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md)",".agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md)",".agents/skills/vercel-react-best-practices/rules/bundle-conditional.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md)",".agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md)",".agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md)",".agents/skills/vercel-react-best-practices/rules/bundle-preload.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-preload.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-preload.md)",".agents/skills/vercel-react-best-practices/rules/client-event-listeners.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md)",".agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md)",".agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md)",".agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md)",".agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md)",".agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md)",".agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md)",".agents/skills/vercel-react-best-practices/rules/js-cache-storage.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md)",".agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md)",".agents/skills/vercel-react-best-practices/rules/js-early-exit.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-early-exit.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-early-exit.md)",".agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md)",".agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md)",".agents/skills/vercel-react-best-practices/rules/js-index-maps.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-index-maps.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-index-maps.md)",".agents/skills/vercel-react-best-practices/rules/js-length-check-first.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md)",".agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md)",".agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md)",".agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md)",".agents/skills/vercel-react-best-practices/rules/rendering-activity.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-activity.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-activity.md)",".agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md)",".agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md)",".agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md)",".agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md)",".agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md)",".agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md)",".agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md)",".agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md)",".agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md)",".agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md)",".agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md)",".agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md)",".agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md)",".agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md)",".agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md)",".agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md)",".agents/skills/vercel-react-best-practices/rules/rerender-memo.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-memo.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo.md)",".agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md)",".agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md)",".agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md)",".agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md)",".agents/skills/vercel-react-best-practices/rules/rerender-transitions.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md)",".agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md)",".agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md)",".agents/skills/vercel-react-best-practices/rules/server-auth-actions.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md)",".agents/skills/vercel-react-best-practices/rules/server-cache-lru.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md)",".agents/skills/vercel-react-best-practices/rules/server-cache-react.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-cache-react.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-react.md)",".agents/skills/vercel-react-best-practices/rules/server-dedup-props.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md)",".agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md)",".agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md)",".agents/skills/vercel-react-best-practices/rules/server-serialization.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-serialization.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-serialization.md)","docs/en/references/components/code-block-view.md":"# Components Skill\n\nPath: `docs/en/references/components/code-block-view.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/code-block-view.md)","docs/en/references/components/image-preview.md":"# Components Skill\n\nPath: `docs/en/references/components/image-preview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/image-preview.md)","docs/zh/references/cherryclaw/channels.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/channels.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/channels.md)","docs/zh/references/cherryclaw/mcp-claw.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/mcp-claw.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/mcp-claw.md)","docs/zh/references/cherryclaw/overview.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/overview.md)","docs/zh/references/cherryclaw/scheduler.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/scheduler.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/scheduler.md)","docs/zh/references/components/code-block-view.md":"# Components Skill\n\nPath: `docs/zh/references/components/code-block-view.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/code-block-view.md)","docs/zh/references/components/image-preview.md":"# Components Skill\n\nPath: `docs/zh/references/components/image-preview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/image-preview.md)","resources/skills/skill-creator/agents/analyzer.md":"# Subagent: analyzer\n\nPath: `resources/skills/skill-creator/agents/analyzer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/analyzer.md)","resources/skills/skill-creator/agents/comparator.md":"# Subagent: comparator\n\nPath: `resources/skills/skill-creator/agents/comparator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/comparator.md)","resources/skills/skill-creator/agents/grader.md":"# Subagent: grader\n\nPath: `resources/skills/skill-creator/agents/grader.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/grader.md)","resources/skills/skill-creator/references/schemas.md":"# References Skill\n\nPath: `resources/skills/skill-creator/references/schemas.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/references/schemas.md)","src/main/services/agents/README.md":"# Subagent: readme\n\nPath: `src/main/services/agents/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/src/main/services/agents/README.md)"},"files":{".agents/skills/gh-create-pr/SKILL.md":"---\nname: gh-create-pr\ndescription: Create or update GitHub pull requests using the repository-required workflow and template compliance. Use when asked to create/open/update a PR so the assistant reads `.github/pull_request_template.md`, fills every template section, preserves markdown structure exactly, and marks missing data as N/A or None instead of skipping sections.\n---\n\n# GitHub PR Creation\n\n## Stack tooling\n\nThis repository ships `.agents/skills/gh-stack/SKILL.md` as a public project skill; developers do not install the agent skill separately. Read it before operating on stacked branches or PRs. Agents that consume `.agents/skills/` discover it directly. If a Claude checkout is missing `.claude/skills/gh-stack`, run `pnpm skills:sync` followed by `pnpm skills:check`; do not download a separate global copy.\n\nBefore the first `gh stack` command in a task, verify the GitHub CLI and install the official extension if it is missing:\n\n```bash\ncommand -v gh >/dev/null 2>&1 || {\n echo \"GitHub CLI is required: https://cli.github.com/\" >&2\n exit 1\n}\ngh auth status\nif ! gh stack --help >/dev/null 2>&1; then\n gh extension install github/gh-stack\nfi\ngh stack --help >/dev/null\n```\n\nStop if authentication, installation, or the final verification fails. Do not infer a stack with ad hoc Git commands. For human-authored Cherry PRs, use `gh stack push`, create each compliant PR through this skill from bottom to top, then link the existing PRs with `gh stack link`; `gh stack submit --auto` creates PRs outside the template-compliant body flow and must not bypass this workflow.\n\n## Workflow\n\n1. Read `.github/pull_request_template.md` before drafting the PR body.\n2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content). Resolve the live base and run `pnpm change:scope --base <verified-base-ref>`; do not infer scope from the latest commit alone.\n3. Read `.agents/notes/README.md` and classify the change:\n - Fill `Agent Note` with the repository path, or `N/A — <reason>` for a local/mechanical change.\n - For a Spec PR, fill `Spec PR: This PR` and list every AC.\n - For an implementation layer, link the Spec PR and list only the AC IDs covered by this layer. Verify an `APPROVED` review whose `commit_id` equals the current Spec head; a stale approval does not authorize implementation.\n - For a direct bug fix with durable rationale, link its implemented `bug-fix` note and use `Spec PR: N/A`.\n - Automation-authored PRs (repository workflows and Dependabot) are exempt from these metadata fields. Do not make their bodies imitate a human-authored PR.\n4. For an implementation PR, complete the stack tooling preflight, then run `gh stack view --json`. If it exits 2, follow the `gh-stack` skill's remote-discovery procedure; missing local metadata does not prove the PR is standalone. Inspect every downstack implementation PR and aggregate only ACs backed by actual verification. Keep the note proposed on intermediate layers. If the current PR is the final layer and cumulative evidence covers the complete approved Spec, move the bilingual triplet to `implemented/` and run `pnpm agent-notes:check-transition --base <verified-spec-ref>` before publishing.\n5. Fill `Verification` with commands and scenarios actually run. Never present a planned, pending, skipped, or CI-only check as passed.\n6. Check if the current branch has been pushed to remote. If not, push it first:\n - Default remote is `origin`, but ask the user if they want to use a different remote.\n ```bash\n git push -u <remote> <head-branch>\n ```\n7. Determine the base branch:\n - Inspect the head branch before applying any default. If the head is `release/v<version>`, stop: never open a pull request from a release branch, especially not to `main`. Put an isolated fix on a topic branch and target the release branch, or let Post Release create the metadata sync branch.\n - Before defaulting an arbitrary topic branch to `main`, inspect its merge base and upstream. A product-code fix that started from `release/v<version>` must stop and be recreated from `main` as a hotfix; only a release-only repair or explicit backport recovery topic may target that exact release branch.\n - A `backport/v<version>/pr-<number>` head must target the matching `release/v<version>` base and its body must contain `<!-- release-backport-source-pr: <number> -->` on its own line for the exact source hotfix PR. A `release-sync/v<version>` head must target `main`, use the exact title `chore(release): sync v<version> metadata`, retain the `release-metadata-boundary: v<version>` body marker, and be squash-merged.\n - For official repo(CherryHQ/cherry-studio) as `origin`: default base is `main` from `origin`, but allow the user to explicitly indicate a base branch.\n - `main` is the active development line, including hotfix PRs. Do not target an old maintenance branch unless the user explicitly requests it.\n - Only classify a PR as a release hotfix when the user explicitly says it must be included in the active draft release. Use the title `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` with a lowercase alphanumeric kebab-case scope, exactly one space after the colon, and a non-empty description. The title grammar synchronizes the `hotfix` label automatically. Merging opens a separate backport PR only when exactly one draft semantic-version release has a matching active `release/v<version>` branch; otherwise automation stops without guessing a target.\n - If the hotfix is user-facing, provide one release-note line in each language so automation can update the active draft and stable release history. Put this exact structure inside the template's existing `release-note` fence; do not include bullet prefixes:\n ```text\n <!--LANG:en-->\n [Component] English description.\n <!--LANG:zh-CN-->\n [组件] 中文说明。\n <!--LANG:END-->\n ```\n - If the hotfix has no user-facing release note, keep `NONE` in the template's `release-note` fence. The code is still backported, but release metadata is unchanged. A provided bilingual block must satisfy the exact structure above.\n - For fork repo as `origin`: check available remotes with `git remote -v`, default base may be `upstream/main` or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.\n - Ask the user to confirm the base branch if it's not the default.\n8. Create a temp file and write the PR body using a single Bash heredoc\n (avoids `mktemp` + `Write` tool path-mismatch on Windows):\n ```bash\n pr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\n cat > \"$pr_body_file\" <<'EOF'\n ...filled template body...\n EOF\n ```\n Fill content using the template structure exactly (keep section order,\n headings, checkbox formatting). If not applicable, write `N/A` or `None`.\n9. Inspect the temp file content via Bash `cat \"$pr_body_file\"` (the `Read`\n tool can fail on `/tmp/...` paths on Windows). If the user requests a preview\n or confirmation, show the full body and follow that request; otherwise,\n proceed with the authorized PR creation.\n10. Create the PR, adding `--draft` when the user requests a draft:\n ```bash\n gh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\n ```\n For a release hotfix, use an exact classifier-compatible title so the workflow synchronizes the label and separately validates any provided bilingual note:\n ```bash\n gh pr create --base main --head <head> --title \"hotfix: <description>\" --body-file \"$pr_body_file\"\n ```\n After creation, verify that the classifier added `hotfix`; if it did not, fix the title instead of adding the label manually. Also fix any malformed optional release-note block reported by the workflow.\n11. Clean up the temp file: `rm -f \"$pr_body_file\"`\n12. Report the created PR URL and summarize title/base/head, Agent Note/Spec, AC coverage, actual verification, and any required follow-up.\n\n## Constraints\n\n- Never skip template sections.\n- Never rewrite the template format.\n- Keep content concise and specific to the current change set.\n- PR title and body must be written in English.\n- Never use a `hotfix` title or label for an ordinary bug fix. It opts the PR into an automatic backport PR after merge when one matching draft release is active.\n- A release hotfix may use `NONE` when it has no user-facing release note. Never provide a partial, single-language, or otherwise malformed bilingual note; the backport workflow fails closed on malformed content.\n- Never default a `release/v<version>` head to `main`; a release branch is not a pull request source branch.\n- Never publish an implementation PR as ready when its current Spec head lacks an exact-head Approval. A Spec may remain unmerged and serve as the stack base.\n- Every human-authored PR fills `Agent Note`, `Spec PR`, and `Acceptance criteria`; `N/A` requires a concise reason. Automation-authored PRs (repository workflows and Dependabot) are exempt from this metadata requirement.\n- **Release note & Documentation checkbox** — both are driven by whether the change is **user-facing**. Use the table below:\n\n | Change type | Release note | Docs `[x]` |\n |---|---|---|\n | New user-facing feature / setting / UI | Describe the change | ✅ |\n | Bug fix visible to users | Describe the fix | ✅ if behavior changed |\n | Behavior change / default value change | Describe + `action required` | ✅ |\n | Security fix in a user-facing dependency | Describe the fix | ✅ if usage changed |\n | CI / GitHub Actions changes | `NONE` | ❌ |\n | Internal refactoring (user cannot tell) | `NONE` | ❌ |\n | Dev / build tooling changes | `NONE` | ❌ |\n | Dev-only dependency bump | `NONE` | ❌ |\n | Test-only / code style changes | `NONE` | ❌ |\n\n## Command Pattern\n\n```bash\n# read template\ncat .github/pull_request_template.md\n\n# prepare and inspect the PR body\npr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\ncat > \"$pr_body_file\" <<'EOF'\n...filled template body...\nEOF\ncat \"$pr_body_file\"\n\n# create the authorized PR; add --draft when requested\ngh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\nrm -f \"$pr_body_file\"\n```\n",".agents/skills/create-skill/SKILL.md":"---\nname: create-skill\ndescription: Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills.\n---\n\n# Create Skill\n\nCreate a new skill in `.agents/skills/<skill-name>/` following the workflow defined in `.agents/skills/README.md`.\n\n## Workflow\n\n### Step 1: Gather Intent\n\nBefore creating anything, ask the user:\n\n1. **Skill name**: What should the skill be called? (lowercase, digits, hyphens only, e.g., `gh-create-pr`, `prepare-release`)\n2. **Description**: What should this skill do? Include specific trigger contexts (e.g., \"Use when user asks to create PRs\")\n3. **Is this a public skill?**: Should it be synced to `.claude/skills/` for shared use? (default: no, private only)\n4. **Test cases** (optional): Does the user want to set up evals for this skill?\n\nIf the user provides partial info (e.g., just a name), proceed with reasonable defaults and ask to confirm.\n\n### Step 2: Read Guidelines\n\nAlways read `.agents/skills/README.md` before creating a new skill to ensure compliance with the current workflow.\n\n### Step 3: Create Skill Structure\n\nCreate the following directory structure:\n\n```\n.agents/skills/<skill-name>/\n└── SKILL.md\n```\n\n**SKILL.md template:**\n\n```markdown\n---\nname: <skill-name>\ndescription: <description>\n---\n\n# <Skill Name>\n\n[Instructions for the skill]\n```\n\n**Frontmatter fields:**\n- `name`: Skill identifier (lowercase, digits, hyphens)\n- `description`: When to trigger (what the skill does + specific contexts)\n\n### Step 4: Sync (if public)\n\nIf the user wants a **public skill**, before validation:\n\n1. Add the skill name to `.agents/skills/public-skills.txt` (one per line, no inline comments)\n2. Run sync:\n ```bash\n pnpm skills:sync\n ```\n\nThis creates a symlink at `.claude/skills/<skill-name>/` pointing to `.agents/skills/<skill-name>/`.\n\n**Note**: `pnpm skills:check` primarily validates public skills (those in `public-skills.txt`) and also verifies related governance files, so you must sync first before validating.\n\n### Step 5: Validate\n\nRun the validation command:\n\n```bash\npnpm skills:check\n```\n\nIf there are issues, fix them and re-run.\n\n### Step 6: Summary\n\nPresent the user with:\n- Created files\n- Validation result\n- Next steps (how to use the skill)\n\n## Naming Rules\n\n- Use lowercase letters, digits, and hyphens only\n- Prefer short, action-oriented names (e.g., `gh-create-pr`)\n\n## Public vs Private Skills\n\n| Type | Location | Sync | Requires |\n|------|----------|------|----------|\n| Private | `.agents/skills/` | No | Just create the folder |\n| Public | Both | Yes | Add to `public-skills.txt` + run `pnpm skills:sync` |\n\n## Commands Reference\n\n```bash\n# Validate skill structure\npnpm skills:check\n\n# Sync public skills to Claude\npnpm skills:sync\n```\n\n## Constraints\n\n- Never create skills outside `.agents/skills/<skill-name>/`\n- Always run `pnpm skills:check` before completing\n- Public skills require both adding to `public-skills.txt` AND running `pnpm skills:sync`\n- If the skill-creator skill is available, you may use it for advanced skill development (evals, iterations), but this skill handles the basic creation workflow.\n",".agents/skills/vercel-react-best-practices/SKILL.md":"---\nname: vercel-react-best-practices\ndescription: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.\nlicense: MIT\nmetadata:\n author: vercel\n version: \"1.0.0\"\n---\n\n# Vercel React Best Practices\n\nComprehensive performance optimization guide for React and Next.js applications, maintained by Vercel. Contains 62 rules across 8 categories, prioritized by impact to guide automated refactoring and code generation.\n\n## When to Apply\n\nReference these guidelines when:\n- Writing new React components or Next.js pages\n- Implementing data fetching (client or server-side)\n- Reviewing code for performance issues\n- Refactoring existing React/Next.js code\n- Optimizing bundle size or load times\n\n## Rule Categories by Priority\n\n| Priority | Category | Impact | Prefix |\n|----------|----------|--------|--------|\n| 1 | Eliminating Waterfalls | CRITICAL | `async-` |\n| 2 | Bundle Size Optimization | CRITICAL | `bundle-` |\n| 3 | Server-Side Performance | HIGH | `server-` |\n| 4 | Client-Side Data Fetching | MEDIUM-HIGH | `client-` |\n| 5 | Re-render Optimization | MEDIUM | `rerender-` |\n| 6 | Rendering Performance | MEDIUM | `rendering-` |\n| 7 | JavaScript Performance | LOW-MEDIUM | `js-` |\n| 8 | Advanced Patterns | LOW | `advanced-` |\n\n## Quick Reference\n\n### 1. Eliminating Waterfalls (CRITICAL)\n\n- `async-defer-await` - Move await into branches where actually used\n- `async-parallel` - Use Promise.all() for independent operations\n- `async-dependencies` - Use better-all for partial dependencies\n- `async-api-routes` - Start promises early, await late in API routes\n- `async-suspense-boundaries` - Use Suspense to stream content\n\n### 2. Bundle Size Optimization (CRITICAL)\n\n- `bundle-barrel-imports` - Import directly, avoid barrel files\n- `bundle-dynamic-imports` - Use next/dynamic for heavy components\n- `bundle-defer-third-party` - Load analytics/logging after hydration\n- `bundle-conditional` - Load modules only when feature is activated\n- `bundle-preload` - Preload on hover/focus for perceived speed\n\n### 3. Server-Side Performance (HIGH)\n\n- `server-auth-actions` - Authenticate server actions like API routes\n- `server-cache-react` - Use React.cache() for per-request deduplication\n- `server-cache-lru` - Use LRU cache for cross-request caching\n- `server-dedup-props` - Avoid duplicate serialization in RSC props\n- `server-hoist-static-io` - Hoist static I/O (fonts, logos) to module level\n- `server-serialization` - Minimize data passed to client components\n- `server-parallel-fetching` - Restructure components to parallelize fetches\n- `server-after-nonblocking` - Use after() for non-blocking operations\n\n### 4. Client-Side Data Fetching (MEDIUM-HIGH)\n\n- `client-swr-dedup` - Use SWR for automatic request deduplication\n- `client-event-listeners` - Deduplicate global event listeners\n- `client-passive-event-listeners` - Use passive listeners for scroll\n- `client-localstorage-schema` - Version and minimize localStorage data\n\n### 5. Re-render Optimization (MEDIUM)\n\n- `rerender-defer-reads` - Don't subscribe to state only used in callbacks\n- `rerender-memo` - Extract expensive work into memoized components\n- `rerender-memo-with-default-value` - Hoist default non-primitive props\n- `rerender-dependencies` - Use primitive dependencies in effects\n- `rerender-derived-state` - Subscribe to derived booleans, not raw values\n- `rerender-derived-state-no-effect` - Derive state during render, not effects\n- `rerender-functional-setstate` - Use functional setState for stable callbacks\n- `rerender-lazy-state-init` - Pass function to useState for expensive values\n- `rerender-simple-expression-in-memo` - Avoid memo for simple primitives\n- `rerender-move-effect-to-event` - Put interaction logic in event handlers\n- `rerender-transitions` - Use startTransition for non-urgent updates\n- `rerender-use-ref-transient-values` - Use refs for transient frequent values\n- `rerender-no-inline-components` - Don't define components inside components\n\n### 6. Rendering Performance (MEDIUM)\n\n- `rendering-animate-svg-wrapper` - Animate div wrapper, not SVG element\n- `rendering-content-visibility` - Use content-visibility for long lists\n- `rendering-hoist-jsx` - Extract static JSX outside components\n- `rendering-svg-precision` - Reduce SVG coordinate precision\n- `rendering-hydration-no-flicker` - Use inline script for client-only data\n- `rendering-hydration-suppress-warning` - Suppress expected mismatches\n- `rendering-activity` - Use Activity component for show/hide\n- `rendering-conditional-render` - Use ternary, not && for conditionals\n- `rendering-usetransition-loading` - Prefer useTransition for loading state\n- `rendering-resource-hints` - Use React DOM resource hints for preloading\n- `rendering-script-defer-async` - Use defer or async on script tags\n\n### 7. JavaScript Performance (LOW-MEDIUM)\n\n- `js-batch-dom-css` - Group CSS changes via classes or cssText\n- `js-index-maps` - Build Map for repeated lookups\n- `js-cache-property-access` - Cache object properties in loops\n- `js-cache-function-results` - Cache function results in module-level Map\n- `js-cache-storage` - Cache localStorage/sessionStorage reads\n- `js-combine-iterations` - Combine multiple filter/map into one loop\n- `js-length-check-first` - Check array length before expensive comparison\n- `js-early-exit` - Return early from functions\n- `js-hoist-regexp` - Hoist RegExp creation outside loops\n- `js-min-max-loop` - Use loop for min/max instead of sort\n- `js-set-map-lookups` - Use Set/Map for O(1) lookups\n- `js-tosorted-immutable` - Use toSorted() for immutability\n- `js-flatmap-filter` - Use flatMap to map and filter in one pass\n\n### 8. Advanced Patterns (LOW)\n\n- `advanced-event-handler-refs` - Store event handlers in refs\n- `advanced-init-once` - Initialize app once per app load\n- `advanced-use-latest` - useLatest for stable callback refs\n\n## How to Use\n\nRead individual rule files for detailed explanations and code examples:\n\n```\nrules/async-parallel.md\nrules/bundle-barrel-imports.md\n```\n\nEach rule file contains:\n- Brief explanation of why it matters\n- Incorrect code example with explanation\n- Correct code example with explanation\n- Additional context and references\n\n## Full Compiled Document\n\nFor the complete guide with all rules expanded: `AGENTS.md`\n",".agents/skills/gh-create-issue/SKILL.md":"---\nname: gh-create-issue\ndescription: Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.\n---\n\n# GitHub Create Issue\n\nUse this skill when the user requests to create an issue. Must follow the repository's issue template format.\n\n## Workflow\n\n### Step 1: Determine Template Type\n\nAnalyze the user's request to determine the issue type:\n- If the user describes a problem, error, crash, or something not working -> Bug Report\n- If the user requests a new feature, enhancement, or additional support -> Feature Request\n- If the user is asking a question or needs help with something -> Questions & Discussion\n- If the user describes engineering work with no user-facing behavior change (a follow-up deferred from a pull request, technical debt, refactoring, tooling or CI work) -> Engineering Task\n- Otherwise -> Others\n\nEngineering Task is not a GitHub issue form and is not offered to regular users. Only select it when the request clearly describes internal engineering work.\n\n**If unclear**, ask the user which template to use. Do not default to \"Others\" on your own.\n\n#### Eligibility Check (Engineering Task only)\n\nEngineering Task is meant for maintainers and collaborators with write access. This is a request,\nnot an access control — nothing prevents anyone from calling `gh issue create` directly, and this\nskill does not try to. The check below is here so that a contributor without write access learns\nthat early and gets pointed somewhere more useful.\n\nBefore collecting any information, read the authenticated user's permission level:\n\n```bash\nrepo=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\nuser=\"$(gh api user --jq .login)\"\npermission=\"$(gh api \"repos/$repo/collaborators/$user/permission\" --jq .permission 2>/dev/null)\"\ncase \"$permission\" in\n admin | write) echo \"eligible\" ;;\n *) echo \"not eligible\" ;;\nesac\n```\n\nOnly `admin` and `write` are eligible (`maintain` reports as `write`). Always compare the returned\nvalue: on a public repository this endpoint answers `read` for any user, including one who is not a\ncollaborator at all, so a successful call proves nothing on its own. Do not use\n`repos/{owner}/{repo}/collaborators/{user}` here — it answers `204` for `read`- and `triage`-only\ncollaborators, who are not the intended audience for this template.\n\nIf the result is anything else, do not use this template. Explain that it is meant for maintainers\nwith write access, politely ask the contributor to use one of the public templates instead, and\noffer to help them file it there — their report is welcome, just not under this template. Do not\nquietly switch templates while keeping the Engineering Task labels or issue type.\n\n### Step 2: Read the Selected Template\n\n1. Read the corresponding template file from `.github/ISSUE_TEMPLATE/` directory.\n2. Identify required fields (`validations.required: true`), title prefix (`title`), labels (`labels`, if present), and issue type (`type`, if present).\n\nFor Engineering Task, read [references/engineering-task.md](references/engineering-task.md) instead — it lives outside `.github/ISSUE_TEMPLATE/` on purpose and carries its own title prefix, labels, issue type, and body structure.\n\n### Step 3: Collect Information\n\nBased on the selected template, ask the user for required information only. Follow the template's required fields and option constraints (for example, Platform and Priority choices).\n\n### Step 4: Build and Preview Issue Content\n\nCreate a temp file and write the issue content:\n- Use `issue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"`\n- Use the exact title prefix from the selected template.\n- Fill content following the template body structure and section order.\n- Apply labels exactly as defined by the template.\n- Keep all labels when there are multiple labels.\n- If template has no labels, do not add custom labels.\n- Apply the issue type exactly as defined by the template's `type` field.\n\nPreview the temp file content. **Show the file path** (e.g., `/tmp/gh-issue-body-XXXXXX.md`) and ask for confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).\n\n### Step 5: Create Issue\n\nUse `gh issue create` command to create the issue.\n\nUse a unique temp file for the body:\n\n```bash\nissue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"\ncat > \"$issue_body_file\" <<'EOF'\n...issue body built from selected template...\nEOF\n```\n\nCreate the issue using values from the selected template:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\"\n```\n\nIf the selected template includes labels, append one `--label` per label:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --label \"<label_1_from_template>\" --label \"<label_2_from_template>\"\n```\n\nIf the selected template has no labels, do not pass `--label`.\n\nIf the selected template declares a `type`, pass it as well. `--body-file` does not carry the issue type over on its own, so omitting this leaves the issue untyped:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --type \"<type_from_template>\"\n```\n\n`--template` and `--web` resolve against `.github/ISSUE_TEMPLATE/` on the default branch, so neither works for Engineering Task. Build the body locally for it.\n\nFor the other templates you may use `--template` as a starting point (use the exact template name from the repository):\n\n```bash\ngh issue create --template \"<template_name>\"\n```\n\nUse the `--web` flag to open the creation page in browser when complex formatting is needed:\n\n```bash\ngh issue create --web\n```\n\nClean up the temp file after creation:\n\n```bash\nrm -f \"$issue_body_file\"\n```\n\n## Notes\n\n- Must read template files under `.github/ISSUE_TEMPLATE/` (or `references/` for Engineering Task) to ensure following the correct format.\n- Treat template files as the only source of truth. Do not hardcode title prefixes, labels, or issue types in this skill.\n- Title must be clear and concise, avoid vague terms like \"a suggestion\" or \"stuck\".\n- Provide as much detail as possible to help developers understand and resolve the issue.\n- If user doesn't specify a template type, ask them to choose one first.\n",".agents/skills/gh-pr-review/SKILL.md":"---\nname: gh-pr-review\ndescription: Automated Cherry Studio review for local branches, PRs, commits, files, architecture docs, and repository skills. Use for code or documentation reviews that need project-specific naming, main/renderer/shared placement and dependency rules, IpcApi and DataApi boundaries, lifecycle/service ownership, renderer hooks, React/UI conventions, and tests. Review depth adapts to diff size and runtime subagent capability (single-agent or multi-agent reviewer-verifier). Report-only by default; code fixes and GitHub submission each require explicit invocation-time authorization (`fix` / `submit`). Normal-review prompts and safe interruption behavior follow the interaction contract below. To diagnose gaps in the skill after a review session, run `/gh-pr-review diag`.\n---\n\n<!-- Based on https://github.com/Tencent/tgfx/tree/main/.codebuddy/skills/cr -->\n<!-- Adapted for agent runtimes and the Cherry Studio tech stack -->\n\n# /gh-pr-review — Code Review\n\nAutomated code review for local branches, PRs, commits, and files. Detects\nthe review target from arguments, then picks the review engine from diff size\nand runtime capability. Small diffs use single-agent review\n(`references/local-review.md`). Large diffs use the multi-agent\nreviewer–verifier flow (`references/teams-review.md`) only when independent\nsubagents are available; otherwise they fall back to single-agent review with\nthat limitation disclosed. PR targets add worktree setup and GitHub submission\n(`references/pr-review.md`) around the same engine-selection contract.\n\nCherry Studio-specific review rules live in\n`references/cherry-review-guidance.md`. Target review flows must load that file\nfor code, mixed, architecture-doc, and project-skill reviews so reviewers can\napply DataApi, service-boundary, renderer hook, React, UI, and type-contract\nchecks without relying on memory. That reference also defines which internal\ndocs, internal skills, external skills, and official websites to consult for\neach changed area; load only the relevant subset.\n\nAll user-facing text matches the user's language.\n\n## Interaction and interruption contract\n\nApart from the declared categories below, normal review is prompt-free: never\nask for mode selection, fix confirmation, finding selection, or submission\npreview. A leaf flow may request input only when it explicitly declares one of\nthese categories:\n\n- **Product decision** — in an interactive session, the Product Demand gate may\n ask the current user for a decision the review cannot derive. In an automated\n session, record the impact and open decision without deciding for the user.\n- **Safety or environment blocker** — continuing would require destructive\n action, new authority, or missing external configuration. Declared examples\n are a dirty/mismatched review worktree, a missing canonical remote, cleanup\n of unexplained changes, removal of a failed fix patch, and a pending review\n draft holding comments this run did not confirm. In an interactive session,\n preserve state and ask only for the decision needed to proceed.\n- **Explicit maintenance mode** — `diag` and separately requested checklist\n maintenance are interactive selection flows outside normal review. They may\n ask for the declared edit selection or persistent checkout/branch target.\n\nAn automated session never waits for user input. At a product decision it\ncontinues record-only as specified below. At a safety/environment blocker it\npreserves state, stops the affected flow safely, and reports the exact blocker\nand required decision. In an explicit maintenance mode it reports candidates\nor missing destination information, applies no selection-dependent edits, and\nstops safely. No leaf flow may introduce another prompt category.\n\n## Review Stages\n\nEvery review runs these stages in order. A later stage reviews only what\nsurvived the earlier ones, so a stage never re-litigates an earlier verdict.\n\nThis table is the single source of truth for stage scope and references; a\nleaf flow may not widen, narrow, or re-reference a stage.\n\n| # | Stage | Applies to | Reference |\n|---|-------|-----------|-----------|\n| 1 | **Product Demand** (gate) | any change whose semantics affect the product | below |\n| 2 | **Consumer** | any change that adds or expands shared surface | `references/consumer-review.md` |\n| 3 | **Architecture-First** | code, mixed, Cherry architecture docs, project skills | `references/cherry-review-guidance.md` |\n| 4 | **Implementation** | code, mixed | `references/code-checklist.md` (A/B) |\n| 4 | **Implementation** | docs | `references/doc-checklist.md` (A/B) |\n| 5 | **Style / conventions** | code, mixed | `references/code-checklist.md` (C) |\n| 5 | **Style / conventions** | docs | `references/doc-checklist.md` (C) |\n\nStage applicability follows the changed content, not the commit label: a\ndocumentation-only diff still runs stages 3–5 when it changes Cherry\narchitecture docs or project skills, and a code diff that also edits docs runs\nboth reference sets for stages 4–5.\n\n### Stage 1: Product Demand gate\n\nFirst inspect the semantics actually expressed or constrained by the change,\nthen decide whether it affects **product semantics, user-visible behavior, or\nproduct direction**. Change labels are not sufficient evidence: internal\nrefactors and non-user-facing fixes often have no product impact, while\nuser-facing fixes, docs, tests, or tooling can record, lock, or alter product\nbehavior.\n\nWhen there is product impact, determine whether the direction is already\nestablished in the current review context. Treat it as established only when\nthe current user explicitly decided it or an authoritative project artifact\nexplicitly records the accepted behavior and its approval by the responsible\nproject authority, such as a specification, an ADR, or an issue containing a\nmaintainer decision that settles the expected behavior. Do not infer acceptance\nfrom issue state, labels, milestone, assignment, or a link from the PR. A change\nlabel, PR body, implementation, or test demonstrates author intent or current\nbehavior but does not establish product approval on its own.\n\nClassify the gate into exactly one state:\n\n- **No product impact**: skip this stage entirely in both interactive and\n automated runs; say nothing about the skipped gate.\n- **Established direction**: compare the change with the recorded decision. If\n it aligns, continue without asking for another product decision. If it\n conflicts, report the product-direction mismatch and **stop the whole review\n immediately** — do not run Consumer, Architecture, Implementation, or Style\n stages, and do not report code findings. Applying an existing decision is\n not making a new one.\n- **Open product decision**:\n - **Interactive session (default)**: summarize the change's effect on\n product functionality and semantics, and ask the current user for the\n unresolved product decision. Do not infer automation from PR authorship,\n review ownership, or whether the user authored the change. If the user\n rejects the direction, stop the whole review as above; if the user\n approves it, continue with the remaining stages.\n - **Automated session (explicit only)**: use this mode only when the\n invocation prompt or workflow context explicitly identifies a headless,\n CI, batch, or other automated run. Make no product decision on the user's\n behalf. Run the remaining stages, and in the final report summarize the\n product impact, the direction the change takes, and the points needing\n human confirmation. Never phrase this as product approval having been\n obtained.\n\n## Authority model\n\nA review request authorizes analysis and reporting only. The review target,\nreview depth, and reviewer–verifier confidence never grant execution\nauthority; authority is granted explicitly at invocation time, and execution\nis prompt-free only after it has been granted:\n\n- **Report-only (default)**: every review, any target — findings are reported\n with fix guidance. No working-tree edits, no GitHub writes.\n- **Fix (explicit)**: granted only by the invocation — `fix` in `$ARGUMENTS`\n or equivalent explicit user wording (\"review and fix …\"). Local targets\n only. What each risk level then permits is owned by\n `references/judgment-matrix.md` § Handling by Risk Level; this section grants\n the authority and never restates the mapping.\n Applying fixes makes the session a coding task, so it must end with the\n validation selected per § Validation after applied fixes below.\n- **Submit (explicit)**: granted only by the invocation — `submit` in\n `$ARGUMENTS` or equivalent explicit user wording. PR flows then submit all\n confirmed findings without per-comment prompts. Approving or merging always\n requires its own explicit request.\n\n## Validation after applied fixes\n\nNever run local lint, test, or format during a review that edited nothing.\nWhen fixes were applied, select the validation matching the changed surface,\nfollowing `AGENTS.md` § Operational Rules (\"Check what you changed, not the\nwhole repo\"), and report the results:\n\n- Docs/markdown-only fixes — including this skill's own files — run\n `pnpm docs:check`.\n- Code fixes run `pnpm lint` (which already ends with `pnpm format`, so never\n invoke `format` again) plus the tests covering the change: a per-project\n wrapper such as `pnpm test:main <file>` or `pnpm exec vitest run <file>`.\n Never `pnpm test <path>` — that script chains several vitest invocations and\n the path reaches only the last one.\n- Reserve the full `pnpm test` for a broad change whose affected tests cannot\n be named, and use `pnpm test:lint` when the CI-equivalent lint gate matters\n (`pnpm lint` tolerates oxlint warnings that CI denies).\n\n## Route\n\nFirst strip authority modifiers from `$ARGUMENTS` (equivalent explicit user\nwording in the conversation counts the same; both default to `false`). Call\nthe remainder `REVIEW_TARGET` — every rule below, and every leaf flow, reads\n`REVIEW_TARGET`, never the raw `$ARGUMENTS`:\n\n- `fix` → `AUTHORIZED_FIX = true` (meaningful for local targets)\n- `submit` → `AUTHORIZED_SUBMIT = true` (meaningful for PR targets)\n\nBefore choosing a review engine, inspect the runtime's exposed coordination\ncapabilities. Set `HAS_SUBAGENTS = true` only when it can launch an independent\nreviewer and a fresh independent verifier. Parallel execution is not required;\nsequential subagents still satisfy the isolation contract.\n\n### Rules\n\nMatch the **first** applicable rule top-to-bottom:\n\n1. `REVIEW_TARGET` is `diag` → `references/diagnosis.md`.\n2. `REVIEW_TARGET` is `checklist`, or the user explicitly asks to adopt the\n proposed checklist candidates → `references/checklist-evolution.md`,\n entering at its Step 2. Maintenance runs only in the session that produced\n the candidates; it reviews nothing.\n3. `REVIEW_TARGET` is a PR number or URL containing `/pull/` →\n `references/pr-review.md` (pass `AUTHORIZED_SUBMIT` and `HAS_SUBAGENTS`;\n the wrapper collects the exact PR scope before selecting the engine).\n4. Everything else: derive the scope and `SMALL_SCOPE` per § Scope derivation\n below, then select the engine.\n - `SMALL_SCOPE = true` → `references/local-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = true` →\n `references/teams-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = false` →\n `references/local-review.md`; pass `LIMITED_SINGLE_AGENT = true` so the\n report explicitly states that a large diff received single-agent review\n without independent adversarial verification.\n - Pass `AUTHORIZED_FIX` (commit and range targets are immutable history —\n always report-only regardless of the flag).\n\nEach `→` means: `Read` the target file and follow it as the sole remaining\ninstruction for how to obtain diffs, apply fixes, and submit results. Do NOT\nreview from memory or habit. The skill-wide sections — § Review Stages,\n§ Authority model, § Validation after applied fixes, and § Scope derivation —\nstay binding; the leaf flows reference them by name.\n\nNever ask the user anything to route. Pass `REVIEW_TARGET`, the resolved\nscope, `SMALL_SCOPE`, and the authority flags to the target file.\n\n### Scope derivation\n\nReached only from Rule 4 above; `diag` and `checklist` targets never enter this\nsubsection. It is the **sole owner** of how a review scope and its size are\nderived — leaf flows reference it and never restate it.\n\nResolve `REVIEW_TARGET` into the review scope:\n\n| `REVIEW_TARGET` | Scope |\n|---|---|\n| empty, uncommitted changes exist | uncommitted changes only — `git diff HEAD` (staged + unstaged tracked files), plus untracked (`??`) files from `git status --porcelain`, reviewed as new code |\n| empty, clean tree | branch diff against the base: `git merge-base origin/{main\\|master} HEAD`, then `git diff <merge-base-sha>`, plus untracked files |\n| commit hash | validate with `git rev-parse --verify`, then `git show` |\n| commit range (`A..B` / `A...B`) | validate both endpoints, then `git diff A~1..B` |\n| file/directory paths | verify each path exists, then the full contents of the resolved files |\n| PR number or `/pull/` URL | the PR's merge-base diff, collected by `references/pr-review.md` |\n\nThe **resolved review scope**, not a diff, decides whether there is work: for a\npath target it is the set of files resolved from the given paths; for every\nother target it is the diff. A clean tree does not make a path target empty.\nIf the resolved scope is empty, show the usage examples below and exit.\n\nThen measure what the leaf flow will actually read — a diff for diff-shaped\ntargets, full file text for path targets:\n\n- **Diff-shaped targets** (uncommitted changes, branch/merge-base diff, a\n commit, a commit range, a PR): `CHANGED_LINES` is the sum of numeric\n additions and deletions from `git diff --numstat` for the complete review\n scope, and `CHANGED_FILES` is the number of unique changed paths in it.\n- **File/directory path targets**: the leaf flow reviews full contents, so\n measure full contents — `CHANGED_FILES` is the number of files resolved\n from the given paths (directories expand recursively, excluding ignored\n paths), and `CHANGED_LINES` is the total line count of those files. A\n clean tree never makes a path target small by default.\n- **Untracked text files** in a diff-shaped scope count as one file each with\n their full line count as additions.\n- Generated files count normally in both totals; do not exclude them because\n they are generated.\n- Any binary file — a binary diff (`-`/`-` in `--numstat`), an untracked\n binary, or a binary resolved from a path target — counts as a file and makes\n the scope non-small, because its line size is unknown.\n\nSet `SMALL_SCOPE = true` only when `CHANGED_LINES <= 1000`,\n`CHANGED_FILES <= 20`, and the scope contains no binary file. Both numeric\nconditions must hold. `SMALL_SCOPE` is the name every flow uses for this\nresult.\n\n### Usage examples\n\nPrint this list when the resolved scope is empty:\n\n```\n/gh-pr-review review uncommitted changes, else the branch diff\n/gh-pr-review a1b2c3d review a commit\n/gh-pr-review a1b2c3d..e4f5g6h review a commit range\n/gh-pr-review src/foo.ts review files or directories\n/gh-pr-review 123 review a PR (also accepts a /pull/ URL)\n/gh-pr-review <target> fix also apply low-risk fixes (local targets)\n/gh-pr-review <pr> submit also publish the review to GitHub\n/gh-pr-review checklist adopt this session's proposed checklist items\n/gh-pr-review diag diagnose gaps in this skill\n```\n",".agents/skills/prepare-release/SKILL.md":"---\nname: prepare-release\ndescription: Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch. Use when asked to prepare/create a release, bump version, or run `/prepare-release`.\n---\n\n# Prepare Release\n\nAutomate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch → trigger CI/CD.\n\n## Arguments\n\nParse the version intent from the user's message. Accept any of these forms:\n- Bump type keyword: `patch`, `minor`, `major`\n- Exact version: strict `x.y.z` or `x.y.z-<prerelease>` without build metadata (e.g. `1.8.0`, `1.8.0-beta.1`, `1.8.0-rc.1`)\n- Natural language: \"prepare a beta release\", \"bump to 1.8.0-rc.2\", etc.\n\nDefaults to `patch` if no version is specified. Always echo the resolved target version back to the user before proceeding with any file edits.\n\n- `--dry-run`: Preview only, do not create a release branch.\n\n## Workflow\n\n### Step 1: Determine Version\n\n1. For an interactive local run, fetch `origin/main` and all tags, then verify that the checkout is a clean `main` at exactly `origin/main`:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test -z \"$(git status --porcelain)\"\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n ```\n Stop before editing files if any check fails. This prevents a standalone run from creating a release branch from an arbitrary or stale checkout.\n In GitHub Actions, use the workflow's frozen dispatch SHA and leave checkout validation to the workflow. Do not fetch or compare the later `origin/main` head.\n2. Read the current version from `package.json`. Use it for version increments even if that release has since been withdrawn; never reuse the withdrawn version.\n3. Select the latest published, non-draft GitHub Release whose tag is strict `v<semver>` as the release-note baseline. Non-semver preview releases and drafts are never a baseline:\n ```bash\n gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty'\n ```\n Stop if no published baseline exists or its Git tag is missing (`git rev-parse --verify refs/tags/{baseline-tag}`). Compare its version with the current package version using `semver`: if main is behind, stop and require the latest Post Release metadata PR to be merged. If main is ahead, allow preparation using the published baseline for release notes and the package version for version increments. For example, after withdrawing 2.1.1, main at 2.1.1 with a published baseline of 2.1.0 prepares 2.1.2 and includes changes since 2.1.0.\n In GitHub Actions, use the workflow-provided baseline tag and collection base without repeating these checks.\n4. Compute the new version based on the argument:\n - `patch` / `minor` / `major`: bump from the current version.\n - An exact version must match `^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\.[0-9A-Za-z-]+)*)?$` and pass `semver.valid`; build metadata such as `+build.1` is not accepted.\n - In both cases, require the result to be strictly greater than the current version according to semver precedence. Reject equal versions and downgrades.\n\n### Step 2: Collect Commits\n\n1. Determine the release-note collection base from the published baseline selected in Step 1, not from the package version:\n - If the baseline tag is an ancestor of `HEAD`, use the tag.\n - Otherwise, use the latest commit whose full message contains the exact marker `release-metadata-boundary: <baseline-tag>`. This machine marker is added to the Post Release pull request body and survives the required squash merge.\n - For metadata pull requests created before the machine marker existed, accept a subject exactly equal to `chore(release): sync <baseline-tag> metadata` or that subject followed only by GitHub's squash suffix ` (#<PR-number>)`.\n - Stop with an error if the tag is not an ancestor and its metadata sync commit is missing; otherwise already-released hotfixes could be included again.\n2. List all commits since that base:\n ```bash\n git log <collection-base>..HEAD --format=\"%H %s\" --no-merges\n ```\n3. For each commit, get the full body:\n ```bash\n git log <hash> -1 --format=\"%B\"\n ```\n4. Extract the content inside `` ```release-note `` code blocks from each commit body.\n5. Extract the conventional commit type from the title (`feat`, `fix`, `refactor`, `perf`, `docs`, etc.).\n6. **Skip** these commits as standalone release-note candidates, but still inspect their effects when reconciling candidates with the final code in Step 3:\n - Titles starting with `🤖 Daily Auto I18N`\n - Titles starting with `Merge`\n - Titles starting with `chore(deps)`\n - Titles starting with `chore: release`\n - Titles starting with `chore(release)`\n - Commits where the release-note block says `NONE`\n\n### Step 3: Generate Bilingual Release Notes\n\nGenerate release notes in **both English and Chinese** from the final user-visible changes relative to the published baseline. Commit titles and `release-note` blocks are candidate descriptions, not proof that a change will ship.\n\n**Reconcile net changes before drafting:**\n\n1. Inspect `git diff --name-status <baseline-tag> <release-head>`, then read the relevant patches and code at both endpoints. `<release-head>` is the source `HEAD` before release preparation (the frozen dispatch SHA in CI). Compare the two endpoint trees, not a three-dot merge-base diff. The collection base is only for discovering commits; when it differs from the published tag, also inspect user-visible differences missing from that commit range.\n2. Group candidates by user-visible behavior and trace related patches in chronological order, including commits excluded in Step 2. Detect explicit reverts, manual undoing, replacements, partial reversals, and reintroductions from the code; do not rely on commit wording or matching hashes alone.\n3. Omit a change introduced and fully undone during this cycle, including fixes that only addressed that temporary change. For partial reversals, replacements, or reintroductions, describe only the final outcome that differs from the published baseline, once per distinct user-visible change.\n4. If a reversal removes or changes behavior that already existed in the published baseline, describe the resulting user-visible removal or restoration. Do not discard all revert commits indiscriminately. An implementation rewrite that preserves the same user-visible behavior does not by itself justify a release-note entry.\n5. Verify each proposed item against the endpoint diff and final code, and ensure the English and Chinese versions describe the same outcome. If the claimed effect cannot be substantiated, omit it and report the uncertainty in the preparation summary rather than inventing a release-note claim.\n\n**Recommended format:**\n\n```\n<!--LANG:en-->\nCherry Studio {version} - {Brief English Title}\n\n✨ New Features\n- [Component] Description\n\n🐛 Bug Fixes\n- [Component] Description\n\n💄 Improvements\n- [Component] Description\n\n⚡ Performance\n- [Component] Description\n\n<!--LANG:zh-CN-->\nCherry Studio {version} - {简短中文标题}\n\n✨ 新功能\n- [组件] 描述\n\n🐛 问题修复\n- [组件] 描述\n\n💄 改进\n- [组件] 描述\n\n⚡ 性能优化\n- [组件] 描述\n<!--LANG:END-->\n```\n\nThe language markers are the machine-readable contract: include each marker once, keep them in order, and provide non-empty English and Chinese sections. Titles and surrounding explanatory text are presentation choices, not validation requirements.\n\n**Rules:**\n- Only include categories that have entries (omit empty categories).\n- Each distinct surviving user-visible change appears once in the appropriate category; combine related commits and omit canceled or superseded claims.\n- Prefer wording from the `release-note` field, or otherwise the commit title, only when it matches the verified final outcome.\n- Component tags should be short: `[Chat]`, `[Models]`, `[Agent]`, `[MCP]`, `[Settings]`, `[Data]`, `[Build]`, etc.\n- Chinese translations should be natural, not machine-literal.\n- Do NOT include commit hashes or PR numbers.\n- Read the **existing** release notes in `electron-builder.yml` as a style reference before writing.\n\n**IMPORTANT: User-Focused Content Only**\n\nRelease notes are for **end users**, not developers. Exclude anything users don't care about:\n\n- **EXCLUDE** internal refactoring, code cleanup, or architecture changes\n- **EXCLUDE** CI/CD, build tooling, or test infrastructure changes\n- **EXCLUDE** dependency updates (unless they add user-visible features)\n- **EXCLUDE** documentation updates\n- **EXCLUDE** developer experience improvements\n- **EXCLUDE** technical debt fixes with no user-visible impact\n- **EXCLUDE** overly technical descriptions (e.g., \"fix race condition in Redux middleware\")\n\n**INCLUDE** only changes that users will notice:\n- New features they can use\n- Bug fixes that affected their workflow\n- UI/UX improvements they can see\n- Performance improvements they can feel\n- Security fixes (simplified, without implementation details)\n\n**Keep descriptions simple and non-technical:**\n- ❌ \"Fix streaming race condition causing partial tool response status in Redux state\"\n- ✅ \"Fix tool status not stopping when aborting\"\n- ❌ \"Auto-convert reasoning_effort to reasoningEffort for OpenAI-compatible providers\"\n- ✅ \"Fix deep thinking mode not working with some providers\"\n\n### Step 4: Update Files\n\n1. **`package.json`**: Update the `\"version\"` field to the new version.\n2. **`electron-builder.yml`**: Replace the content under `releaseInfo.releaseNotes: |` with the generated notes. Preserve the 4-space YAML indentation for the block scalar content.\n3. **`resources/cherry-studio/release-history.json`**: Never edit by hand; the notes must match `electron-builder.yml` byte for byte. Run `node scripts/release/sync-release-history.js --target-version {version}`, which prepends (or replaces) the entry for a stable release and leaves the file untouched for a prerelease. In GitHub Actions, the workflow runs this itself after the Claude step.\n4. **Validate source metadata**: For an interactive local run, run `node scripts/release/validate-prepared-release.js --target-version {version}` before generating the product manifest, and stop if it rejects the changed paths, version ordering, bilingual sections, or stable history. In GitHub Actions, leave validation to the workflow step that runs after Claude.\n5. **Built-in knowledge**: For an interactive local run, run `pnpm build:builtin-knowledge` after validation. This refreshes `resources/builtin-agents/cherry-assistant/product-manifest.json` with the new package version. Never edit the generated manifest by hand. In GitHub Actions, do not run the generator: the workflow runs the same validator first, then runs the trusted generator itself.\n\n### Step 5: Present for Review\n\nShow the user:\n- The new version number.\n- The full generated release notes.\n- A summary of which files were modified.\n\nIf `--dry-run` was specified, stop here.\n\nOtherwise, ask the user to confirm before proceeding to Step 6.\n\n### Step 6: Create Release Branch\n\n1. For an interactive local run, repeat Step 1 items 1-3 immediately before creating the branch, reading the original package version from `HEAD:package.json`. Require the published baseline to still match the one used to collect release notes; otherwise regenerate the notes before proceeding. Because Step 4 has intentionally prepared and validated release metadata, replace Step 1's clean-worktree assertion with `git status --short` and stop unless every listed path is one of the four allowed release metadata files. Then create and push a signed, DCO-compliant release commit:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n test \"$(node -p \"require('./package.json').version\")\" = \"{version}\"\n CURRENT_VERSION=\"$(git show HEAD:package.json | jq -r .version)\"\n LATEST_PUBLISHED=\"$(gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty')\"\n test \"$LATEST_PUBLISHED\" = \"{baseline-tag}\"\n git rev-parse --verify \"refs/tags/$LATEST_PUBLISHED\"\n node -e \"const semver = require('semver'); process.exit(semver.gte(process.argv[1], process.argv[2]) ? 0 : 1)\" \"$CURRENT_VERSION\" \"${LATEST_PUBLISHED#v}\"\n REPO=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\n gh api --paginate --slurp \"repos/$REPO/releases?per_page=100\" | TAG=\"v{version}\" node scripts/release/validate-release-state.js prepare\n test -z \"$(git ls-remote --heads origin refs/heads/release/v{version})\"\n git status --short\n UNEXPECTED_RELEASE_PATHS=\"$(git status --porcelain | cut -c4- | grep -Ev '^(package\\.json|electron-builder\\.yml|resources/cherry-studio/release-history\\.json|resources/builtin-agents/cherry-assistant/product-manifest\\.json)$' || true)\"\n test -z \"$UNEXPECTED_RELEASE_PATHS\"\n git checkout -b release/v{version}\n git add package.json electron-builder.yml resources/cherry-studio/release-history.json resources/builtin-agents/cherry-assistant/product-manifest.json\n git commit -S --signoff -m \"chore(release): prepare v{version}\"\n git cat-file commit HEAD | grep -q '^gpgsig '\n git log -1 --format=%B | grep -q '^Signed-off-by: '\n git push -u origin release/v{version}\n ```\n2. In GitHub Actions, stop after updating `package.json` and `electron-builder.yml`. Temporary helper files and local Git operations are allowed; the workflow extracts those two file changes, restores the frozen source SHA, and discards everything else. It then derives the release history, validates, generates the product manifest, creates the branch, and uses GitHub's API to create and verify the signed, DCO-compliant commit. Never push from the Claude step.\n3. Report the release branch and next steps. Do not create a PR yet: the release must be built and published from this branch first.\n\n## CI Trigger Chain\n\n- Wait for the **CI** push run on the new `release/v{version}` commit to succeed. **`auto-release-build.yml`** revalidates that exact live branch head and dispatches **`release.yml`** with `all`; it builds macOS, Windows, and Linux and creates or updates the draft GitHub Release. Use **`release.yml`** manually only to retry a failed all-platform build or one platform for the unchanged tagged commit.\n- While a single draft semantic-version release is active, **`backport-release-fixes.yml`** opens a backport PR for the first merged `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` PR from `main`, applies any optional bilingual release note, then appends consecutive hotfixes and source markers to that same open topic branch. It manages every source PR's `hotfix` and backport-status labels and reports failures on the source PR; never merge `main` into the release branch.\n- Review the backport PR, wait for its CI, and merge it. After the resulting release-branch push passes CI, the exact-head all-platform draft rebuild starts automatically.\n- A successful exact-head all-platform build starts **`publish-release.yml`**. Approve the `release` Environment deployment after inspecting the draft. Publication then acquires the release-state lock, revalidates the approved run, release branch, tag, draft, artifacts, open PRs, and pending hotfixes, and publishes only if they still agree. The draft body contains the bilingual `electron-builder.yml` notes followed by GitHub's generated changes. The final fetched `main` SHA is the hotfix cutoff; a hotfix merged after that snapshot belongs to the next release. Publication triggers **`post-release.yml`**, which uses the published tag as its source, applies only the release metadata delta to the latest `main`, and creates a `release-sync/v{version}` metadata-only PR.\n- The metadata PR synchronizes only `package.json`, `electron-builder.yml`, release history, and the generated product manifest. It triggers **`ci.yml`**; merge it only after CI passes.\n- When squash-merging the metadata PR, set the commit title to exactly `chore(release): sync v{version} metadata` with only GitHub's optional PR-number suffix, and keep `release-metadata-boundary: v{version}` on its own line in the squash commit body so the next release can find the boundary reliably.\n\n## Constraints\n\n- Always read `electron-builder.yml` before modifying it to understand the current format.\n- Never retain changes outside `package.json`, `electron-builder.yml`, `resources/cherry-studio/release-history.json`, and the generated `resources/builtin-agents/cherry-assistant/product-manifest.json`.\n- Never push directly to `main`.\n- Never create the release metadata PR before the GitHub Release is published; `post-release.yml` owns that step.\n- Always show the generated release notes to the user before creating the release branch (unless running in CI with no interactive user).\n","resources/builtin-agents/cherry-assistant/.claude/skills/skills-manager/SKILL.md":"---\nname: skills-manager\ndescription: '搜索、安装或创建 Agent Skill；用户说“find a skill”“搜索技能”“帮我做个 skill”或想扩展能力时使用。'\n---\n\n# Skills Manager\n\n## 搜索和安装\n\n**优先复用**: `find-skills` 可用时先调用它完成搜索、质量检查和安装确认；只有不可用时才执行下面的 CLI 降级流程。\n\n**运行时检测**: 优先 `npx skills`，备选 `$CHERRY_STUDIO_BUN_PATH x skills`，都没有则提示安装 Node.js\n\n**搜索**: 理解需求→提取关键词→`npx skills find [query]`→展示名称/功能/来源\n\n**安装**: Skills 是第三方代码有完整权限，必须: 展示安全警告→提供源码链接→用户确认→`npx skills add <owner/repo@skill> -y`。位置: 项目级 `.claude/skills/` 或用户级 `~/.claude/skills/`\n\n**无结果**: 告知→先尝试直接完成→可复用流程再建议创建自定义 Skill\n\n## 创建 Skills\n\n1. 先确认现有 Skill 无法满足需求，并判断这是不是值得复用的流程；一次性任务直接完成，不强行创建 Skill。\n2. 检查可用 Skill 列表。`skill-creator` 可用时必须调用它，并完整遵循其需求澄清、初始化、编辑、验证和迭代流程；不要绕过它直接手写 `SKILL.md`。\n3. 只有 `skill-creator` 确实不可用时，才明确告诉用户正在降级，然后用 `npx skills init <skill-name>` 初始化，保持 `SKILL.md` 精简，并按需加入 `scripts/`、`references/`、`assets/`。\n4. 创建后至少验证 frontmatter、触发描述和一个真实用例；验证失败就修正后重跑。\n\n**参考**: https://skills.sh/ | `npx skills find/add/init`\n","resources/builtin-agents/cherry-assistant/.claude/skills/issue-reporter/SKILL.md":"---\nname: issue-reporter\ndescription: '仅在用户点名 GitHub Issue、Bug Report 或 Feature Request 时使用；未点名 GitHub 的反馈改用 cherry-studio-feedback。'\n---\n\n# Issue Reporter\n\n## 触发边界\n\n只有用户明确要求提交到 GitHub，才能继续本流程。不得从“提交问题”“反馈”“bug”或“功能建议”推断 GitHub；未明确点名 GitHub 时立即转交 `cherry-studio-feedback`，不得运行 `gh auth status`、搜索仓库或发起任何 GitHub 操作。\n\n## 检测 GitHub 登录\n\n每次提交前: `gh auth status 2>&1`。成功→GitHub模式，失败→本地模式。\n\n## GitHub 模式\n\n**Bug Report**: 收集信息(描述/复现步骤/期望/平台/版本) → 查重 `gh search issues \"[关键词]\" --repo CherryHQ/cherry-studio --state open --limit 5` → 读模板 `.github/ISSUE_TEMPLATE/0_bug_report.yml` → 预览给用户 → 确认后 `gh issue create` → 告知链接\n\n**Feature Request**: 确认需求→查重→读模板 `1_feature_request.yml`→预览→确认→提交→记录到 `.cherry-assistant/feature-requests.md`\n\n## 本地模式\n\nBug 存 `.cherry-assistant/bug-reports.md`，Feature 存 `feature-requests.md`：\n```markdown\n### [Bug/Feature]: [标题]\n- **日期**: YYYY-MM-DD | **平台**: OS | **版本**: vX.X.X\n- **描述**: ... | **复现步骤**: 1... 2... | **期望**: ...\n- **状态**: 待提交\n---\n```\n\n存档后引导: GitHub(推荐) https://github.com/CherryHQ/cherry-studio/issues | 论坛 linux.do | 飞书表单 https://mcnnox2fhjfq.feishu.cn/share/base/form/shrcnsjfFkx4gy6wx9LQ70tMaKe\n\n**批量提交**: 有权限时可说「帮我把待提交的都提交了」→读文件→筛待提交→逐个查重预览确认→更新状态为「已提交 #号」\n\n## 注意\n\n- 提交前必须用户确认\n- 脱敏日志中 token/key\n- Redux/IndexedDB schema 变更标记 Blocked: v2\n","resources/builtin-agents/cherry-assistant/.claude/skills/faq-collector/SKILL.md":"---\nname: faq-collector\ndescription: 将成功解决的用户问题收录到 FAQ 知识库。问题解决后自动判断是否收录。也可以在用户说\"收录到 FAQ\"、\"记录这个问题\"、\"add to FAQ\"时手动触发。\n---\n\n# FAQ Collector\n\n**收录标准**: 通用性高、有明确方案、配置/操作类、非直觉问题。不收录: 纯个人环境问题、已有相同条目、未解决问题。\n\n**文件**: `<project_root>/.cherry-assistant/faq.md`（目录不存在则 `mkdir -p .cherry-assistant` 创建）\n\n**条目格式**（追加到末尾）:\n```markdown\n### Q: [通用化问题表述]\n**A:** [简洁方案]\n[分步骤操作]\n- **关键词**: [逗号分隔]\n- **相关文件/Issue**: [路径或#编号]\n- **版本**: vX.X.X | **收录日期**: YYYY-MM-DD\n---\n```\n\n**流程**: 问题解决→判断收录标准→读FAQ查重→无重复则通用化后追加→有相似但更好则更新\n\n**搜索匹配**: 用户提问时先读FAQ关键词匹配→命中直接给答案→未命中走正常诊断\n\n**与 Issue Reporter 协作**: 先收录FAQ(记录方案)→如果是Bug再提Issue→FAQ记关联Issue编号\n","resources/skills/find-skills/SKILL.md":"---\nname: find-skills\ndescription: 'Find and install agent skills when the user asks for a capability that may already exist as a skill.'\nversion: 1.0.0\n---\n\n# Find Skills\n\nThis skill helps you discover and install skills from the open agent skills ecosystem.\n\n## When to Use This Skill\n\nUse this skill when the user:\n\n- Asks \"how do I do X\" where X might be a common task with an existing skill\n- Says \"find a skill for X\" or \"is there a skill for X\"\n- Asks \"can you do X\" where X is a specialized capability\n- Expresses interest in extending agent capabilities\n- Wants to search for tools, templates, or workflows\n- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)\n\n## The skill tools\n\nCherry gives you two built-in tools for skills — use them, and do NOT shell out to\n`npx skills`, `git`, or any package manager:\n\n- **`search_skills(query)`** — search the marketplace by keyword. Returns matches, each with an\n opaque `install_source` value.\n- **`install_skill(install_source)`** — install ONE skill into Cherry's managed\n library and enable it for this agent. Cherry clones the repo, installs just that one skill,\n and registers it in a single deterministic step. Permission handling follows the active Claude\n permission mode (Step 6).\n\n**Browse skills at:** https://skills.sh/\n\n## How to Help Users Find Skills\n\n### Step 1: Understand What They Need\n\nWhen a user asks for help with something, identify:\n\n1. The domain (e.g., React, testing, design, deployment)\n2. The specific task (e.g., writing tests, creating animations, reviewing PRs)\n3. Whether this is a common enough task that a skill likely exists\n\n### Step 2: Check the Leaderboard First\n\nBefore running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.\n\nFor example, top skills for web development include:\n- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each)\n- `anthropics/skills` — Frontend design, document processing (100K+ installs)\n\n### Step 3: Search for Skills\n\nIf the leaderboard doesn't cover the user's need, call the `search_skills` tool:\n\n- User asks \"how do I make my React app faster?\" → `search_skills(\"react performance\")`\n- User asks \"can you help me with PR reviews?\" → `search_skills(\"pr review\")`\n- User asks \"I need to create a changelog\" → `search_skills(\"changelog\")`\n\nEach result includes an opaque `install_source`, source registry, review URL,\ninstall count, and available star count. Pass the exact `install_source` value\nto `install_skill`.\n\n### Step 4: Verify Quality Before Recommending\n\n**Do not recommend a skill based solely on search results.** Always verify:\n\n1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100.\n2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors.\n3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.\n\n### Step 5: Present Options to the User\n\nWhen you find relevant skills, present them to the user with:\n\n1. The skill name and what it does\n2. The install count and source\n3. That you can install it for them into Cherry\n4. A link to learn more at skills.sh\n\nExample response:\n\n```\nI found a skill that might help! The \"react-best-practices\" skill provides\nReact and Next.js performance optimization guidelines from Vercel Engineering.\n(185K installs)\n\nI can install it into Cherry's skill library for you — want me to go ahead?\n\nLearn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices\n```\n\n### Step 6: Install (Uses the Active Permission Mode)\n\n**⚠️ Security:** Skills are third-party code that runs with full agent\npermissions. A malicious skill could read, modify, or delete files on your\nsystem.\n\nBefore installing any skill:\n\n1. **Show a security warning** — tell the user that the skill is third-party\n code and will run with full agent permissions.\n2. **Provide a review link** — the skills.sh page (or source repository) so\n the user can review the skill's SKILL.md and any scripts it contains.\n3. **Require install intent** — call `install_skill` only when the user asked to install the skill\n or accepted a presented option. A search-only request must not mutate the skill library.\n\nOnce the user has expressed install intent, call `install_skill` with the exact `install_source`\nfrom the search result. Do not add another model-level confirmation step: Claude's active permission\nmode is the authority. Default and accept-edits modes may prompt through the SDK; bypass-permissions\nmode runs directly.\n\n- `install_skill(\"claude-plugins:vercel-labs/agent-skills/skills/react-best-practices\")`\n\nDo **not** run `npx skills add`, `git clone`, or any shell command to install — that would\ninstall the whole repo (dozens of skills), scatter symlinks across other tools, and land\noutside Cherry's library. `install_skill` installs **only that one skill** into Cherry's\nmanaged library in one deterministic step. The Claude Agent SDK applies the configured permission\nmode before it runs. Once done it is registered and listed in the app — nothing is left elsewhere.\n\n## Common Skill Categories\n\nWhen searching, consider these common categories:\n\n| Category | Example Queries |\n| --------------- | ---------------------------------------- |\n| Web Development | react, nextjs, typescript, css, tailwind |\n| Testing | testing, jest, playwright, e2e |\n| DevOps | deploy, docker, kubernetes, ci-cd |\n| Documentation | docs, readme, changelog, api-docs |\n| Code Quality | review, lint, refactor, best-practices |\n| Design | ui, ux, design-system, accessibility |\n| Productivity | workflow, automation, git |\n\n## Tips for Effective Searches\n\n1. **Use specific keywords**: \"react testing\" is better than just \"testing\"\n2. **Try alternative terms**: If \"deploy\" doesn't work, try \"deployment\" or \"ci-cd\"\n3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`\n\n## When No Skills Are Found\n\nIf no relevant skills exist:\n\n1. Acknowledge that no existing skill was found\n2. Offer to help with the task directly using your general capabilities\n3. Offer to author a custom skill for the task (the skill-creator skill handles this)\n\nExample:\n\n```\nI searched for skills related to \"xyz\" but didn't find any matches.\nI can still help you with this task directly! Would you like me to proceed?\n\nIf this is something you do often, I can author a custom skill for you — just ask\nme to \"create a skill for <task>\" and I'll write one into Cherry's skills directory.\n```\n","resources/skills/skill-creator/SKILL.md":"---\nname: skill-creator\ndescription: 'Create, edit, evaluate, and optimize skills, including benchmarking and description tuning for better triggering.'\nversion: 1.0.0\n---\n\n## Cherry Studio workflow (READ FIRST — overrides packaging / install steps below)\n\nYou are running inside Cherry Studio. Skills live in a managed registry that Cherry\nkeeps in sync with the filesystem automatically — there is **no** install or register\ntool to call, and you should **ignore** any `package_skill.py` / `.skill` packaging\nsteps mentioned later in this file (they apply to Claude Code / Claude.ai, not here).\n\n**To create a new skill, write it straight into Cherry's managed skills directory:**\n\n1. Resolve the directory once by running `echo \"$CHERRY_STUDIO_SKILLS_DIR\"` in Bash.\n That folder is Cherry's managed skill library.\n2. Create `$CHERRY_STUDIO_SKILLS_DIR/<skill-folder-name>/` and write `SKILL.md` plus any\n supporting files (`scripts/`, `references/`, `assets/`) into it with your normal file\n tools.\n3. That's it. Cherry's skill sync detects the new directory, registers it in the catalog,\n and lists it in the app — no register step. You can re-edit the files in place at any\n time and the changes are picked up on the next sync.\n\nUse a lowercase, hyphenated `<skill-folder-name>` (e.g. `my-cool-skill`). The `name:`\nfield inside your `SKILL.md` frontmatter must match the folder name and use only\nlowercase letters, numbers, and hyphens (e.g. `name: my-cool-skill` with folder\n`my-cool-skill`), per the Agent Skills spec — it is not a free-form display name.\n\nEval / test workspaces (`<skill-name>-workspace/`, `iteration-*/`, etc.) from the\nevaluation loop described below must be created **outside** that skills directory —\ne.g. as a sibling under the user's workspace — so they don't get bundled into the\nskill. The evaluation loop itself still applies; only the packaging and install\nmechanics change.\n\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nAt a high level, the process of creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft of the skill\n- Create a few test prompts and run claude-with-access-to-the-skill on them\n- Help the user evaluate the results both qualitatively and quantitatively\n - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)\n - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics\n- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like \"I want to make a skill for X\". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.\n\nOn the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.\n\nOf course, you should always be flexible and if the user is like \"I don't need to run a bunch of evaluations, just vibe with me\", you can do that instead.\n\nThen after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.\n\nCool? Cool.\n\n## Communicating with the user\n\nThe skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google \"how to install npm\". On the other hand, the bulk of users are probably fairly computer-literate.\n\nSo please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:\n\n- \"evaluation\" and \"benchmark\" are borderline, but OK\n- for \"JSON\" and \"assertion\" you want to see serious cues from the user that they know what those things are before using them without explaining them\n\nIt's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.\n\n---\n\n## Creating a skill\n\n### Capture Intent\n\nStart by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say \"turn this into a skill\"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.\n\n1. What should this skill enable Claude to do?\n2. When should this skill trigger? (what user phrases/contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.\n\n### Interview and Research\n\nProactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.\n\nCheck available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.\n\n### Write the SKILL.md\n\nBased on the user interview, fill in these components:\n\n- **name**: Skill identifier\n- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All \"when to use\" info goes here, not in the body. Note: currently Claude has a tendency to \"undertrigger\" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit \"pushy\". So for instance, instead of \"How to build a simple fast dashboard to display internal Anthropic data.\", you might write \"How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **compatibility**: Required tools, dependencies (optional, rarely needed)\n- **the rest of the skill :)**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled Resources (optional)\n ├── scripts/ - Executable code for deterministic/repetitive tasks\n ├── references/ - Docs loaded into context as needed\n └── assets/ - Files used in output (templates, icons, fonts)\n```\n\n#### Progressive Disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description) - Always in context (~100 words)\n2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)\n3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)\n\nThese word counts are approximate and you can feel free to go longer if needed.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.\n- Reference files clearly from SKILL.md with guidance on when to read them\n- For large reference files (>300 lines), include a table of contents\n\n**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:\n```\ncloud-deploy/\n├── SKILL.md (workflow + selection)\n└── references/\n ├── aws.md\n ├── gcp.md\n └── azure.md\n```\nClaude reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nThis goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a \"roleplay as an XYZ\" are OK though.\n\n#### Writing Patterns\n\nPrefer using the imperative form in instructions.\n\n**Defining output formats** - You can do it like this:\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** - It's useful to include examples. You can format them like this (but if \"Input\" and \"Output\" are in the examples you might want to deviate a little):\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n### Writing Style\n\nTry to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.\n\n### Test Cases\n\nAfter writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.\n\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\n \"id\": 1,\n \"prompt\": \"User's task prompt\",\n \"expected_output\": \"Description of expected result\",\n \"files\": []\n }\n ]\n}\n```\n\nSee `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.\n\nPut results in `<skill-name>-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: <path-to-skill>\n- Task: <eval prompt>\n- Input files: <eval files if any, or \"none\">\n- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/\n- Outputs to save: <what the user cares about — e.g., \"the .docx file\", \"the final CSV\">\n```\n\n**Baseline run** (same prompt, but the baseline depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.\n- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r <skill-path> <workspace>/skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.\n\nWrite an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just \"eval-0\". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.\n\n```json\n{\n \"eval_id\": 0,\n \"eval_name\": \"descriptive-name-here\",\n \"prompt\": \"The user's task prompt\",\n \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.\n\nUpdate the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:\n\n```json\n{\n \"total_tokens\": 84852,\n \"duration_ms\": 23332,\n \"total_duration_seconds\": 23.3\n}\n```\n\nThis is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.\n\n2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:\n ```bash\n python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>\n ```\n This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.\nPut each with_skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the \"Analyzing Benchmark Results\" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n ```bash\n nohup python <skill-creator-path>/eval-viewer/generate_review.py \\\n <workspace>/iteration-N \\\n --skill-name \"my-skill\" \\\n --benchmark <workspace>/iteration-N/benchmark.json \\\n > /dev/null 2>&1 &\n VIEWER_PID=$!\n ```\n For iteration 2+, also pass `--previous-workspace <workspace>/iteration-<N-1>`.\n\n **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks \"Submit All Reviews\". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.\n\nNote: please use generate_review.py to create the viewer; there's no need to write custom HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): collapsed section showing last iteration's output\n- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.\n\nNavigation is via prev/next buttons or arrow keys. When done, they click \"Submit All Reviews\" which saves all feedback to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user tells you they're done, read `feedback.json`:\n\n```json\n{\n \"reviews\": [\n {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n ],\n \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.\n\nKill the viewer server when you're done with it:\n\n```bash\nkill $VIEWER_PID 2>/dev/null\n```\n\n---\n\n## Improving the skill\n\nThis is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.\n\n3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.\n\n4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.\n\nThis task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply your improvements to the skill\n2. Rerun all test cases into a new `iteration-<N+1>/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and tell you they're done\n5. Read the new feedback, improve again, repeat\n\nKeep going until:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n---\n\n## Advanced: Blind comparison\n\nFor situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks \"is the new version actually better?\"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.\n\nThis is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n---\n\n## Description Optimization\n\nThe description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n {\"query\": \"the user prompt\", \"should_trigger\": true},\n {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nFor the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.\n\nFor the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.\n\nThe key thing to avoid: don't make should-not-trigger queries obviously irrelevant. \"Write a fibonacci function\" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.\n\n### Step 2: Review with user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read the template from `assets/eval_review.html`\n2. Replace the placeholders:\n - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)\n - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file (e.g., `/tmp/eval_review_<skill-name>.html`) and open it: `open /tmp/eval_review_<skill-name>.html`\n4. The user can edit queries, toggle should-trigger, add/remove entries, then click \"Export Eval Set\"\n5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)\n\nThis step matters — bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take some time — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run in the background:\n\n```bash\npython -m scripts.run_loop \\\n --eval-set <path-to-trigger-eval.json> \\\n --skill-path <path-to-skill> \\\n --model <model-id-powering-this-session> \\\n --max-iterations 5 \\\n --verbose\n```\n\nUse the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.\n\nWhile it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.\n\nThis handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.\n\n### How skill triggering works\n\nUnderstanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like \"read this PDF\" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.\n\nThis means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like \"read file X\" are poor test cases — they won't trigger skills regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.\n\n---\n\n### Package and Present (only if `present_files` tool is available)\n\nCheck whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:\n\n```bash\npython -m scripts.package_skill <path/to/skill-folder>\n```\n\nAfter packaging, direct the user to the resulting `.skill` file path so they can install it.\n\n---\n\n## Claude.ai-specific instructions\n\nIn Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:\n\n**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.\n\n**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: \"How does this look? Anything you'd change?\"\n\n**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.\n\n**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.\n\n**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.\n\n**Blind comparison**: Requires subagents. Skip it.\n\n**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.\n\n**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).\n- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.\n- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.\n\n---\n\n## Cowork-Specific Instructions\n\nIf you're in Cowork, the main things to know are:\n\n- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)\n- You don't have a browser or display, so when generating the eval viewer, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.\n- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!\n- Feedback works differently: since there's no running server, the viewer's \"Submit All Reviews\" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).\n- Packaging works — `package_skill.py` just needs Python and a filesystem.\n- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.\n- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.\n\n---\n\n## Reference files\n\nThe agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.\n\n- `agents/grader.md` — How to evaluate assertions against outputs\n- `agents/comparator.md` — How to do blind A/B comparison between two outputs\n- `agents/analyzer.md` — How to analyze why one version beat another\n\nThe references/ directory has additional documentation:\n- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.\n\n---\n\nRepeating one more time the core loop here for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill\n- Run claude-with-access-to-the-skill on test prompts\n- With the user, evaluate the outputs:\n - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them\n - Run quantitative evals\n- Repeat until you and the user are satisfied\n- Package the final skill and return it to the user.\n\nPlease add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put \"Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases\" in your TodoList to make sure it happens.\n\nGood luck!\n","resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md":"# cherry-assistant-guide\n\nPath: `resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md)","CLAUDE.md":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/CLAUDE.md)",".claude/skills/.gitignore":"# Claude Directive: .gitignore\n\nPath: `.claude/skills/.gitignore`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/.gitignore)",".claude/skills/README.md":"# Skills Skill\n\nPath: `.claude/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.md)",".claude/skills/README.zh.md":"# Skills Skill\n\nPath: `.claude/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.zh.md)",".agents/skills/README.md":"# Skills Skill\n\nPath: `.agents/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.md)",".agents/skills/README.zh.md":"# Skills Skill\n\nPath: `.agents/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.zh.md)","packages/extension-table-plus/CHANGELOG.md":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG.md)","packages/extension-table-plus/CHANGELOG-OLD.md":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/CHANGELOG-OLD.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG-OLD.md)","packages/extension-table-plus/package.json":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/package.json)","packages/extension-table-plus/README.md":"# extension-table-plus Documentation\n\nPath: `packages/extension-table-plus/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/README.md)","packages/extension-table-plus/tsconfig.json":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/tsconfig.json)","packages/aiCore/CHANGELOG.md":"# AiCore Skill\n\nPath: `packages/aiCore/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/CHANGELOG.md)","packages/aiCore/package.json":"# AiCore Skill\n\nPath: `packages/aiCore/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/package.json)","packages/aiCore/README.md":"# aiCore Documentation\n\nPath: `packages/aiCore/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/README.md)","packages/aiCore/tsconfig.json":"# AiCore Skill\n\nPath: `packages/aiCore/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/tsconfig.json)","packages/ai-sdk-provider/CHANGELOG.md":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/CHANGELOG.md)","packages/ai-sdk-provider/package.json":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/package.json)","packages/ai-sdk-provider/README.md":"# ai-sdk-provider Documentation\n\nPath: `packages/ai-sdk-provider/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/README.md)","packages/ai-sdk-provider/tsconfig.json":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/tsconfig.json)",".agents/skills/vercel-react-best-practices/AGENTS.md":"# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/AGENTS.md)",".agents/skills/vercel-react-best-practices/README.md":"# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/README.md)","docs/en/references/app-upgrade.md":"# References Skill\n\nPath: `docs/en/references/app-upgrade.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/app-upgrade.md)","docs/en/references/feishu-notify.md":"# References Skill\n\nPath: `docs/en/references/feishu-notify.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/feishu-notify.md)","docs/en/references/fuzzy-search.md":"# References Skill\n\nPath: `docs/en/references/fuzzy-search.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/fuzzy-search.md)","docs/zh/references/app-upgrade.md":"# References Skill\n\nPath: `docs/zh/references/app-upgrade.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/app-upgrade.md)","docs/zh/references/code-execution.md":"# References Skill\n\nPath: `docs/zh/references/code-execution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/code-execution.md)","docs/zh/references/database.md":"# References Skill\n\nPath: `docs/zh/references/database.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/database.md)","docs/zh/references/feishu-notify.md":"# References Skill\n\nPath: `docs/zh/references/feishu-notify.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/feishu-notify.md)","docs/zh/references/fuzzy-search.md":"# References Skill\n\nPath: `docs/zh/references/fuzzy-search.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/fuzzy-search.md)","docs/zh/references/lan-transfer-protocol.md":"# References Skill\n\nPath: `docs/zh/references/lan-transfer-protocol.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/lan-transfer-protocol.md)","docs/zh/references/message-system.md":"# References Skill\n\nPath: `docs/zh/references/message-system.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/message-system.md)","docs/zh/references/services.md":"# References Skill\n\nPath: `docs/zh/references/services.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/services.md)",".agents/skills/gh-create-pr/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/gh-create-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-pr/agents/openai.yaml)",".agents/skills/gh-pr-review/references/checklist-evolution.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/checklist-evolution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/checklist-evolution.md)",".agents/skills/gh-pr-review/references/code-checklist.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/code-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/code-checklist.md)",".agents/skills/gh-pr-review/references/diagnosis.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/diagnosis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/diagnosis.md)",".agents/skills/gh-pr-review/references/doc-checklist.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/doc-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/doc-checklist.md)",".agents/skills/gh-pr-review/references/judgment-matrix.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/judgment-matrix.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/judgment-matrix.md)",".agents/skills/gh-pr-review/references/local-review.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/local-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/local-review.md)",".agents/skills/gh-pr-review/references/pr-review.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/pr-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/pr-review.md)",".agents/skills/gh-pr-review/references/teams-review.md":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/teams-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/teams-review.md)",".agents/skills/gh-pr-review/agents/openai.yaml":"# Agents Skill\n\nPath: `.agents/skills/gh-pr-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/agents/openai.yaml)",".agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md)",".agents/skills/vercel-react-best-practices/rules/advanced-init-once.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md)",".agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md)",".agents/skills/vercel-react-best-practices/rules/async-api-routes.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-api-routes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-api-routes.md)",".agents/skills/vercel-react-best-practices/rules/async-defer-await.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-defer-await.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-defer-await.md)",".agents/skills/vercel-react-best-practices/rules/async-dependencies.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-dependencies.md)",".agents/skills/vercel-react-best-practices/rules/async-parallel.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-parallel.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-parallel.md)",".agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md)",".agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md)",".agents/skills/vercel-react-best-practices/rules/bundle-conditional.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md)",".agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md)",".agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md)",".agents/skills/vercel-react-best-practices/rules/bundle-preload.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-preload.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-preload.md)",".agents/skills/vercel-react-best-practices/rules/client-event-listeners.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md)",".agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md)",".agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md)",".agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md)",".agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md)",".agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md)",".agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md)",".agents/skills/vercel-react-best-practices/rules/js-cache-storage.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md)",".agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md)",".agents/skills/vercel-react-best-practices/rules/js-early-exit.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-early-exit.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-early-exit.md)",".agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md)",".agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md)",".agents/skills/vercel-react-best-practices/rules/js-index-maps.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-index-maps.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-index-maps.md)",".agents/skills/vercel-react-best-practices/rules/js-length-check-first.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md)",".agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md)",".agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md)",".agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md)",".agents/skills/vercel-react-best-practices/rules/rendering-activity.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-activity.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-activity.md)",".agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md)",".agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md)",".agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md)",".agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md)",".agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md)",".agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md)",".agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md)",".agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md)",".agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md)",".agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md)",".agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md)",".agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md)",".agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md)",".agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md)",".agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md)",".agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md)",".agents/skills/vercel-react-best-practices/rules/rerender-memo.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-memo.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo.md)",".agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md)",".agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md)",".agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md)",".agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md)",".agents/skills/vercel-react-best-practices/rules/rerender-transitions.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md)",".agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md)",".agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md)",".agents/skills/vercel-react-best-practices/rules/server-auth-actions.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md)",".agents/skills/vercel-react-best-practices/rules/server-cache-lru.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md)",".agents/skills/vercel-react-best-practices/rules/server-cache-react.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-cache-react.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-react.md)",".agents/skills/vercel-react-best-practices/rules/server-dedup-props.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md)",".agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md)",".agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md)",".agents/skills/vercel-react-best-practices/rules/server-serialization.md":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-serialization.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-serialization.md)","docs/en/references/components/code-block-view.md":"# Components Skill\n\nPath: `docs/en/references/components/code-block-view.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/code-block-view.md)","docs/en/references/components/image-preview.md":"# Components Skill\n\nPath: `docs/en/references/components/image-preview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/image-preview.md)","docs/zh/references/cherryclaw/channels.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/channels.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/channels.md)","docs/zh/references/cherryclaw/mcp-claw.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/mcp-claw.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/mcp-claw.md)","docs/zh/references/cherryclaw/overview.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/overview.md)","docs/zh/references/cherryclaw/scheduler.md":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/scheduler.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/scheduler.md)","docs/zh/references/components/code-block-view.md":"# Components Skill\n\nPath: `docs/zh/references/components/code-block-view.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/code-block-view.md)","docs/zh/references/components/image-preview.md":"# Components Skill\n\nPath: `docs/zh/references/components/image-preview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/image-preview.md)","resources/skills/skill-creator/agents/analyzer.md":"# Subagent: analyzer\n\nPath: `resources/skills/skill-creator/agents/analyzer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/analyzer.md)","resources/skills/skill-creator/agents/comparator.md":"# Subagent: comparator\n\nPath: `resources/skills/skill-creator/agents/comparator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/comparator.md)","resources/skills/skill-creator/agents/grader.md":"# Subagent: grader\n\nPath: `resources/skills/skill-creator/agents/grader.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/grader.md)","resources/skills/skill-creator/references/schemas.md":"# References Skill\n\nPath: `resources/skills/skill-creator/references/schemas.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/references/schemas.md)","src/main/services/agents/README.md":"# Subagent: readme\n\nPath: `src/main/services/agents/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/src/main/services/agents/README.md)"},"items":[{"name":"SKILL.md","path":".agents/skills/create-skill/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/create-skill/SKILL.md","title":"create-skill","category":"anthropic-skill","format":"markdown","content":"---\nname: create-skill\ndescription: Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills.\n---\n\n# Create Skill\n\nCreate a new skill in `.agents/skills/<skill-name>/` following the workflow defined in `.agents/skills/README.md`.\n\n## Workflow\n\n### Step 1: Gather Intent\n\nBefore creating anything, ask the user:\n\n1. **Skill name**: What should the skill be called? (lowercase, digits, hyphens only, e.g., `gh-create-pr`, `prepare-release`)\n2. **Description**: What should this skill do? Include specific trigger contexts (e.g., \"Use when user asks to create PRs\")\n3. **Is this a public skill?**: Should it be synced to `.claude/skills/` for shared use? (default: no, private only)\n4. **Test cases** (optional): Does the user want to set up evals for this skill?\n\nIf the user provides partial info (e.g., just a name), proceed with reasonable defaults and ask to confirm.\n\n### Step 2: Read Guidelines\n\nAlways read `.agents/skills/README.md` before creating a new skill to ensure compliance with the current workflow.\n\n### Step 3: Create Skill Structure\n\nCreate the following directory structure:\n\n```\n.agents/skills/<skill-name>/\n└── SKILL.md\n```\n\n**SKILL.md template:**\n\n```markdown\n---\nname: <skill-name>\ndescription: <description>\n---\n\n# <Skill Name>\n\n[Instructions for the skill]\n```\n\n**Frontmatter fields:**\n- `name`: Skill identifier (lowercase, digits, hyphens)\n- `description`: When to trigger (what the skill does + specific contexts)\n\n### Step 4: Sync (if public)\n\nIf the user wants a **public skill**, before validation:\n\n1. Add the skill name to `.agents/skills/public-skills.txt` (one per line, no inline comments)\n2. Run sync:\n ```bash\n pnpm skills:sync\n ```\n\nThis creates a symlink at `.claude/skills/<skill-name>/` pointing to `.agents/skills/<skill-name>/`.\n\n**Note**: `pnpm skills:check` primarily validates public skills (those in `public-skills.txt`) and also verifies related governance files, so you must sync first before validating.\n\n### Step 5: Validate\n\nRun the validation command:\n\n```bash\npnpm skills:check\n```\n\nIf there are issues, fix them and re-run.\n\n### Step 6: Summary\n\nPresent the user with:\n- Created files\n- Validation result\n- Next steps (how to use the skill)\n\n## Naming Rules\n\n- Use lowercase letters, digits, and hyphens only\n- Prefer short, action-oriented names (e.g., `gh-create-pr`)\n\n## Public vs Private Skills\n\n| Type | Location | Sync | Requires |\n|------|----------|------|----------|\n| Private | `.agents/skills/` | No | Just create the folder |\n| Public | Both | Yes | Add to `public-skills.txt` + run `pnpm skills:sync` |\n\n## Commands Reference\n\n```bash\n# Validate skill structure\npnpm skills:check\n\n# Sync public skills to Claude\npnpm skills:sync\n```\n\n## Constraints\n\n- Never create skills outside `.agents/skills/<skill-name>/`\n- Always run `pnpm skills:check` before completing\n- Public skills require both adding to `public-skills.txt` AND running `pnpm skills:sync`\n- If the skill-creator skill is available, you may use it for advanced skill development (evals, iterations), but this skill handles the basic creation workflow.\n","frontmatter":{"name":"create-skill","description":"Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills."},"isInternal":false,"tokens":810,"sizeBytes":3296},{"name":"SKILL.md","path":".agents/skills/gh-create-issue/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-issue/SKILL.md","title":"gh-create-issue","category":"anthropic-skill","format":"markdown","content":"---\nname: gh-create-issue\ndescription: Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.\n---\n\n# GitHub Create Issue\n\nUse this skill when the user requests to create an issue. Must follow the repository's issue template format.\n\n## Workflow\n\n### Step 1: Determine Template Type\n\nAnalyze the user's request to determine the issue type:\n- If the user describes a problem, error, crash, or something not working -> Bug Report\n- If the user requests a new feature, enhancement, or additional support -> Feature Request\n- If the user is asking a question or needs help with something -> Questions & Discussion\n- If the user describes engineering work with no user-facing behavior change (a follow-up deferred from a pull request, technical debt, refactoring, tooling or CI work) -> Engineering Task\n- Otherwise -> Others\n\nEngineering Task is not a GitHub issue form and is not offered to regular users. Only select it when the request clearly describes internal engineering work.\n\n**If unclear**, ask the user which template to use. Do not default to \"Others\" on your own.\n\n#### Eligibility Check (Engineering Task only)\n\nEngineering Task is meant for maintainers and collaborators with write access. This is a request,\nnot an access control — nothing prevents anyone from calling `gh issue create` directly, and this\nskill does not try to. The check below is here so that a contributor without write access learns\nthat early and gets pointed somewhere more useful.\n\nBefore collecting any information, read the authenticated user's permission level:\n\n```bash\nrepo=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\nuser=\"$(gh api user --jq .login)\"\npermission=\"$(gh api \"repos/$repo/collaborators/$user/permission\" --jq .permission 2>/dev/null)\"\ncase \"$permission\" in\n admin | write) echo \"eligible\" ;;\n *) echo \"not eligible\" ;;\nesac\n```\n\nOnly `admin` and `write` are eligible (`maintain` reports as `write`). Always compare the returned\nvalue: on a public repository this endpoint answers `read` for any user, including one who is not a\ncollaborator at all, so a successful call proves nothing on its own. Do not use\n`repos/{owner}/{repo}/collaborators/{user}` here — it answers `204` for `read`- and `triage`-only\ncollaborators, who are not the intended audience for this template.\n\nIf the result is anything else, do not use this template. Explain that it is meant for maintainers\nwith write access, politely ask the contributor to use one of the public templates instead, and\noffer to help them file it there — their report is welcome, just not under this template. Do not\nquietly switch templates while keeping the Engineering Task labels or issue type.\n\n### Step 2: Read the Selected Template\n\n1. Read the corresponding template file from `.github/ISSUE_TEMPLATE/` directory.\n2. Identify required fields (`validations.required: true`), title prefix (`title`), labels (`labels`, if present), and issue type (`type`, if present).\n\nFor Engineering Task, read [references/engineering-task.md](references/engineering-task.md) instead — it lives outside `.github/ISSUE_TEMPLATE/` on purpose and carries its own title prefix, labels, issue type, and body structure.\n\n### Step 3: Collect Information\n\nBased on the selected template, ask the user for required information only. Follow the template's required fields and option constraints (for example, Platform and Priority choices).\n\n### Step 4: Build and Preview Issue Content\n\nCreate a temp file and write the issue content:\n- Use `issue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"`\n- Use the exact title prefix from the selected template.\n- Fill content following the template body structure and section order.\n- Apply labels exactly as defined by the template.\n- Keep all labels when there are multiple labels.\n- If template has no labels, do not add custom labels.\n- Apply the issue type exactly as defined by the template's `type` field.\n\nPreview the temp file content. **Show the file path** (e.g., `/tmp/gh-issue-body-XXXXXX.md`) and ask for confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).\n\n### Step 5: Create Issue\n\nUse `gh issue create` command to create the issue.\n\nUse a unique temp file for the body:\n\n```bash\nissue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"\ncat > \"$issue_body_file\" <<'EOF'\n...issue body built from selected template...\nEOF\n```\n\nCreate the issue using values from the selected template:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\"\n```\n\nIf the selected template includes labels, append one `--label` per label:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --label \"<label_1_from_template>\" --label \"<label_2_from_template>\"\n```\n\nIf the selected template has no labels, do not pass `--label`.\n\nIf the selected template declares a `type`, pass it as well. `--body-file` does not carry the issue type over on its own, so omitting this leaves the issue untyped:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --type \"<type_from_template>\"\n```\n\n`--template` and `--web` resolve against `.github/ISSUE_TEMPLATE/` on the default branch, so neither works for Engineering Task. Build the body locally for it.\n\nFor the other templates you may use `--template` as a starting point (use the exact template name from the repository):\n\n```bash\ngh issue create --template \"<template_name>\"\n```\n\nUse the `--web` flag to open the creation page in browser when complex formatting is needed:\n\n```bash\ngh issue create --web\n```\n\nClean up the temp file after creation:\n\n```bash\nrm -f \"$issue_body_file\"\n```\n\n## Notes\n\n- Must read template files under `.github/ISSUE_TEMPLATE/` (or `references/` for Engineering Task) to ensure following the correct format.\n- Treat template files as the only source of truth. Do not hardcode title prefixes, labels, or issue types in this skill.\n- Title must be clear and concise, avoid vague terms like \"a suggestion\" or \"stuck\".\n- Provide as much detail as possible to help developers understand and resolve the issue.\n- If user doesn't specify a template type, ask them to choose one first.\n","frontmatter":{"name":"gh-create-issue","description":"Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format."},"isInternal":false,"tokens":1421,"sizeBytes":6351},{"name":"openai.yaml","path":".agents/skills/gh-create-pr/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-pr/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/gh-create-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-pr/agents/openai.yaml)","tokens":300,"sizeBytes":210},{"name":"SKILL.md","path":".agents/skills/gh-create-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-pr/SKILL.md","title":"gh-create-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: gh-create-pr\ndescription: Create or update GitHub pull requests using the repository-required workflow and template compliance. Use when asked to create/open/update a PR so the assistant reads `.github/pull_request_template.md`, fills every template section, preserves markdown structure exactly, and marks missing data as N/A or None instead of skipping sections.\n---\n\n# GitHub PR Creation\n\n## Stack tooling\n\nThis repository ships `.agents/skills/gh-stack/SKILL.md` as a public project skill; developers do not install the agent skill separately. Read it before operating on stacked branches or PRs. Agents that consume `.agents/skills/` discover it directly. If a Claude checkout is missing `.claude/skills/gh-stack`, run `pnpm skills:sync` followed by `pnpm skills:check`; do not download a separate global copy.\n\nBefore the first `gh stack` command in a task, verify the GitHub CLI and install the official extension if it is missing:\n\n```bash\ncommand -v gh >/dev/null 2>&1 || {\n echo \"GitHub CLI is required: https://cli.github.com/\" >&2\n exit 1\n}\ngh auth status\nif ! gh stack --help >/dev/null 2>&1; then\n gh extension install github/gh-stack\nfi\ngh stack --help >/dev/null\n```\n\nStop if authentication, installation, or the final verification fails. Do not infer a stack with ad hoc Git commands. For human-authored Cherry PRs, use `gh stack push`, create each compliant PR through this skill from bottom to top, then link the existing PRs with `gh stack link`; `gh stack submit --auto` creates PRs outside the template-compliant body flow and must not bypass this workflow.\n\n## Workflow\n\n1. Read `.github/pull_request_template.md` before drafting the PR body.\n2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content). Resolve the live base and run `pnpm change:scope --base <verified-base-ref>`; do not infer scope from the latest commit alone.\n3. Read `.agents/notes/README.md` and classify the change:\n - Fill `Agent Note` with the repository path, or `N/A — <reason>` for a local/mechanical change.\n - For a Spec PR, fill `Spec PR: This PR` and list every AC.\n - For an implementation layer, link the Spec PR and list only the AC IDs covered by this layer. Verify an `APPROVED` review whose `commit_id` equals the current Spec head; a stale approval does not authorize implementation.\n - For a direct bug fix with durable rationale, link its implemented `bug-fix` note and use `Spec PR: N/A`.\n - Automation-authored PRs (repository workflows and Dependabot) are exempt from these metadata fields. Do not make their bodies imitate a human-authored PR.\n4. For an implementation PR, complete the stack tooling preflight, then run `gh stack view --json`. If it exits 2, follow the `gh-stack` skill's remote-discovery procedure; missing local metadata does not prove the PR is standalone. Inspect every downstack implementation PR and aggregate only ACs backed by actual verification. Keep the note proposed on intermediate layers. If the current PR is the final layer and cumulative evidence covers the complete approved Spec, move the bilingual triplet to `implemented/` and run `pnpm agent-notes:check-transition --base <verified-spec-ref>` before publishing.\n5. Fill `Verification` with commands and scenarios actually run. Never present a planned, pending, skipped, or CI-only check as passed.\n6. Check if the current branch has been pushed to remote. If not, push it first:\n - Default remote is `origin`, but ask the user if they want to use a different remote.\n ```bash\n git push -u <remote> <head-branch>\n ```\n7. Determine the base branch:\n - Inspect the head branch before applying any default. If the head is `release/v<version>`, stop: never open a pull request from a release branch, especially not to `main`. Put an isolated fix on a topic branch and target the release branch, or let Post Release create the metadata sync branch.\n - Before defaulting an arbitrary topic branch to `main`, inspect its merge base and upstream. A product-code fix that started from `release/v<version>` must stop and be recreated from `main` as a hotfix; only a release-only repair or explicit backport recovery topic may target that exact release branch.\n - A `backport/v<version>/pr-<number>` head must target the matching `release/v<version>` base and its body must contain `<!-- release-backport-source-pr: <number> -->` on its own line for the exact source hotfix PR. A `release-sync/v<version>` head must target `main`, use the exact title `chore(release): sync v<version> metadata`, retain the `release-metadata-boundary: v<version>` body marker, and be squash-merged.\n - For official repo(CherryHQ/cherry-studio) as `origin`: default base is `main` from `origin`, but allow the user to explicitly indicate a base branch.\n - `main` is the active development line, including hotfix PRs. Do not target an old maintenance branch unless the user explicitly requests it.\n - Only classify a PR as a release hotfix when the user explicitly says it must be included in the active draft release. Use the title `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` with a lowercase alphanumeric kebab-case scope, exactly one space after the colon, and a non-empty description. The title grammar synchronizes the `hotfix` label automatically. Merging opens a separate backport PR only when exactly one draft semantic-version release has a matching active `release/v<version>` branch; otherwise automation stops without guessing a target.\n - If the hotfix is user-facing, provide one release-note line in each language so automation can update the active draft and stable release history. Put this exact structure inside the template's existing `release-note` fence; do not include bullet prefixes:\n ```text\n <!--LANG:en-->\n [Component] English description.\n <!--LANG:zh-CN-->\n [组件] 中文说明。\n <!--LANG:END-->\n ```\n - If the hotfix has no user-facing release note, keep `NONE` in the template's `release-note` fence. The code is still backported, but release metadata is unchanged. A provided bilingual block must satisfy the exact structure above.\n - For fork repo as `origin`: check available remotes with `git remote -v`, default base may be `upstream/main` or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.\n - Ask the user to confirm the base branch if it's not the default.\n8. Create a temp file and write the PR body using a single Bash heredoc\n (avoids `mktemp` + `Write` tool path-mismatch on Windows):\n ```bash\n pr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\n cat > \"$pr_body_file\" <<'EOF'\n ...filled template body...\n EOF\n ```\n Fill content using the template structure exactly (keep section order,\n headings, checkbox formatting). If not applicable, write `N/A` or `None`.\n9. Inspect the temp file content via Bash `cat \"$pr_body_file\"` (the `Read`\n tool can fail on `/tmp/...` paths on Windows). If the user requests a preview\n or confirmation, show the full body and follow that request; otherwise,\n proceed with the authorized PR creation.\n10. Create the PR, adding `--draft` when the user requests a draft:\n ```bash\n gh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\n ```\n For a release hotfix, use an exact classifier-compatible title so the workflow synchronizes the label and separately validates any provided bilingual note:\n ```bash\n gh pr create --base main --head <head> --title \"hotfix: <description>\" --body-file \"$pr_body_file\"\n ```\n After creation, verify that the classifier added `hotfix`; if it did not, fix the title instead of adding the label manually. Also fix any malformed optional release-note block reported by the workflow.\n11. Clean up the temp file: `rm -f \"$pr_body_file\"`\n12. Report the created PR URL and summarize title/base/head, Agent Note/Spec, AC coverage, actual verification, and any required follow-up.\n\n## Constraints\n\n- Never skip template sections.\n- Never rewrite the template format.\n- Keep content concise and specific to the current change set.\n- PR title and body must be written in English.\n- Never use a `hotfix` title or label for an ordinary bug fix. It opts the PR into an automatic backport PR after merge when one matching draft release is active.\n- A release hotfix may use `NONE` when it has no user-facing release note. Never provide a partial, single-language, or otherwise malformed bilingual note; the backport workflow fails closed on malformed content.\n- Never default a `release/v<version>` head to `main`; a release branch is not a pull request source branch.\n- Never publish an implementation PR as ready when its current Spec head lacks an exact-head Approval. A Spec may remain unmerged and serve as the stack base.\n- Every human-authored PR fills `Agent Note`, `Spec PR`, and `Acceptance criteria`; `N/A` requires a concise reason. Automation-authored PRs (repository workflows and Dependabot) are exempt from this metadata requirement.\n- **Release note & Documentation checkbox** — both are driven by whether the change is **user-facing**. Use the table below:\n\n | Change type | Release note | Docs `[x]` |\n |---|---|---|\n | New user-facing feature / setting / UI | Describe the change | ✅ |\n | Bug fix visible to users | Describe the fix | ✅ if behavior changed |\n | Behavior change / default value change | Describe + `action required` | ✅ |\n | Security fix in a user-facing dependency | Describe the fix | ✅ if usage changed |\n | CI / GitHub Actions changes | `NONE` | ❌ |\n | Internal refactoring (user cannot tell) | `NONE` | ❌ |\n | Dev / build tooling changes | `NONE` | ❌ |\n | Dev-only dependency bump | `NONE` | ❌ |\n | Test-only / code style changes | `NONE` | ❌ |\n\n## Command Pattern\n\n```bash\n# read template\ncat .github/pull_request_template.md\n\n# prepare and inspect the PR body\npr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\ncat > \"$pr_body_file\" <<'EOF'\n...filled template body...\nEOF\ncat \"$pr_body_file\"\n\n# create the authorized PR; add --draft when requested\ngh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\nrm -f \"$pr_body_file\"\n```\n","frontmatter":{"name":"gh-create-pr","description":"Create or update GitHub pull requests using the repository-required workflow and template compliance. Use when asked to create/open/update a PR so the assistant reads `.github/pull_request_template.md`, fills every template section, preserves markdown structure exactly, and marks missing data as N/A or None instead of skipping sections."},"isInternal":false,"tokens":2414,"sizeBytes":10350},{"name":"openai.yaml","path":".agents/skills/gh-pr-review/agents/openai.yaml","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/agents/openai.yaml","title":"Agents Skill","category":"anthropic-skill","format":"yaml","content":"# Agents Skill\n\nPath: `.agents/skills/gh-pr-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/agents/openai.yaml)","tokens":300,"sizeBytes":210},{"name":"checklist-evolution.md","path":".agents/skills/gh-pr-review/references/checklist-evolution.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/checklist-evolution.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/checklist-evolution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/checklist-evolution.md)","tokens":300,"sizeBytes":244},{"name":"code-checklist.md","path":".agents/skills/gh-pr-review/references/code-checklist.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/code-checklist.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/code-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/code-checklist.md)","tokens":300,"sizeBytes":234},{"name":"diagnosis.md","path":".agents/skills/gh-pr-review/references/diagnosis.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/diagnosis.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/diagnosis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/diagnosis.md)","tokens":300,"sizeBytes":224},{"name":"doc-checklist.md","path":".agents/skills/gh-pr-review/references/doc-checklist.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/doc-checklist.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/doc-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/doc-checklist.md)","tokens":300,"sizeBytes":232},{"name":"judgment-matrix.md","path":".agents/skills/gh-pr-review/references/judgment-matrix.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/judgment-matrix.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/judgment-matrix.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/judgment-matrix.md)","tokens":300,"sizeBytes":236},{"name":"local-review.md","path":".agents/skills/gh-pr-review/references/local-review.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/local-review.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/local-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/local-review.md)","tokens":300,"sizeBytes":230},{"name":"pr-review.md","path":".agents/skills/gh-pr-review/references/pr-review.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/pr-review.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/pr-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/pr-review.md)","tokens":300,"sizeBytes":224},{"name":"teams-review.md","path":".agents/skills/gh-pr-review/references/teams-review.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/teams-review.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/teams-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/teams-review.md)","tokens":300,"sizeBytes":230},{"name":"SKILL.md","path":".agents/skills/gh-pr-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/SKILL.md","title":"gh-pr-review","category":"anthropic-skill","format":"markdown","content":"---\nname: gh-pr-review\ndescription: Automated Cherry Studio review for local branches, PRs, commits, files, architecture docs, and repository skills. Use for code or documentation reviews that need project-specific naming, main/renderer/shared placement and dependency rules, IpcApi and DataApi boundaries, lifecycle/service ownership, renderer hooks, React/UI conventions, and tests. Review depth adapts to diff size and runtime subagent capability (single-agent or multi-agent reviewer-verifier). Report-only by default; code fixes and GitHub submission each require explicit invocation-time authorization (`fix` / `submit`). Normal-review prompts and safe interruption behavior follow the interaction contract below. To diagnose gaps in the skill after a review session, run `/gh-pr-review diag`.\n---\n\n<!-- Based on https://github.com/Tencent/tgfx/tree/main/.codebuddy/skills/cr -->\n<!-- Adapted for agent runtimes and the Cherry Studio tech stack -->\n\n# /gh-pr-review — Code Review\n\nAutomated code review for local branches, PRs, commits, and files. Detects\nthe review target from arguments, then picks the review engine from diff size\nand runtime capability. Small diffs use single-agent review\n(`references/local-review.md`). Large diffs use the multi-agent\nreviewer–verifier flow (`references/teams-review.md`) only when independent\nsubagents are available; otherwise they fall back to single-agent review with\nthat limitation disclosed. PR targets add worktree setup and GitHub submission\n(`references/pr-review.md`) around the same engine-selection contract.\n\nCherry Studio-specific review rules live in\n`references/cherry-review-guidance.md`. Target review flows must load that file\nfor code, mixed, architecture-doc, and project-skill reviews so reviewers can\napply DataApi, service-boundary, renderer hook, React, UI, and type-contract\nchecks without relying on memory. That reference also defines which internal\ndocs, internal skills, external skills, and official websites to consult for\neach changed area; load only the relevant subset.\n\nAll user-facing text matches the user's language.\n\n## Interaction and interruption contract\n\nApart from the declared categories below, normal review is prompt-free: never\nask for mode selection, fix confirmation, finding selection, or submission\npreview. A leaf flow may request input only when it explicitly declares one of\nthese categories:\n\n- **Product decision** — in an interactive session, the Product Demand gate may\n ask the current user for a decision the review cannot derive. In an automated\n session, record the impact and open decision without deciding for the user.\n- **Safety or environment blocker** — continuing would require destructive\n action, new authority, or missing external configuration. Declared examples\n are a dirty/mismatched review worktree, a missing canonical remote, cleanup\n of unexplained changes, removal of a failed fix patch, and a pending review\n draft holding comments this run did not confirm. In an interactive session,\n preserve state and ask only for the decision needed to proceed.\n- **Explicit maintenance mode** — `diag` and separately requested checklist\n maintenance are interactive selection flows outside normal review. They may\n ask for the declared edit selection or persistent checkout/branch target.\n\nAn automated session never waits for user input. At a product decision it\ncontinues record-only as specified below. At a safety/environment blocker it\npreserves state, stops the affected flow safely, and reports the exact blocker\nand required decision. In an explicit maintenance mode it reports candidates\nor missing destination information, applies no selection-dependent edits, and\nstops safely. No leaf flow may introduce another prompt category.\n\n## Review Stages\n\nEvery review runs these stages in order. A later stage reviews only what\nsurvived the earlier ones, so a stage never re-litigates an earlier verdict.\n\nThis table is the single source of truth for stage scope and references; a\nleaf flow may not widen, narrow, or re-reference a stage.\n\n| # | Stage | Applies to | Reference |\n|---|-------|-----------|-----------|\n| 1 | **Product Demand** (gate) | any change whose semantics affect the product | below |\n| 2 | **Consumer** | any change that adds or expands shared surface | `references/consumer-review.md` |\n| 3 | **Architecture-First** | code, mixed, Cherry architecture docs, project skills | `references/cherry-review-guidance.md` |\n| 4 | **Implementation** | code, mixed | `references/code-checklist.md` (A/B) |\n| 4 | **Implementation** | docs | `references/doc-checklist.md` (A/B) |\n| 5 | **Style / conventions** | code, mixed | `references/code-checklist.md` (C) |\n| 5 | **Style / conventions** | docs | `references/doc-checklist.md` (C) |\n\nStage applicability follows the changed content, not the commit label: a\ndocumentation-only diff still runs stages 3–5 when it changes Cherry\narchitecture docs or project skills, and a code diff that also edits docs runs\nboth reference sets for stages 4–5.\n\n### Stage 1: Product Demand gate\n\nFirst inspect the semantics actually expressed or constrained by the change,\nthen decide whether it affects **product semantics, user-visible behavior, or\nproduct direction**. Change labels are not sufficient evidence: internal\nrefactors and non-user-facing fixes often have no product impact, while\nuser-facing fixes, docs, tests, or tooling can record, lock, or alter product\nbehavior.\n\nWhen there is product impact, determine whether the direction is already\nestablished in the current review context. Treat it as established only when\nthe current user explicitly decided it or an authoritative project artifact\nexplicitly records the accepted behavior and its approval by the responsible\nproject authority, such as a specification, an ADR, or an issue containing a\nmaintainer decision that settles the expected behavior. Do not infer acceptance\nfrom issue state, labels, milestone, assignment, or a link from the PR. A change\nlabel, PR body, implementation, or test demonstrates author intent or current\nbehavior but does not establish product approval on its own.\n\nClassify the gate into exactly one state:\n\n- **No product impact**: skip this stage entirely in both interactive and\n automated runs; say nothing about the skipped gate.\n- **Established direction**: compare the change with the recorded decision. If\n it aligns, continue without asking for another product decision. If it\n conflicts, report the product-direction mismatch and **stop the whole review\n immediately** — do not run Consumer, Architecture, Implementation, or Style\n stages, and do not report code findings. Applying an existing decision is\n not making a new one.\n- **Open product decision**:\n - **Interactive session (default)**: summarize the change's effect on\n product functionality and semantics, and ask the current user for the\n unresolved product decision. Do not infer automation from PR authorship,\n review ownership, or whether the user authored the change. If the user\n rejects the direction, stop the whole review as above; if the user\n approves it, continue with the remaining stages.\n - **Automated session (explicit only)**: use this mode only when the\n invocation prompt or workflow context explicitly identifies a headless,\n CI, batch, or other automated run. Make no product decision on the user's\n behalf. Run the remaining stages, and in the final report summarize the\n product impact, the direction the change takes, and the points needing\n human confirmation. Never phrase this as product approval having been\n obtained.\n\n## Authority model\n\nA review request authorizes analysis and reporting only. The review target,\nreview depth, and reviewer–verifier confidence never grant execution\nauthority; authority is granted explicitly at invocation time, and execution\nis prompt-free only after it has been granted:\n\n- **Report-only (default)**: every review, any target — findings are reported\n with fix guidance. No working-tree edits, no GitHub writes.\n- **Fix (explicit)**: granted only by the invocation — `fix` in `$ARGUMENTS`\n or equivalent explicit user wording (\"review and fix …\"). Local targets\n only. What each risk level then permits is owned by\n `references/judgment-matrix.md` § Handling by Risk Level; this section grants\n the authority and never restates the mapping.\n Applying fixes makes the session a coding task, so it must end with the\n validation selected per § Validation after applied fixes below.\n- **Submit (explicit)**: granted only by the invocation — `submit` in\n `$ARGUMENTS` or equivalent explicit user wording. PR flows then submit all\n confirmed findings without per-comment prompts. Approving or merging always\n requires its own explicit request.\n\n## Validation after applied fixes\n\nNever run local lint, test, or format during a review that edited nothing.\nWhen fixes were applied, select the validation matching the changed surface,\nfollowing `AGENTS.md` § Operational Rules (\"Check what you changed, not the\nwhole repo\"), and report the results:\n\n- Docs/markdown-only fixes — including this skill's own files — run\n `pnpm docs:check`.\n- Code fixes run `pnpm lint` (which already ends with `pnpm format`, so never\n invoke `format` again) plus the tests covering the change: a per-project\n wrapper such as `pnpm test:main <file>` or `pnpm exec vitest run <file>`.\n Never `pnpm test <path>` — that script chains several vitest invocations and\n the path reaches only the last one.\n- Reserve the full `pnpm test` for a broad change whose affected tests cannot\n be named, and use `pnpm test:lint` when the CI-equivalent lint gate matters\n (`pnpm lint` tolerates oxlint warnings that CI denies).\n\n## Route\n\nFirst strip authority modifiers from `$ARGUMENTS` (equivalent explicit user\nwording in the conversation counts the same; both default to `false`). Call\nthe remainder `REVIEW_TARGET` — every rule below, and every leaf flow, reads\n`REVIEW_TARGET`, never the raw `$ARGUMENTS`:\n\n- `fix` → `AUTHORIZED_FIX = true` (meaningful for local targets)\n- `submit` → `AUTHORIZED_SUBMIT = true` (meaningful for PR targets)\n\nBefore choosing a review engine, inspect the runtime's exposed coordination\ncapabilities. Set `HAS_SUBAGENTS = true` only when it can launch an independent\nreviewer and a fresh independent verifier. Parallel execution is not required;\nsequential subagents still satisfy the isolation contract.\n\n### Rules\n\nMatch the **first** applicable rule top-to-bottom:\n\n1. `REVIEW_TARGET` is `diag` → `references/diagnosis.md`.\n2. `REVIEW_TARGET` is `checklist`, or the user explicitly asks to adopt the\n proposed checklist candidates → `references/checklist-evolution.md`,\n entering at its Step 2. Maintenance runs only in the session that produced\n the candidates; it reviews nothing.\n3. `REVIEW_TARGET` is a PR number or URL containing `/pull/` →\n `references/pr-review.md` (pass `AUTHORIZED_SUBMIT` and `HAS_SUBAGENTS`;\n the wrapper collects the exact PR scope before selecting the engine).\n4. Everything else: derive the scope and `SMALL_SCOPE` per § Scope derivation\n below, then select the engine.\n - `SMALL_SCOPE = true` → `references/local-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = true` →\n `references/teams-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = false` →\n `references/local-review.md`; pass `LIMITED_SINGLE_AGENT = true` so the\n report explicitly states that a large diff received single-agent review\n without independent adversarial verification.\n - Pass `AUTHORIZED_FIX` (commit and range targets are immutable history —\n always report-only regardless of the flag).\n\nEach `→` means: `Read` the target file and follow it as the sole remaining\ninstruction for how to obtain diffs, apply fixes, and submit results. Do NOT\nreview from memory or habit. The skill-wide sections — § Review Stages,\n§ Authority model, § Validation after applied fixes, and § Scope derivation —\nstay binding; the leaf flows reference them by name.\n\nNever ask the user anything to route. Pass `REVIEW_TARGET`, the resolved\nscope, `SMALL_SCOPE`, and the authority flags to the target file.\n\n### Scope derivation\n\nReached only from Rule 4 above; `diag` and `checklist` targets never enter this\nsubsection. It is the **sole owner** of how a review scope and its size are\nderived — leaf flows reference it and never restate it.\n\nResolve `REVIEW_TARGET` into the review scope:\n\n| `REVIEW_TARGET` | Scope |\n|---|---|\n| empty, uncommitted changes exist | uncommitted changes only — `git diff HEAD` (staged + unstaged tracked files), plus untracked (`??`) files from `git status --porcelain`, reviewed as new code |\n| empty, clean tree | branch diff against the base: `git merge-base origin/{main\\|master} HEAD`, then `git diff <merge-base-sha>`, plus untracked files |\n| commit hash | validate with `git rev-parse --verify`, then `git show` |\n| commit range (`A..B` / `A...B`) | validate both endpoints, then `git diff A~1..B` |\n| file/directory paths | verify each path exists, then the full contents of the resolved files |\n| PR number or `/pull/` URL | the PR's merge-base diff, collected by `references/pr-review.md` |\n\nThe **resolved review scope**, not a diff, decides whether there is work: for a\npath target it is the set of files resolved from the given paths; for every\nother target it is the diff. A clean tree does not make a path target empty.\nIf the resolved scope is empty, show the usage examples below and exit.\n\nThen measure what the leaf flow will actually read — a diff for diff-shaped\ntargets, full file text for path targets:\n\n- **Diff-shaped targets** (uncommitted changes, branch/merge-base diff, a\n commit, a commit range, a PR): `CHANGED_LINES` is the sum of numeric\n additions and deletions from `git diff --numstat` for the complete review\n scope, and `CHANGED_FILES` is the number of unique changed paths in it.\n- **File/directory path targets**: the leaf flow reviews full contents, so\n measure full contents — `CHANGED_FILES` is the number of files resolved\n from the given paths (directories expand recursively, excluding ignored\n paths), and `CHANGED_LINES` is the total line count of those files. A\n clean tree never makes a path target small by default.\n- **Untracked text files** in a diff-shaped scope count as one file each with\n their full line count as additions.\n- Generated files count normally in both totals; do not exclude them because\n they are generated.\n- Any binary file — a binary diff (`-`/`-` in `--numstat`), an untracked\n binary, or a binary resolved from a path target — counts as a file and makes\n the scope non-small, because its line size is unknown.\n\nSet `SMALL_SCOPE = true` only when `CHANGED_LINES <= 1000`,\n`CHANGED_FILES <= 20`, and the scope contains no binary file. Both numeric\nconditions must hold. `SMALL_SCOPE` is the name every flow uses for this\nresult.\n\n### Usage examples\n\nPrint this list when the resolved scope is empty:\n\n```\n/gh-pr-review review uncommitted changes, else the branch diff\n/gh-pr-review a1b2c3d review a commit\n/gh-pr-review a1b2c3d..e4f5g6h review a commit range\n/gh-pr-review src/foo.ts review files or directories\n/gh-pr-review 123 review a PR (also accepts a /pull/ URL)\n/gh-pr-review <target> fix also apply low-risk fixes (local targets)\n/gh-pr-review <pr> submit also publish the review to GitHub\n/gh-pr-review checklist adopt this session's proposed checklist items\n/gh-pr-review diag diagnose gaps in this skill\n```\n","frontmatter":{"name":"gh-pr-review","description":"Automated Cherry Studio review for local branches, PRs, commits, files, architecture docs, and repository skills. Use for code or documentation reviews that need project-specific naming, main/renderer/shared placement and dependency rules, IpcApi and DataApi boundaries, lifecycle/service ownership, renderer hooks, React/UI conventions, and tests. Review depth adapts to diff size and runtime subagent capability (single-agent or multi-agent reviewer-verifier). Report-only by default; code fixes and GitHub submission each require explicit invocation-time authorization (`fix` / `submit`). Normal-review prompts and safe interruption behavior follow the interaction contract below. To diagnose gaps in the skill after a review session, run `/gh-pr-review diag`."},"isInternal":false,"tokens":3492,"sizeBytes":15738},{"name":"SKILL.md","path":".agents/skills/prepare-release/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/prepare-release/SKILL.md","title":"prepare-release","category":"anthropic-skill","format":"markdown","content":"---\nname: prepare-release\ndescription: Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch. Use when asked to prepare/create a release, bump version, or run `/prepare-release`.\n---\n\n# Prepare Release\n\nAutomate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch → trigger CI/CD.\n\n## Arguments\n\nParse the version intent from the user's message. Accept any of these forms:\n- Bump type keyword: `patch`, `minor`, `major`\n- Exact version: strict `x.y.z` or `x.y.z-<prerelease>` without build metadata (e.g. `1.8.0`, `1.8.0-beta.1`, `1.8.0-rc.1`)\n- Natural language: \"prepare a beta release\", \"bump to 1.8.0-rc.2\", etc.\n\nDefaults to `patch` if no version is specified. Always echo the resolved target version back to the user before proceeding with any file edits.\n\n- `--dry-run`: Preview only, do not create a release branch.\n\n## Workflow\n\n### Step 1: Determine Version\n\n1. For an interactive local run, fetch `origin/main` and all tags, then verify that the checkout is a clean `main` at exactly `origin/main`:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test -z \"$(git status --porcelain)\"\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n ```\n Stop before editing files if any check fails. This prevents a standalone run from creating a release branch from an arbitrary or stale checkout.\n In GitHub Actions, use the workflow's frozen dispatch SHA and leave checkout validation to the workflow. Do not fetch or compare the later `origin/main` head.\n2. Read the current version from `package.json`. Use it for version increments even if that release has since been withdrawn; never reuse the withdrawn version.\n3. Select the latest published, non-draft GitHub Release whose tag is strict `v<semver>` as the release-note baseline. Non-semver preview releases and drafts are never a baseline:\n ```bash\n gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty'\n ```\n Stop if no published baseline exists or its Git tag is missing (`git rev-parse --verify refs/tags/{baseline-tag}`). Compare its version with the current package version using `semver`: if main is behind, stop and require the latest Post Release metadata PR to be merged. If main is ahead, allow preparation using the published baseline for release notes and the package version for version increments. For example, after withdrawing 2.1.1, main at 2.1.1 with a published baseline of 2.1.0 prepares 2.1.2 and includes changes since 2.1.0.\n In GitHub Actions, use the workflow-provided baseline tag and collection base without repeating these checks.\n4. Compute the new version based on the argument:\n - `patch` / `minor` / `major`: bump from the current version.\n - An exact version must match `^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\.[0-9A-Za-z-]+)*)?$` and pass `semver.valid`; build metadata such as `+build.1` is not accepted.\n - In both cases, require the result to be strictly greater than the current version according to semver precedence. Reject equal versions and downgrades.\n\n### Step 2: Collect Commits\n\n1. Determine the release-note collection base from the published baseline selected in Step 1, not from the package version:\n - If the baseline tag is an ancestor of `HEAD`, use the tag.\n - Otherwise, use the latest commit whose full message contains the exact marker `release-metadata-boundary: <baseline-tag>`. This machine marker is added to the Post Release pull request body and survives the required squash merge.\n - For metadata pull requests created before the machine marker existed, accept a subject exactly equal to `chore(release): sync <baseline-tag> metadata` or that subject followed only by GitHub's squash suffix ` (#<PR-number>)`.\n - Stop with an error if the tag is not an ancestor and its metadata sync commit is missing; otherwise already-released hotfixes could be included again.\n2. List all commits since that base:\n ```bash\n git log <collection-base>..HEAD --format=\"%H %s\" --no-merges\n ```\n3. For each commit, get the full body:\n ```bash\n git log <hash> -1 --format=\"%B\"\n ```\n4. Extract the content inside `` ```release-note `` code blocks from each commit body.\n5. Extract the conventional commit type from the title (`feat`, `fix`, `refactor`, `perf`, `docs`, etc.).\n6. **Skip** these commits as standalone release-note candidates, but still inspect their effects when reconciling candidates with the final code in Step 3:\n - Titles starting with `🤖 Daily Auto I18N`\n - Titles starting with `Merge`\n - Titles starting with `chore(deps)`\n - Titles starting with `chore: release`\n - Titles starting with `chore(release)`\n - Commits where the release-note block says `NONE`\n\n### Step 3: Generate Bilingual Release Notes\n\nGenerate release notes in **both English and Chinese** from the final user-visible changes relative to the published baseline. Commit titles and `release-note` blocks are candidate descriptions, not proof that a change will ship.\n\n**Reconcile net changes before drafting:**\n\n1. Inspect `git diff --name-status <baseline-tag> <release-head>`, then read the relevant patches and code at both endpoints. `<release-head>` is the source `HEAD` before release preparation (the frozen dispatch SHA in CI). Compare the two endpoint trees, not a three-dot merge-base diff. The collection base is only for discovering commits; when it differs from the published tag, also inspect user-visible differences missing from that commit range.\n2. Group candidates by user-visible behavior and trace related patches in chronological order, including commits excluded in Step 2. Detect explicit reverts, manual undoing, replacements, partial reversals, and reintroductions from the code; do not rely on commit wording or matching hashes alone.\n3. Omit a change introduced and fully undone during this cycle, including fixes that only addressed that temporary change. For partial reversals, replacements, or reintroductions, describe only the final outcome that differs from the published baseline, once per distinct user-visible change.\n4. If a reversal removes or changes behavior that already existed in the published baseline, describe the resulting user-visible removal or restoration. Do not discard all revert commits indiscriminately. An implementation rewrite that preserves the same user-visible behavior does not by itself justify a release-note entry.\n5. Verify each proposed item against the endpoint diff and final code, and ensure the English and Chinese versions describe the same outcome. If the claimed effect cannot be substantiated, omit it and report the uncertainty in the preparation summary rather than inventing a release-note claim.\n\n**Recommended format:**\n\n```\n<!--LANG:en-->\nCherry Studio {version} - {Brief English Title}\n\n✨ New Features\n- [Component] Description\n\n🐛 Bug Fixes\n- [Component] Description\n\n💄 Improvements\n- [Component] Description\n\n⚡ Performance\n- [Component] Description\n\n<!--LANG:zh-CN-->\nCherry Studio {version} - {简短中文标题}\n\n✨ 新功能\n- [组件] 描述\n\n🐛 问题修复\n- [组件] 描述\n\n💄 改进\n- [组件] 描述\n\n⚡ 性能优化\n- [组件] 描述\n<!--LANG:END-->\n```\n\nThe language markers are the machine-readable contract: include each marker once, keep them in order, and provide non-empty English and Chinese sections. Titles and surrounding explanatory text are presentation choices, not validation requirements.\n\n**Rules:**\n- Only include categories that have entries (omit empty categories).\n- Each distinct surviving user-visible change appears once in the appropriate category; combine related commits and omit canceled or superseded claims.\n- Prefer wording from the `release-note` field, or otherwise the commit title, only when it matches the verified final outcome.\n- Component tags should be short: `[Chat]`, `[Models]`, `[Agent]`, `[MCP]`, `[Settings]`, `[Data]`, `[Build]`, etc.\n- Chinese translations should be natural, not machine-literal.\n- Do NOT include commit hashes or PR numbers.\n- Read the **existing** release notes in `electron-builder.yml` as a style reference before writing.\n\n**IMPORTANT: User-Focused Content Only**\n\nRelease notes are for **end users**, not developers. Exclude anything users don't care about:\n\n- **EXCLUDE** internal refactoring, code cleanup, or architecture changes\n- **EXCLUDE** CI/CD, build tooling, or test infrastructure changes\n- **EXCLUDE** dependency updates (unless they add user-visible features)\n- **EXCLUDE** documentation updates\n- **EXCLUDE** developer experience improvements\n- **EXCLUDE** technical debt fixes with no user-visible impact\n- **EXCLUDE** overly technical descriptions (e.g., \"fix race condition in Redux middleware\")\n\n**INCLUDE** only changes that users will notice:\n- New features they can use\n- Bug fixes that affected their workflow\n- UI/UX improvements they can see\n- Performance improvements they can feel\n- Security fixes (simplified, without implementation details)\n\n**Keep descriptions simple and non-technical:**\n- ❌ \"Fix streaming race condition causing partial tool response status in Redux state\"\n- ✅ \"Fix tool status not stopping when aborting\"\n- ❌ \"Auto-convert reasoning_effort to reasoningEffort for OpenAI-compatible providers\"\n- ✅ \"Fix deep thinking mode not working with some providers\"\n\n### Step 4: Update Files\n\n1. **`package.json`**: Update the `\"version\"` field to the new version.\n2. **`electron-builder.yml`**: Replace the content under `releaseInfo.releaseNotes: |` with the generated notes. Preserve the 4-space YAML indentation for the block scalar content.\n3. **`resources/cherry-studio/release-history.json`**: Never edit by hand; the notes must match `electron-builder.yml` byte for byte. Run `node scripts/release/sync-release-history.js --target-version {version}`, which prepends (or replaces) the entry for a stable release and leaves the file untouched for a prerelease. In GitHub Actions, the workflow runs this itself after the Claude step.\n4. **Validate source metadata**: For an interactive local run, run `node scripts/release/validate-prepared-release.js --target-version {version}` before generating the product manifest, and stop if it rejects the changed paths, version ordering, bilingual sections, or stable history. In GitHub Actions, leave validation to the workflow step that runs after Claude.\n5. **Built-in knowledge**: For an interactive local run, run `pnpm build:builtin-knowledge` after validation. This refreshes `resources/builtin-agents/cherry-assistant/product-manifest.json` with the new package version. Never edit the generated manifest by hand. In GitHub Actions, do not run the generator: the workflow runs the same validator first, then runs the trusted generator itself.\n\n### Step 5: Present for Review\n\nShow the user:\n- The new version number.\n- The full generated release notes.\n- A summary of which files were modified.\n\nIf `--dry-run` was specified, stop here.\n\nOtherwise, ask the user to confirm before proceeding to Step 6.\n\n### Step 6: Create Release Branch\n\n1. For an interactive local run, repeat Step 1 items 1-3 immediately before creating the branch, reading the original package version from `HEAD:package.json`. Require the published baseline to still match the one used to collect release notes; otherwise regenerate the notes before proceeding. Because Step 4 has intentionally prepared and validated release metadata, replace Step 1's clean-worktree assertion with `git status --short` and stop unless every listed path is one of the four allowed release metadata files. Then create and push a signed, DCO-compliant release commit:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n test \"$(node -p \"require('./package.json').version\")\" = \"{version}\"\n CURRENT_VERSION=\"$(git show HEAD:package.json | jq -r .version)\"\n LATEST_PUBLISHED=\"$(gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty')\"\n test \"$LATEST_PUBLISHED\" = \"{baseline-tag}\"\n git rev-parse --verify \"refs/tags/$LATEST_PUBLISHED\"\n node -e \"const semver = require('semver'); process.exit(semver.gte(process.argv[1], process.argv[2]) ? 0 : 1)\" \"$CURRENT_VERSION\" \"${LATEST_PUBLISHED#v}\"\n REPO=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\n gh api --paginate --slurp \"repos/$REPO/releases?per_page=100\" | TAG=\"v{version}\" node scripts/release/validate-release-state.js prepare\n test -z \"$(git ls-remote --heads origin refs/heads/release/v{version})\"\n git status --short\n UNEXPECTED_RELEASE_PATHS=\"$(git status --porcelain | cut -c4- | grep -Ev '^(package\\.json|electron-builder\\.yml|resources/cherry-studio/release-history\\.json|resources/builtin-agents/cherry-assistant/product-manifest\\.json)$' || true)\"\n test -z \"$UNEXPECTED_RELEASE_PATHS\"\n git checkout -b release/v{version}\n git add package.json electron-builder.yml resources/cherry-studio/release-history.json resources/builtin-agents/cherry-assistant/product-manifest.json\n git commit -S --signoff -m \"chore(release): prepare v{version}\"\n git cat-file commit HEAD | grep -q '^gpgsig '\n git log -1 --format=%B | grep -q '^Signed-off-by: '\n git push -u origin release/v{version}\n ```\n2. In GitHub Actions, stop after updating `package.json` and `electron-builder.yml`. Temporary helper files and local Git operations are allowed; the workflow extracts those two file changes, restores the frozen source SHA, and discards everything else. It then derives the release history, validates, generates the product manifest, creates the branch, and uses GitHub's API to create and verify the signed, DCO-compliant commit. Never push from the Claude step.\n3. Report the release branch and next steps. Do not create a PR yet: the release must be built and published from this branch first.\n\n## CI Trigger Chain\n\n- Wait for the **CI** push run on the new `release/v{version}` commit to succeed. **`auto-release-build.yml`** revalidates that exact live branch head and dispatches **`release.yml`** with `all`; it builds macOS, Windows, and Linux and creates or updates the draft GitHub Release. Use **`release.yml`** manually only to retry a failed all-platform build or one platform for the unchanged tagged commit.\n- While a single draft semantic-version release is active, **`backport-release-fixes.yml`** opens a backport PR for the first merged `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` PR from `main`, applies any optional bilingual release note, then appends consecutive hotfixes and source markers to that same open topic branch. It manages every source PR's `hotfix` and backport-status labels and reports failures on the source PR; never merge `main` into the release branch.\n- Review the backport PR, wait for its CI, and merge it. After the resulting release-branch push passes CI, the exact-head all-platform draft rebuild starts automatically.\n- A successful exact-head all-platform build starts **`publish-release.yml`**. Approve the `release` Environment deployment after inspecting the draft. Publication then acquires the release-state lock, revalidates the approved run, release branch, tag, draft, artifacts, open PRs, and pending hotfixes, and publishes only if they still agree. The draft body contains the bilingual `electron-builder.yml` notes followed by GitHub's generated changes. The final fetched `main` SHA is the hotfix cutoff; a hotfix merged after that snapshot belongs to the next release. Publication triggers **`post-release.yml`**, which uses the published tag as its source, applies only the release metadata delta to the latest `main`, and creates a `release-sync/v{version}` metadata-only PR.\n- The metadata PR synchronizes only `package.json`, `electron-builder.yml`, release history, and the generated product manifest. It triggers **`ci.yml`**; merge it only after CI passes.\n- When squash-merging the metadata PR, set the commit title to exactly `chore(release): sync v{version} metadata` with only GitHub's optional PR-number suffix, and keep `release-metadata-boundary: v{version}` on its own line in the squash commit body so the next release can find the boundary reliably.\n\n## Constraints\n\n- Always read `electron-builder.yml` before modifying it to understand the current format.\n- Never retain changes outside `package.json`, `electron-builder.yml`, `resources/cherry-studio/release-history.json`, and the generated `resources/builtin-agents/cherry-assistant/product-manifest.json`.\n- Never push directly to `main`.\n- Never create the release metadata PR before the GitHub Release is published; `post-release.yml` owns that step.\n- Always show the generated release notes to the user before creating the release branch (unless running in CI with no interactive user).\n","frontmatter":{"name":"prepare-release","description":"Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch. Use when asked to prepare/create a release, bump version, or run `/prepare-release`."},"isInternal":false,"tokens":4065,"sizeBytes":17483},{"name":"README.md","path":".agents/skills/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `.agents/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.md)","tokens":300,"sizeBytes":166},{"name":"README.zh.md","path":".agents/skills/README.zh.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.zh.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `.agents/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.zh.md)","tokens":300,"sizeBytes":172},{"name":"AGENTS.md","path":".agents/skills/vercel-react-best-practices/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/AGENTS.md","title":"Vercel-react-best-practices Skill","category":"anthropic-skill","format":"markdown","content":"# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/AGENTS.md)","tokens":300,"sizeBytes":243},{"name":"README.md","path":".agents/skills/vercel-react-best-practices/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/README.md","title":"Vercel-react-best-practices Skill","category":"anthropic-skill","format":"markdown","content":"# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/README.md)","tokens":300,"sizeBytes":243},{"name":"advanced-event-handler-refs.md","path":".agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md)","tokens":300,"sizeBytes":275},{"name":"advanced-init-once.md","path":".agents/skills/vercel-react-best-practices/rules/advanced-init-once.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md)","tokens":300,"sizeBytes":257},{"name":"advanced-use-latest.md","path":".agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md)","tokens":300,"sizeBytes":259},{"name":"async-api-routes.md","path":".agents/skills/vercel-react-best-practices/rules/async-api-routes.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-api-routes.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-api-routes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-api-routes.md)","tokens":300,"sizeBytes":253},{"name":"async-defer-await.md","path":".agents/skills/vercel-react-best-practices/rules/async-defer-await.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-defer-await.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-defer-await.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-defer-await.md)","tokens":300,"sizeBytes":255},{"name":"async-dependencies.md","path":".agents/skills/vercel-react-best-practices/rules/async-dependencies.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-dependencies.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-dependencies.md)","tokens":300,"sizeBytes":257},{"name":"async-parallel.md","path":".agents/skills/vercel-react-best-practices/rules/async-parallel.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-parallel.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-parallel.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-parallel.md)","tokens":300,"sizeBytes":249},{"name":"async-suspense-boundaries.md","path":".agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md)","tokens":300,"sizeBytes":271},{"name":"bundle-barrel-imports.md","path":".agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md)","tokens":300,"sizeBytes":263},{"name":"bundle-conditional.md","path":".agents/skills/vercel-react-best-practices/rules/bundle-conditional.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md)","tokens":300,"sizeBytes":257},{"name":"bundle-defer-third-party.md","path":".agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md)","tokens":300,"sizeBytes":269},{"name":"bundle-dynamic-imports.md","path":".agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-dynamic-imports.md)","tokens":300,"sizeBytes":265},{"name":"bundle-preload.md","path":".agents/skills/vercel-react-best-practices/rules/bundle-preload.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-preload.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-preload.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-preload.md)","tokens":300,"sizeBytes":249},{"name":"client-event-listeners.md","path":".agents/skills/vercel-react-best-practices/rules/client-event-listeners.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-event-listeners.md)","tokens":300,"sizeBytes":265},{"name":"client-localstorage-schema.md","path":".agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-localstorage-schema.md)","tokens":300,"sizeBytes":273},{"name":"client-passive-event-listeners.md","path":".agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-passive-event-listeners.md)","tokens":300,"sizeBytes":281},{"name":"client-swr-dedup.md","path":".agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/client-swr-dedup.md)","tokens":300,"sizeBytes":253},{"name":"js-batch-dom-css.md","path":".agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-batch-dom-css.md)","tokens":300,"sizeBytes":253},{"name":"js-cache-function-results.md","path":".agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-function-results.md)","tokens":300,"sizeBytes":271},{"name":"js-cache-property-access.md","path":".agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-property-access.md)","tokens":300,"sizeBytes":269},{"name":"js-cache-storage.md","path":".agents/skills/vercel-react-best-practices/rules/js-cache-storage.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-cache-storage.md)","tokens":300,"sizeBytes":253},{"name":"js-combine-iterations.md","path":".agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-combine-iterations.md)","tokens":300,"sizeBytes":263},{"name":"js-early-exit.md","path":".agents/skills/vercel-react-best-practices/rules/js-early-exit.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-early-exit.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-early-exit.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-early-exit.md)","tokens":300,"sizeBytes":247},{"name":"js-flatmap-filter.md","path":".agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-flatmap-filter.md)","tokens":300,"sizeBytes":255},{"name":"js-hoist-regexp.md","path":".agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-hoist-regexp.md)","tokens":300,"sizeBytes":251},{"name":"js-index-maps.md","path":".agents/skills/vercel-react-best-practices/rules/js-index-maps.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-index-maps.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-index-maps.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-index-maps.md)","tokens":300,"sizeBytes":247},{"name":"js-length-check-first.md","path":".agents/skills/vercel-react-best-practices/rules/js-length-check-first.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-length-check-first.md)","tokens":300,"sizeBytes":263},{"name":"js-min-max-loop.md","path":".agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-min-max-loop.md)","tokens":300,"sizeBytes":251},{"name":"js-set-map-lookups.md","path":".agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-set-map-lookups.md)","tokens":300,"sizeBytes":257},{"name":"js-tosorted-immutable.md","path":".agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/js-tosorted-immutable.md)","tokens":300,"sizeBytes":263},{"name":"rendering-activity.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-activity.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-activity.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-activity.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-activity.md)","tokens":300,"sizeBytes":257},{"name":"rendering-animate-svg-wrapper.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-animate-svg-wrapper.md)","tokens":300,"sizeBytes":279},{"name":"rendering-conditional-render.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-conditional-render.md)","tokens":300,"sizeBytes":277},{"name":"rendering-content-visibility.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-content-visibility.md)","tokens":300,"sizeBytes":277},{"name":"rendering-hoist-jsx.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hoist-jsx.md)","tokens":300,"sizeBytes":259},{"name":"rendering-hydration-no-flicker.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-no-flicker.md)","tokens":300,"sizeBytes":281},{"name":"rendering-hydration-suppress-warning.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-hydration-suppress-warning.md)","tokens":300,"sizeBytes":293},{"name":"rendering-resource-hints.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-resource-hints.md)","tokens":300,"sizeBytes":269},{"name":"rendering-script-defer-async.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-script-defer-async.md)","tokens":300,"sizeBytes":277},{"name":"rendering-svg-precision.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-svg-precision.md)","tokens":300,"sizeBytes":267},{"name":"rendering-usetransition-loading.md","path":".agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rendering-usetransition-loading.md)","tokens":300,"sizeBytes":283},{"name":"rerender-defer-reads.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-defer-reads.md)","tokens":300,"sizeBytes":261},{"name":"rerender-dependencies.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-dependencies.md)","tokens":300,"sizeBytes":263},{"name":"rerender-derived-state-no-effect.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state-no-effect.md)","tokens":300,"sizeBytes":285},{"name":"rerender-derived-state.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-derived-state.md)","tokens":300,"sizeBytes":265},{"name":"rerender-functional-setstate.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-functional-setstate.md)","tokens":300,"sizeBytes":277},{"name":"rerender-lazy-state-init.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md)","tokens":300,"sizeBytes":269},{"name":"rerender-memo-with-default-value.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo-with-default-value.md)","tokens":300,"sizeBytes":285},{"name":"rerender-memo.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-memo.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-memo.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-memo.md)","tokens":300,"sizeBytes":247},{"name":"rerender-move-effect-to-event.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-move-effect-to-event.md)","tokens":300,"sizeBytes":279},{"name":"rerender-no-inline-components.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-no-inline-components.md)","tokens":300,"sizeBytes":279},{"name":"rerender-simple-expression-in-memo.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-simple-expression-in-memo.md)","tokens":300,"sizeBytes":289},{"name":"rerender-transitions.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-transitions.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-transitions.md)","tokens":300,"sizeBytes":261},{"name":"rerender-use-ref-transient-values.md","path":".agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/rerender-use-ref-transient-values.md)","tokens":300,"sizeBytes":287},{"name":"server-after-nonblocking.md","path":".agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-after-nonblocking.md)","tokens":300,"sizeBytes":269},{"name":"server-auth-actions.md","path":".agents/skills/vercel-react-best-practices/rules/server-auth-actions.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-auth-actions.md)","tokens":300,"sizeBytes":259},{"name":"server-cache-lru.md","path":".agents/skills/vercel-react-best-practices/rules/server-cache-lru.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-lru.md)","tokens":300,"sizeBytes":253},{"name":"server-cache-react.md","path":".agents/skills/vercel-react-best-practices/rules/server-cache-react.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-react.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-cache-react.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-cache-react.md)","tokens":300,"sizeBytes":257},{"name":"server-dedup-props.md","path":".agents/skills/vercel-react-best-practices/rules/server-dedup-props.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-dedup-props.md)","tokens":300,"sizeBytes":257},{"name":"server-hoist-static-io.md","path":".agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-hoist-static-io.md)","tokens":300,"sizeBytes":265},{"name":"server-parallel-fetching.md","path":".agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-parallel-fetching.md)","tokens":300,"sizeBytes":269},{"name":"server-serialization.md","path":".agents/skills/vercel-react-best-practices/rules/server-serialization.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-serialization.md","title":"Rules Skill","category":"anthropic-skill","format":"markdown","content":"# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/server-serialization.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/server-serialization.md)","tokens":300,"sizeBytes":261},{"name":"SKILL.md","path":".agents/skills/vercel-react-best-practices/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/SKILL.md","title":"vercel-react-best-practices","category":"anthropic-skill","format":"markdown","content":"---\nname: vercel-react-best-practices\ndescription: React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.\nlicense: MIT\nmetadata:\n author: vercel\n version: \"1.0.0\"\n---\n\n# Vercel React Best Practices\n\nComprehensive performance optimization guide for React and Next.js applications, maintained by Vercel. Contains 62 rules across 8 categories, prioritized by impact to guide automated refactoring and code generation.\n\n## When to Apply\n\nReference these guidelines when:\n- Writing new React components or Next.js pages\n- Implementing data fetching (client or server-side)\n- Reviewing code for performance issues\n- Refactoring existing React/Next.js code\n- Optimizing bundle size or load times\n\n## Rule Categories by Priority\n\n| Priority | Category | Impact | Prefix |\n|----------|----------|--------|--------|\n| 1 | Eliminating Waterfalls | CRITICAL | `async-` |\n| 2 | Bundle Size Optimization | CRITICAL | `bundle-` |\n| 3 | Server-Side Performance | HIGH | `server-` |\n| 4 | Client-Side Data Fetching | MEDIUM-HIGH | `client-` |\n| 5 | Re-render Optimization | MEDIUM | `rerender-` |\n| 6 | Rendering Performance | MEDIUM | `rendering-` |\n| 7 | JavaScript Performance | LOW-MEDIUM | `js-` |\n| 8 | Advanced Patterns | LOW | `advanced-` |\n\n## Quick Reference\n\n### 1. Eliminating Waterfalls (CRITICAL)\n\n- `async-defer-await` - Move await into branches where actually used\n- `async-parallel` - Use Promise.all() for independent operations\n- `async-dependencies` - Use better-all for partial dependencies\n- `async-api-routes` - Start promises early, await late in API routes\n- `async-suspense-boundaries` - Use Suspense to stream content\n\n### 2. Bundle Size Optimization (CRITICAL)\n\n- `bundle-barrel-imports` - Import directly, avoid barrel files\n- `bundle-dynamic-imports` - Use next/dynamic for heavy components\n- `bundle-defer-third-party` - Load analytics/logging after hydration\n- `bundle-conditional` - Load modules only when feature is activated\n- `bundle-preload` - Preload on hover/focus for perceived speed\n\n### 3. Server-Side Performance (HIGH)\n\n- `server-auth-actions` - Authenticate server actions like API routes\n- `server-cache-react` - Use React.cache() for per-request deduplication\n- `server-cache-lru` - Use LRU cache for cross-request caching\n- `server-dedup-props` - Avoid duplicate serialization in RSC props\n- `server-hoist-static-io` - Hoist static I/O (fonts, logos) to module level\n- `server-serialization` - Minimize data passed to client components\n- `server-parallel-fetching` - Restructure components to parallelize fetches\n- `server-after-nonblocking` - Use after() for non-blocking operations\n\n### 4. Client-Side Data Fetching (MEDIUM-HIGH)\n\n- `client-swr-dedup` - Use SWR for automatic request deduplication\n- `client-event-listeners` - Deduplicate global event listeners\n- `client-passive-event-listeners` - Use passive listeners for scroll\n- `client-localstorage-schema` - Version and minimize localStorage data\n\n### 5. Re-render Optimization (MEDIUM)\n\n- `rerender-defer-reads` - Don't subscribe to state only used in callbacks\n- `rerender-memo` - Extract expensive work into memoized components\n- `rerender-memo-with-default-value` - Hoist default non-primitive props\n- `rerender-dependencies` - Use primitive dependencies in effects\n- `rerender-derived-state` - Subscribe to derived booleans, not raw values\n- `rerender-derived-state-no-effect` - Derive state during render, not effects\n- `rerender-functional-setstate` - Use functional setState for stable callbacks\n- `rerender-lazy-state-init` - Pass function to useState for expensive values\n- `rerender-simple-expression-in-memo` - Avoid memo for simple primitives\n- `rerender-move-effect-to-event` - Put interaction logic in event handlers\n- `rerender-transitions` - Use startTransition for non-urgent updates\n- `rerender-use-ref-transient-values` - Use refs for transient frequent values\n- `rerender-no-inline-components` - Don't define components inside components\n\n### 6. Rendering Performance (MEDIUM)\n\n- `rendering-animate-svg-wrapper` - Animate div wrapper, not SVG element\n- `rendering-content-visibility` - Use content-visibility for long lists\n- `rendering-hoist-jsx` - Extract static JSX outside components\n- `rendering-svg-precision` - Reduce SVG coordinate precision\n- `rendering-hydration-no-flicker` - Use inline script for client-only data\n- `rendering-hydration-suppress-warning` - Suppress expected mismatches\n- `rendering-activity` - Use Activity component for show/hide\n- `rendering-conditional-render` - Use ternary, not && for conditionals\n- `rendering-usetransition-loading` - Prefer useTransition for loading state\n- `rendering-resource-hints` - Use React DOM resource hints for preloading\n- `rendering-script-defer-async` - Use defer or async on script tags\n\n### 7. JavaScript Performance (LOW-MEDIUM)\n\n- `js-batch-dom-css` - Group CSS changes via classes or cssText\n- `js-index-maps` - Build Map for repeated lookups\n- `js-cache-property-access` - Cache object properties in loops\n- `js-cache-function-results` - Cache function results in module-level Map\n- `js-cache-storage` - Cache localStorage/sessionStorage reads\n- `js-combine-iterations` - Combine multiple filter/map into one loop\n- `js-length-check-first` - Check array length before expensive comparison\n- `js-early-exit` - Return early from functions\n- `js-hoist-regexp` - Hoist RegExp creation outside loops\n- `js-min-max-loop` - Use loop for min/max instead of sort\n- `js-set-map-lookups` - Use Set/Map for O(1) lookups\n- `js-tosorted-immutable` - Use toSorted() for immutability\n- `js-flatmap-filter` - Use flatMap to map and filter in one pass\n\n### 8. Advanced Patterns (LOW)\n\n- `advanced-event-handler-refs` - Store event handlers in refs\n- `advanced-init-once` - Initialize app once per app load\n- `advanced-use-latest` - useLatest for stable callback refs\n\n## How to Use\n\nRead individual rule files for detailed explanations and code examples:\n\n```\nrules/async-parallel.md\nrules/bundle-barrel-imports.md\n```\n\nEach rule file contains:\n- Brief explanation of why it matters\n- Incorrect code example with explanation\n- Correct code example with explanation\n- Additional context and references\n\n## Full Compiled Document\n\nFor the complete guide with all rules expanded: `AGENTS.md`\n","frontmatter":{"name":"vercel-react-best-practices","description":"React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","license":"MIT","metadata":{"author":"vercel","version":"1.0.0"}},"isInternal":false,"tokens":1584,"sizeBytes":6530},{"name":"README.md","path":".claude/skills/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `.claude/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.md)","tokens":300,"sizeBytes":166},{"name":"README.zh.md","path":".claude/skills/README.zh.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.zh.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `.claude/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/README.zh.md)","tokens":300,"sizeBytes":172},{"name":"app-upgrade.md","path":"docs/en/references/app-upgrade.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/app-upgrade.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/en/references/app-upgrade.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/app-upgrade.md)","tokens":300,"sizeBytes":188},{"name":"code-block-view.md","path":"docs/en/references/components/code-block-view.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/code-block-view.md","title":"Components Skill","category":"anthropic-skill","format":"markdown","content":"# Components Skill\n\nPath: `docs/en/references/components/code-block-view.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/code-block-view.md)","tokens":300,"sizeBytes":218},{"name":"image-preview.md","path":"docs/en/references/components/image-preview.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/image-preview.md","title":"Components Skill","category":"anthropic-skill","format":"markdown","content":"# Components Skill\n\nPath: `docs/en/references/components/image-preview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/components/image-preview.md)","tokens":300,"sizeBytes":214},{"name":"feishu-notify.md","path":"docs/en/references/feishu-notify.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/feishu-notify.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/en/references/feishu-notify.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/feishu-notify.md)","tokens":300,"sizeBytes":192},{"name":"fuzzy-search.md","path":"docs/en/references/fuzzy-search.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/fuzzy-search.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/en/references/fuzzy-search.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/en/references/fuzzy-search.md)","tokens":300,"sizeBytes":190},{"name":"app-upgrade.md","path":"docs/zh/references/app-upgrade.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/app-upgrade.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/app-upgrade.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/app-upgrade.md)","tokens":300,"sizeBytes":188},{"name":"channels.md","path":"docs/zh/references/cherryclaw/channels.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/channels.md","title":"Cherryclaw Skill","category":"anthropic-skill","format":"markdown","content":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/channels.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/channels.md)","tokens":300,"sizeBytes":204},{"name":"mcp-claw.md","path":"docs/zh/references/cherryclaw/mcp-claw.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/mcp-claw.md","title":"Cherryclaw Skill","category":"anthropic-skill","format":"markdown","content":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/mcp-claw.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/mcp-claw.md)","tokens":300,"sizeBytes":204},{"name":"overview.md","path":"docs/zh/references/cherryclaw/overview.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/overview.md","title":"Cherryclaw Skill","category":"anthropic-skill","format":"markdown","content":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/overview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/overview.md)","tokens":300,"sizeBytes":204},{"name":"scheduler.md","path":"docs/zh/references/cherryclaw/scheduler.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/scheduler.md","title":"Cherryclaw Skill","category":"anthropic-skill","format":"markdown","content":"# Cherryclaw Skill\n\nPath: `docs/zh/references/cherryclaw/scheduler.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/cherryclaw/scheduler.md)","tokens":300,"sizeBytes":206},{"name":"code-execution.md","path":"docs/zh/references/code-execution.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/code-execution.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/code-execution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/code-execution.md)","tokens":300,"sizeBytes":194},{"name":"code-block-view.md","path":"docs/zh/references/components/code-block-view.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/code-block-view.md","title":"Components Skill","category":"anthropic-skill","format":"markdown","content":"# Components Skill\n\nPath: `docs/zh/references/components/code-block-view.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/code-block-view.md)","tokens":300,"sizeBytes":218},{"name":"image-preview.md","path":"docs/zh/references/components/image-preview.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/image-preview.md","title":"Components Skill","category":"anthropic-skill","format":"markdown","content":"# Components Skill\n\nPath: `docs/zh/references/components/image-preview.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/components/image-preview.md)","tokens":300,"sizeBytes":214},{"name":"database.md","path":"docs/zh/references/database.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/database.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/database.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/database.md)","tokens":300,"sizeBytes":182},{"name":"feishu-notify.md","path":"docs/zh/references/feishu-notify.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/feishu-notify.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/feishu-notify.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/feishu-notify.md)","tokens":300,"sizeBytes":192},{"name":"fuzzy-search.md","path":"docs/zh/references/fuzzy-search.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/fuzzy-search.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/fuzzy-search.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/fuzzy-search.md)","tokens":300,"sizeBytes":190},{"name":"lan-transfer-protocol.md","path":"docs/zh/references/lan-transfer-protocol.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/lan-transfer-protocol.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/lan-transfer-protocol.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/lan-transfer-protocol.md)","tokens":300,"sizeBytes":208},{"name":"message-system.md","path":"docs/zh/references/message-system.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/message-system.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/message-system.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/message-system.md)","tokens":300,"sizeBytes":194},{"name":"services.md","path":"docs/zh/references/services.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/services.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `docs/zh/references/services.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/docs/zh/references/services.md)","tokens":300,"sizeBytes":182},{"name":"CHANGELOG.md","path":"packages/ai-sdk-provider/CHANGELOG.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/CHANGELOG.md","title":"Ai-sdk-provider Skill","category":"anthropic-skill","format":"markdown","content":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/CHANGELOG.md)","tokens":300,"sizeBytes":201},{"name":"package.json","path":"packages/ai-sdk-provider/package.json","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/package.json","title":"Ai-sdk-provider Skill","category":"anthropic-skill","format":"json","content":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/package.json)","tokens":300,"sizeBytes":201},{"name":"tsconfig.json","path":"packages/ai-sdk-provider/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/tsconfig.json","title":"Ai-sdk-provider Skill","category":"anthropic-skill","format":"json","content":"# Ai-sdk-provider Skill\n\nPath: `packages/ai-sdk-provider/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/tsconfig.json)","tokens":300,"sizeBytes":203},{"name":"CHANGELOG.md","path":"packages/aiCore/CHANGELOG.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/CHANGELOG.md","title":"AiCore Skill","category":"anthropic-skill","format":"markdown","content":"# AiCore Skill\n\nPath: `packages/aiCore/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/CHANGELOG.md)","tokens":300,"sizeBytes":174},{"name":"package.json","path":"packages/aiCore/package.json","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/package.json","title":"AiCore Skill","category":"anthropic-skill","format":"json","content":"# AiCore Skill\n\nPath: `packages/aiCore/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/package.json)","tokens":300,"sizeBytes":174},{"name":"tsconfig.json","path":"packages/aiCore/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/tsconfig.json","title":"AiCore Skill","category":"anthropic-skill","format":"json","content":"# AiCore Skill\n\nPath: `packages/aiCore/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/tsconfig.json)","tokens":300,"sizeBytes":176},{"name":"CHANGELOG-OLD.md","path":"packages/extension-table-plus/CHANGELOG-OLD.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG-OLD.md","title":"Extension-table-plus Skill","category":"anthropic-skill","format":"markdown","content":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/CHANGELOG-OLD.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG-OLD.md)","tokens":300,"sizeBytes":224},{"name":"CHANGELOG.md","path":"packages/extension-table-plus/CHANGELOG.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG.md","title":"Extension-table-plus Skill","category":"anthropic-skill","format":"markdown","content":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/CHANGELOG.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/CHANGELOG.md)","tokens":300,"sizeBytes":216},{"name":"package.json","path":"packages/extension-table-plus/package.json","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/package.json","title":"Extension-table-plus Skill","category":"anthropic-skill","format":"json","content":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/package.json)","tokens":300,"sizeBytes":216},{"name":"tsconfig.json","path":"packages/extension-table-plus/tsconfig.json","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/tsconfig.json","title":"Extension-table-plus Skill","category":"anthropic-skill","format":"json","content":"# Extension-table-plus Skill\n\nPath: `packages/extension-table-plus/tsconfig.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/tsconfig.json)","tokens":300,"sizeBytes":218},{"name":"SKILL.md","path":"resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md","title":"cherry-assistant-guide","category":"anthropic-skill","format":"markdown","content":"# cherry-assistant-guide\n\nPath: `resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/cherry-assistant-guide/SKILL.md)","tokens":300,"sizeBytes":304},{"name":"SKILL.md","path":"resources/builtin-agents/cherry-assistant/.claude/skills/faq-collector/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/faq-collector/SKILL.md","title":"faq-collector","category":"anthropic-skill","format":"markdown","content":"---\nname: faq-collector\ndescription: 将成功解决的用户问题收录到 FAQ 知识库。问题解决后自动判断是否收录。也可以在用户说\"收录到 FAQ\"、\"记录这个问题\"、\"add to FAQ\"时手动触发。\n---\n\n# FAQ Collector\n\n**收录标准**: 通用性高、有明确方案、配置/操作类、非直觉问题。不收录: 纯个人环境问题、已有相同条目、未解决问题。\n\n**文件**: `<project_root>/.cherry-assistant/faq.md`（目录不存在则 `mkdir -p .cherry-assistant` 创建）\n\n**条目格式**（追加到末尾）:\n```markdown\n### Q: [通用化问题表述]\n**A:** [简洁方案]\n[分步骤操作]\n- **关键词**: [逗号分隔]\n- **相关文件/Issue**: [路径或#编号]\n- **版本**: vX.X.X | **收录日期**: YYYY-MM-DD\n---\n```\n\n**流程**: 问题解决→判断收录标准→读FAQ查重→无重复则通用化后追加→有相似但更好则更新\n\n**搜索匹配**: 用户提问时先读FAQ关键词匹配→命中直接给答案→未命中走正常诊断\n\n**与 Issue Reporter 协作**: 先收录FAQ(记录方案)→如果是Bug再提Issue→FAQ记关联Issue编号\n","frontmatter":{"name":"faq-collector","description":"将成功解决的用户问题收录到 FAQ 知识库。问题解决后自动判断是否收录。也可以在用户说\"收录到 FAQ\"、\"记录这个问题\"、\"add to FAQ\"时手动触发。"},"isInternal":false,"tokens":383,"sizeBytes":1134},{"name":"SKILL.md","path":"resources/builtin-agents/cherry-assistant/.claude/skills/issue-reporter/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/issue-reporter/SKILL.md","title":"issue-reporter","category":"anthropic-skill","format":"markdown","content":"---\nname: issue-reporter\ndescription: '仅在用户点名 GitHub Issue、Bug Report 或 Feature Request 时使用；未点名 GitHub 的反馈改用 cherry-studio-feedback。'\n---\n\n# Issue Reporter\n\n## 触发边界\n\n只有用户明确要求提交到 GitHub，才能继续本流程。不得从“提交问题”“反馈”“bug”或“功能建议”推断 GitHub；未明确点名 GitHub 时立即转交 `cherry-studio-feedback`，不得运行 `gh auth status`、搜索仓库或发起任何 GitHub 操作。\n\n## 检测 GitHub 登录\n\n每次提交前: `gh auth status 2>&1`。成功→GitHub模式，失败→本地模式。\n\n## GitHub 模式\n\n**Bug Report**: 收集信息(描述/复现步骤/期望/平台/版本) → 查重 `gh search issues \"[关键词]\" --repo CherryHQ/cherry-studio --state open --limit 5` → 读模板 `.github/ISSUE_TEMPLATE/0_bug_report.yml` → 预览给用户 → 确认后 `gh issue create` → 告知链接\n\n**Feature Request**: 确认需求→查重→读模板 `1_feature_request.yml`→预览→确认→提交→记录到 `.cherry-assistant/feature-requests.md`\n\n## 本地模式\n\nBug 存 `.cherry-assistant/bug-reports.md`，Feature 存 `feature-requests.md`：\n```markdown\n### [Bug/Feature]: [标题]\n- **日期**: YYYY-MM-DD | **平台**: OS | **版本**: vX.X.X\n- **描述**: ... | **复现步骤**: 1... 2... | **期望**: ...\n- **状态**: 待提交\n---\n```\n\n存档后引导: GitHub(推荐) https://github.com/CherryHQ/cherry-studio/issues | 论坛 linux.do | 飞书表单 https://mcnnox2fhjfq.feishu.cn/share/base/form/shrcnsjfFkx4gy6wx9LQ70tMaKe\n\n**批量提交**: 有权限时可说「帮我把待提交的都提交了」→读文件→筛待提交→逐个查重预览确认→更新状态为「已提交 #号」\n\n## 注意\n\n- 提交前必须用户确认\n- 脱敏日志中 token/key\n- Redux/IndexedDB schema 变更标记 Blocked: v2\n","frontmatter":{"name":"issue-reporter","description":"仅在用户点名 GitHub Issue、Bug Report 或 Feature Request 时使用；未点名 GitHub 的反馈改用 cherry-studio-feedback。"},"isInternal":false,"tokens":607,"sizeBytes":1878},{"name":"SKILL.md","path":"resources/builtin-agents/cherry-assistant/.claude/skills/skills-manager/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/builtin-agents/cherry-assistant/.claude/skills/skills-manager/SKILL.md","title":"skills-manager","category":"anthropic-skill","format":"markdown","content":"---\nname: skills-manager\ndescription: '搜索、安装或创建 Agent Skill；用户说“find a skill”“搜索技能”“帮我做个 skill”或想扩展能力时使用。'\n---\n\n# Skills Manager\n\n## 搜索和安装\n\n**优先复用**: `find-skills` 可用时先调用它完成搜索、质量检查和安装确认；只有不可用时才执行下面的 CLI 降级流程。\n\n**运行时检测**: 优先 `npx skills`，备选 `$CHERRY_STUDIO_BUN_PATH x skills`，都没有则提示安装 Node.js\n\n**搜索**: 理解需求→提取关键词→`npx skills find [query]`→展示名称/功能/来源\n\n**安装**: Skills 是第三方代码有完整权限，必须: 展示安全警告→提供源码链接→用户确认→`npx skills add <owner/repo@skill> -y`。位置: 项目级 `.claude/skills/` 或用户级 `~/.claude/skills/`\n\n**无结果**: 告知→先尝试直接完成→可复用流程再建议创建自定义 Skill\n\n## 创建 Skills\n\n1. 先确认现有 Skill 无法满足需求，并判断这是不是值得复用的流程；一次性任务直接完成，不强行创建 Skill。\n2. 检查可用 Skill 列表。`skill-creator` 可用时必须调用它，并完整遵循其需求澄清、初始化、编辑、验证和迭代流程；不要绕过它直接手写 `SKILL.md`。\n3. 只有 `skill-creator` 确实不可用时，才明确告诉用户正在降级，然后用 `npx skills init <skill-name>` 初始化，保持 `SKILL.md` 精简，并按需加入 `scripts/`、`references/`、`assets/`。\n4. 创建后至少验证 frontmatter、触发描述和一个真实用例；验证失败就修正后重跑。\n\n**参考**: https://skills.sh/ | `npx skills find/add/init`\n","frontmatter":{"name":"skills-manager","description":"搜索、安装或创建 Agent Skill；用户说“find a skill”“搜索技能”“帮我做个 skill”或想扩展能力时使用。"},"isInternal":false,"tokens":548,"sizeBytes":1675},{"name":"SKILL.md","path":"resources/skills/find-skills/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/find-skills/SKILL.md","title":"find-skills","category":"anthropic-skill","format":"markdown","content":"---\nname: find-skills\ndescription: 'Find and install agent skills when the user asks for a capability that may already exist as a skill.'\nversion: 1.0.0\n---\n\n# Find Skills\n\nThis skill helps you discover and install skills from the open agent skills ecosystem.\n\n## When to Use This Skill\n\nUse this skill when the user:\n\n- Asks \"how do I do X\" where X might be a common task with an existing skill\n- Says \"find a skill for X\" or \"is there a skill for X\"\n- Asks \"can you do X\" where X is a specialized capability\n- Expresses interest in extending agent capabilities\n- Wants to search for tools, templates, or workflows\n- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)\n\n## The skill tools\n\nCherry gives you two built-in tools for skills — use them, and do NOT shell out to\n`npx skills`, `git`, or any package manager:\n\n- **`search_skills(query)`** — search the marketplace by keyword. Returns matches, each with an\n opaque `install_source` value.\n- **`install_skill(install_source)`** — install ONE skill into Cherry's managed\n library and enable it for this agent. Cherry clones the repo, installs just that one skill,\n and registers it in a single deterministic step. Permission handling follows the active Claude\n permission mode (Step 6).\n\n**Browse skills at:** https://skills.sh/\n\n## How to Help Users Find Skills\n\n### Step 1: Understand What They Need\n\nWhen a user asks for help with something, identify:\n\n1. The domain (e.g., React, testing, design, deployment)\n2. The specific task (e.g., writing tests, creating animations, reviewing PRs)\n3. Whether this is a common enough task that a skill likely exists\n\n### Step 2: Check the Leaderboard First\n\nBefore running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.\n\nFor example, top skills for web development include:\n- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each)\n- `anthropics/skills` — Frontend design, document processing (100K+ installs)\n\n### Step 3: Search for Skills\n\nIf the leaderboard doesn't cover the user's need, call the `search_skills` tool:\n\n- User asks \"how do I make my React app faster?\" → `search_skills(\"react performance\")`\n- User asks \"can you help me with PR reviews?\" → `search_skills(\"pr review\")`\n- User asks \"I need to create a changelog\" → `search_skills(\"changelog\")`\n\nEach result includes an opaque `install_source`, source registry, review URL,\ninstall count, and available star count. Pass the exact `install_source` value\nto `install_skill`.\n\n### Step 4: Verify Quality Before Recommending\n\n**Do not recommend a skill based solely on search results.** Always verify:\n\n1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100.\n2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors.\n3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.\n\n### Step 5: Present Options to the User\n\nWhen you find relevant skills, present them to the user with:\n\n1. The skill name and what it does\n2. The install count and source\n3. That you can install it for them into Cherry\n4. A link to learn more at skills.sh\n\nExample response:\n\n```\nI found a skill that might help! The \"react-best-practices\" skill provides\nReact and Next.js performance optimization guidelines from Vercel Engineering.\n(185K installs)\n\nI can install it into Cherry's skill library for you — want me to go ahead?\n\nLearn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices\n```\n\n### Step 6: Install (Uses the Active Permission Mode)\n\n**⚠️ Security:** Skills are third-party code that runs with full agent\npermissions. A malicious skill could read, modify, or delete files on your\nsystem.\n\nBefore installing any skill:\n\n1. **Show a security warning** — tell the user that the skill is third-party\n code and will run with full agent permissions.\n2. **Provide a review link** — the skills.sh page (or source repository) so\n the user can review the skill's SKILL.md and any scripts it contains.\n3. **Require install intent** — call `install_skill` only when the user asked to install the skill\n or accepted a presented option. A search-only request must not mutate the skill library.\n\nOnce the user has expressed install intent, call `install_skill` with the exact `install_source`\nfrom the search result. Do not add another model-level confirmation step: Claude's active permission\nmode is the authority. Default and accept-edits modes may prompt through the SDK; bypass-permissions\nmode runs directly.\n\n- `install_skill(\"claude-plugins:vercel-labs/agent-skills/skills/react-best-practices\")`\n\nDo **not** run `npx skills add`, `git clone`, or any shell command to install — that would\ninstall the whole repo (dozens of skills), scatter symlinks across other tools, and land\noutside Cherry's library. `install_skill` installs **only that one skill** into Cherry's\nmanaged library in one deterministic step. The Claude Agent SDK applies the configured permission\nmode before it runs. Once done it is registered and listed in the app — nothing is left elsewhere.\n\n## Common Skill Categories\n\nWhen searching, consider these common categories:\n\n| Category | Example Queries |\n| --------------- | ---------------------------------------- |\n| Web Development | react, nextjs, typescript, css, tailwind |\n| Testing | testing, jest, playwright, e2e |\n| DevOps | deploy, docker, kubernetes, ci-cd |\n| Documentation | docs, readme, changelog, api-docs |\n| Code Quality | review, lint, refactor, best-practices |\n| Design | ui, ux, design-system, accessibility |\n| Productivity | workflow, automation, git |\n\n## Tips for Effective Searches\n\n1. **Use specific keywords**: \"react testing\" is better than just \"testing\"\n2. **Try alternative terms**: If \"deploy\" doesn't work, try \"deployment\" or \"ci-cd\"\n3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`\n\n## When No Skills Are Found\n\nIf no relevant skills exist:\n\n1. Acknowledge that no existing skill was found\n2. Offer to help with the task directly using your general capabilities\n3. Offer to author a custom skill for the task (the skill-creator skill handles this)\n\nExample:\n\n```\nI searched for skills related to \"xyz\" but didn't find any matches.\nI can still help you with this task directly! Would you like me to proceed?\n\nIf this is something you do often, I can author a custom skill for you — just ask\nme to \"create a skill for <task>\" and I'll write one into Cherry's skills directory.\n```\n","frontmatter":{"name":"find-skills","description":"Find and install agent skills when the user asks for a capability that may already exist as a skill.","version":"1.0.0"},"isInternal":false,"tokens":1605,"sizeBytes":6950},{"name":"schemas.md","path":"resources/skills/skill-creator/references/schemas.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/references/schemas.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `resources/skills/skill-creator/references/schemas.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/references/schemas.md)","tokens":300,"sizeBytes":226},{"name":"SKILL.md","path":"resources/skills/skill-creator/SKILL.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/SKILL.md","title":"skill-creator","category":"anthropic-skill","format":"markdown","content":"---\nname: skill-creator\ndescription: 'Create, edit, evaluate, and optimize skills, including benchmarking and description tuning for better triggering.'\nversion: 1.0.0\n---\n\n## Cherry Studio workflow (READ FIRST — overrides packaging / install steps below)\n\nYou are running inside Cherry Studio. Skills live in a managed registry that Cherry\nkeeps in sync with the filesystem automatically — there is **no** install or register\ntool to call, and you should **ignore** any `package_skill.py` / `.skill` packaging\nsteps mentioned later in this file (they apply to Claude Code / Claude.ai, not here).\n\n**To create a new skill, write it straight into Cherry's managed skills directory:**\n\n1. Resolve the directory once by running `echo \"$CHERRY_STUDIO_SKILLS_DIR\"` in Bash.\n That folder is Cherry's managed skill library.\n2. Create `$CHERRY_STUDIO_SKILLS_DIR/<skill-folder-name>/` and write `SKILL.md` plus any\n supporting files (`scripts/`, `references/`, `assets/`) into it with your normal file\n tools.\n3. That's it. Cherry's skill sync detects the new directory, registers it in the catalog,\n and lists it in the app — no register step. You can re-edit the files in place at any\n time and the changes are picked up on the next sync.\n\nUse a lowercase, hyphenated `<skill-folder-name>` (e.g. `my-cool-skill`). The `name:`\nfield inside your `SKILL.md` frontmatter must match the folder name and use only\nlowercase letters, numbers, and hyphens (e.g. `name: my-cool-skill` with folder\n`my-cool-skill`), per the Agent Skills spec — it is not a free-form display name.\n\nEval / test workspaces (`<skill-name>-workspace/`, `iteration-*/`, etc.) from the\nevaluation loop described below must be created **outside** that skills directory —\ne.g. as a sibling under the user's workspace — so they don't get bundled into the\nskill. The evaluation loop itself still applies; only the packaging and install\nmechanics change.\n\n---\n\n# Skill Creator\n\nA skill for creating new skills and iteratively improving them.\n\nAt a high level, the process of creating a skill goes like this:\n\n- Decide what you want the skill to do and roughly how it should do it\n- Write a draft of the skill\n- Create a few test prompts and run claude-with-access-to-the-skill on them\n- Help the user evaluate the results both qualitatively and quantitatively\n - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)\n - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics\n- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)\n- Repeat until you're satisfied\n- Expand the test set and try again at larger scale\n\nYour job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like \"I want to make a skill for X\". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.\n\nOn the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.\n\nOf course, you should always be flexible and if the user is like \"I don't need to run a bunch of evaluations, just vibe with me\", you can do that instead.\n\nThen after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.\n\nCool? Cool.\n\n## Communicating with the user\n\nThe skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google \"how to install npm\". On the other hand, the bulk of users are probably fairly computer-literate.\n\nSo please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:\n\n- \"evaluation\" and \"benchmark\" are borderline, but OK\n- for \"JSON\" and \"assertion\" you want to see serious cues from the user that they know what those things are before using them without explaining them\n\nIt's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.\n\n---\n\n## Creating a skill\n\n### Capture Intent\n\nStart by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say \"turn this into a skill\"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.\n\n1. What should this skill enable Claude to do?\n2. When should this skill trigger? (what user phrases/contexts)\n3. What's the expected output format?\n4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.\n\n### Interview and Research\n\nProactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.\n\nCheck available MCPs - if useful for research (searching docs, finding similar skills, looking up best practices), research in parallel via subagents if available, otherwise inline. Come prepared with context to reduce burden on the user.\n\n### Write the SKILL.md\n\nBased on the user interview, fill in these components:\n\n- **name**: Skill identifier\n- **description**: When to trigger, what it does. This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All \"when to use\" info goes here, not in the body. Note: currently Claude has a tendency to \"undertrigger\" skills -- to not use them when they'd be useful. To combat this, please make the skill descriptions a little bit \"pushy\". So for instance, instead of \"How to build a simple fast dashboard to display internal Anthropic data.\", you might write \"How to build a simple fast dashboard to display internal Anthropic data. Make sure to use this skill whenever the user mentions dashboards, data visualization, internal metrics, or wants to display any kind of company data, even if they don't explicitly ask for a 'dashboard.'\"\n- **compatibility**: Required tools, dependencies (optional, rarely needed)\n- **the rest of the skill :)**\n\n### Skill Writing Guide\n\n#### Anatomy of a Skill\n\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled Resources (optional)\n ├── scripts/ - Executable code for deterministic/repetitive tasks\n ├── references/ - Docs loaded into context as needed\n └── assets/ - Files used in output (templates, icons, fonts)\n```\n\n#### Progressive Disclosure\n\nSkills use a three-level loading system:\n1. **Metadata** (name + description) - Always in context (~100 words)\n2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal)\n3. **Bundled resources** - As needed (unlimited, scripts can execute without loading)\n\nThese word counts are approximate and you can feel free to go longer if needed.\n\n**Key patterns:**\n- Keep SKILL.md under 500 lines; if you're approaching this limit, add an additional layer of hierarchy along with clear pointers about where the model using the skill should go next to follow up.\n- Reference files clearly from SKILL.md with guidance on when to read them\n- For large reference files (>300 lines), include a table of contents\n\n**Domain organization**: When a skill supports multiple domains/frameworks, organize by variant:\n```\ncloud-deploy/\n├── SKILL.md (workflow + selection)\n└── references/\n ├── aws.md\n ├── gcp.md\n └── azure.md\n```\nClaude reads only the relevant reference file.\n\n#### Principle of Lack of Surprise\n\nThis goes without saying, but skills must not contain malware, exploit code, or any content that could compromise system security. A skill's contents should not surprise the user in their intent if described. Don't go along with requests to create misleading skills or skills designed to facilitate unauthorized access, data exfiltration, or other malicious activities. Things like a \"roleplay as an XYZ\" are OK though.\n\n#### Writing Patterns\n\nPrefer using the imperative form in instructions.\n\n**Defining output formats** - You can do it like this:\n```markdown\n## Report structure\nALWAYS use this exact template:\n# [Title]\n## Executive summary\n## Key findings\n## Recommendations\n```\n\n**Examples pattern** - It's useful to include examples. You can format them like this (but if \"Input\" and \"Output\" are in the examples you might want to deviate a little):\n```markdown\n## Commit message format\n**Example 1:**\nInput: Added user authentication with JWT tokens\nOutput: feat(auth): implement JWT-based authentication\n```\n\n### Writing Style\n\nTry to explain to the model why things are important in lieu of heavy-handed musty MUSTs. Use theory of mind and try to make the skill general and not super-narrow to specific examples. Start by writing a draft and then look at it with fresh eyes and improve it.\n\n### Test Cases\n\nAfter writing the skill draft, come up with 2-3 realistic test prompts — the kind of thing a real user would actually say. Share them with the user: [you don't have to use this exact language] \"Here are a few test cases I'd like to try. Do these look right, or do you want to add more?\" Then run them.\n\nSave test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. You'll draft assertions in the next step while the runs are in progress.\n\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\n \"id\": 1,\n \"prompt\": \"User's task prompt\",\n \"expected_output\": \"Description of expected result\",\n \"files\": []\n }\n ]\n}\n```\n\nSee `references/schemas.md` for the full schema (including the `assertions` field, which you'll add later).\n\n## Running and evaluating test cases\n\nThis section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill.\n\nPut results in `<skill-name>-workspace/` as a sibling to the skill directory. Within the workspace, organize results by iteration (`iteration-1/`, `iteration-2/`, etc.) and within that, each test case gets a directory (`eval-0/`, `eval-1/`, etc.). Don't create all of this upfront — just create directories as you go.\n\n### Step 1: Spawn all runs (with-skill AND baseline) in the same turn\n\nFor each test case, spawn two subagents in the same turn — one with the skill, one without. This is important: don't spawn the with-skill runs first and then come back for baselines later. Launch everything at once so it all finishes around the same time.\n\n**With-skill run:**\n\n```\nExecute this task:\n- Skill path: <path-to-skill>\n- Task: <eval prompt>\n- Input files: <eval files if any, or \"none\">\n- Save outputs to: <workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/\n- Outputs to save: <what the user cares about — e.g., \"the .docx file\", \"the final CSV\">\n```\n\n**Baseline run** (same prompt, but the baseline depends on context):\n- **Creating a new skill**: no skill at all. Same prompt, no skill path, save to `without_skill/outputs/`.\n- **Improving an existing skill**: the old version. Before editing, snapshot the skill (`cp -r <skill-path> <workspace>/skill-snapshot/`), then point the baseline subagent at the snapshot. Save to `old_skill/outputs/`.\n\nWrite an `eval_metadata.json` for each test case (assertions can be empty for now). Give each eval a descriptive name based on what it's testing — not just \"eval-0\". Use this name for the directory too. If this iteration uses new or modified eval prompts, create these files for each new eval directory — don't assume they carry over from previous iterations.\n\n```json\n{\n \"eval_id\": 0,\n \"eval_name\": \"descriptive-name-here\",\n \"prompt\": \"The user's task prompt\",\n \"assertions\": []\n}\n```\n\n### Step 2: While runs are in progress, draft assertions\n\nDon't just wait for the runs to finish — you can use this time productively. Draft quantitative assertions for each test case and explain them to the user. If assertions already exist in `evals/evals.json`, review them and explain what they check.\n\nGood assertions are objectively verifiable and have descriptive names — they should read clearly in the benchmark viewer so someone glancing at the results immediately understands what each one checks. Subjective skills (writing style, design quality) are better evaluated qualitatively — don't force assertions onto things that need human judgment.\n\nUpdate the `eval_metadata.json` files and `evals/evals.json` with the assertions once drafted. Also explain to the user what they'll see in the viewer — both the qualitative outputs and the quantitative benchmark.\n\n### Step 3: As runs complete, capture timing data\n\nWhen each subagent task completes, you receive a notification containing `total_tokens` and `duration_ms`. Save this data immediately to `timing.json` in the run directory:\n\n```json\n{\n \"total_tokens\": 84852,\n \"duration_ms\": 23332,\n \"total_duration_seconds\": 23.3\n}\n```\n\nThis is the only opportunity to capture this data — it comes through the task notification and isn't persisted elsewhere. Process each notification as it arrives rather than trying to batch them.\n\n### Step 4: Grade, aggregate, and launch the viewer\n\nOnce all runs are done:\n\n1. **Grade each run** — spawn a grader subagent (or grade inline) that reads `agents/grader.md` and evaluates each assertion against the outputs. Save results to `grading.json` in each run directory. The grading.json expectations array must use the fields `text`, `passed`, and `evidence` (not `name`/`met`/`details` or other variants) — the viewer depends on these exact field names. For assertions that can be checked programmatically, write and run a script rather than eyeballing it — scripts are faster, more reliable, and can be reused across iterations.\n\n2. **Aggregate into benchmark** — run the aggregation script from the skill-creator directory:\n ```bash\n python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>\n ```\n This produces `benchmark.json` and `benchmark.md` with pass_rate, time, and tokens for each configuration, with mean ± stddev and the delta. If generating benchmark.json manually, see `references/schemas.md` for the exact schema the viewer expects.\nPut each with_skill version before its baseline counterpart.\n\n3. **Do an analyst pass** — read the benchmark data and surface patterns the aggregate stats might hide. See `agents/analyzer.md` (the \"Analyzing Benchmark Results\" section) for what to look for — things like assertions that always pass regardless of skill (non-discriminating), high-variance evals (possibly flaky), and time/token tradeoffs.\n\n4. **Launch the viewer** with both qualitative outputs and quantitative data:\n ```bash\n nohup python <skill-creator-path>/eval-viewer/generate_review.py \\\n <workspace>/iteration-N \\\n --skill-name \"my-skill\" \\\n --benchmark <workspace>/iteration-N/benchmark.json \\\n > /dev/null 2>&1 &\n VIEWER_PID=$!\n ```\n For iteration 2+, also pass `--previous-workspace <workspace>/iteration-<N-1>`.\n\n **Cowork / headless environments:** If `webbrowser.open()` is not available or the environment has no display, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Feedback will be downloaded as a `feedback.json` file when the user clicks \"Submit All Reviews\". After download, copy `feedback.json` into the workspace directory for the next iteration to pick up.\n\nNote: please use generate_review.py to create the viewer; there's no need to write custom HTML.\n\n5. **Tell the user** something like: \"I've opened the results in your browser. There are two tabs — 'Outputs' lets you click through each test case and leave feedback, 'Benchmark' shows the quantitative comparison. When you're done, come back here and let me know.\"\n\n### What the user sees in the viewer\n\nThe \"Outputs\" tab shows one test case at a time:\n- **Prompt**: the task that was given\n- **Output**: the files the skill produced, rendered inline where possible\n- **Previous Output** (iteration 2+): collapsed section showing last iteration's output\n- **Formal Grades** (if grading was run): collapsed section showing assertion pass/fail\n- **Feedback**: a textbox that auto-saves as they type\n- **Previous Feedback** (iteration 2+): their comments from last time, shown below the textbox\n\nThe \"Benchmark\" tab shows the stats summary: pass rates, timing, and token usage for each configuration, with per-eval breakdowns and analyst observations.\n\nNavigation is via prev/next buttons or arrow keys. When done, they click \"Submit All Reviews\" which saves all feedback to `feedback.json`.\n\n### Step 5: Read the feedback\n\nWhen the user tells you they're done, read `feedback.json`:\n\n```json\n{\n \"reviews\": [\n {\"run_id\": \"eval-0-with_skill\", \"feedback\": \"the chart is missing axis labels\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-1-with_skill\", \"feedback\": \"\", \"timestamp\": \"...\"},\n {\"run_id\": \"eval-2-with_skill\", \"feedback\": \"perfect, love this\", \"timestamp\": \"...\"}\n ],\n \"status\": \"complete\"\n}\n```\n\nEmpty feedback means the user thought it was fine. Focus your improvements on the test cases where the user had specific complaints.\n\nKill the viewer server when you're done with it:\n\n```bash\nkill $VIEWER_PID 2>/dev/null\n```\n\n---\n\n## Improving the skill\n\nThis is the heart of the loop. You've run the test cases, the user has reviewed the results, and now you need to make the skill better based on their feedback.\n\n### How to think about improvements\n\n1. **Generalize from the feedback.** The big picture thing that's happening here is that we're trying to create skills that can be used a million times (maybe literally, maybe even more who knows) across many different prompts. Here you and the user are iterating on only a few examples over and over again because it helps move faster. The user knows these examples in and out and it's quick for them to assess new outputs. But if the skill you and the user are codeveloping works only for those examples, it's useless. Rather than put in fiddly overfitty changes, or oppressively constrictive MUSTs, if there's some stubborn issue, you might try branching out and using different metaphors, or recommending different patterns of working. It's relatively cheap to try and maybe you'll land on something great.\n\n2. **Keep the prompt lean.** Remove things that aren't pulling their weight. Make sure to read the transcripts, not just the final outputs — if it looks like the skill is making the model waste a bunch of time doing things that are unproductive, you can try getting rid of the parts of the skill that are making it do that and seeing what happens.\n\n3. **Explain the why.** Try hard to explain the **why** behind everything you're asking the model to do. Today's LLMs are *smart*. They have good theory of mind and when given a good harness can go beyond rote instructions and really make things happen. Even if the feedback from the user is terse or frustrated, try to actually understand the task and why the user is writing what they wrote, and what they actually wrote, and then transmit this understanding into the instructions. If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag — if possible, reframe and explain the reasoning so that the model understands why the thing you're asking for is important. That's a more humane, powerful, and effective approach.\n\n4. **Look for repeated work across test cases.** Read the transcripts from the test runs and notice if the subagents all independently wrote similar helper scripts or took the same multi-step approach to something. If all 3 test cases resulted in the subagent writing a `create_docx.py` or a `build_chart.py`, that's a strong signal the skill should bundle that script. Write it once, put it in `scripts/`, and tell the skill to use it. This saves every future invocation from reinventing the wheel.\n\nThis task is pretty important (we are trying to create billions a year in economic value here!) and your thinking time is not the blocker; take your time and really mull things over. I'd suggest writing a draft revision and then looking at it anew and making improvements. Really do your best to get into the head of the user and understand what they want and need.\n\n### The iteration loop\n\nAfter improving the skill:\n\n1. Apply your improvements to the skill\n2. Rerun all test cases into a new `iteration-<N+1>/` directory, including baseline runs. If you're creating a new skill, the baseline is always `without_skill` (no skill) — that stays the same across iterations. If you're improving an existing skill, use your judgment on what makes sense as the baseline: the original version the user came in with, or the previous iteration.\n3. Launch the reviewer with `--previous-workspace` pointing at the previous iteration\n4. Wait for the user to review and tell you they're done\n5. Read the new feedback, improve again, repeat\n\nKeep going until:\n- The user says they're happy\n- The feedback is all empty (everything looks good)\n- You're not making meaningful progress\n\n---\n\n## Advanced: Blind comparison\n\nFor situations where you want a more rigorous comparison between two versions of a skill (e.g., the user asks \"is the new version actually better?\"), there's a blind comparison system. Read `agents/comparator.md` and `agents/analyzer.md` for the details. The basic idea is: give two outputs to an independent agent without telling it which is which, and let it judge quality. Then analyze why the winner won.\n\nThis is optional, requires subagents, and most users won't need it. The human review loop is usually sufficient.\n\n---\n\n## Description Optimization\n\nThe description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. After creating or improving a skill, offer to optimize the description for better triggering accuracy.\n\n### Step 1: Generate trigger eval queries\n\nCreate 20 eval queries — a mix of should-trigger and should-not-trigger. Save as JSON:\n\n```json\n[\n {\"query\": \"the user prompt\", \"should_trigger\": true},\n {\"query\": \"another prompt\", \"should_trigger\": false}\n]\n```\n\nThe queries must be realistic and something a Claude Code or Claude.ai user would actually type. Not abstract requests, but requests that are concrete and specific and have a good amount of detail. For instance, file paths, personal context about the user's job or situation, column names and values, company names, URLs. A little bit of backstory. Some might be in lowercase or contain abbreviations or typos or casual speech. Use a mix of different lengths, and focus on edge cases rather than making them clear-cut (the user will get a chance to sign off on them).\n\nBad: `\"Format this data\"`, `\"Extract text from PDF\"`, `\"Create a chart\"`\n\nGood: `\"ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage. The revenue is in column C and costs are in column D i think\"`\n\nFor the **should-trigger** queries (8-10), think about coverage. You want different phrasings of the same intent — some formal, some casual. Include cases where the user doesn't explicitly name the skill or file type but clearly needs it. Throw in some uncommon use cases and cases where this skill competes with another but should win.\n\nFor the **should-not-trigger** queries (8-10), the most valuable ones are the near-misses — queries that share keywords or concepts with the skill but actually need something different. Think adjacent domains, ambiguous phrasing where a naive keyword match would trigger but shouldn't, and cases where the query touches on something the skill does but in a context where another tool is more appropriate.\n\nThe key thing to avoid: don't make should-not-trigger queries obviously irrelevant. \"Write a fibonacci function\" as a negative test for a PDF skill is too easy — it doesn't test anything. The negative cases should be genuinely tricky.\n\n### Step 2: Review with user\n\nPresent the eval set to the user for review using the HTML template:\n\n1. Read the template from `assets/eval_review.html`\n2. Replace the placeholders:\n - `__EVAL_DATA_PLACEHOLDER__` → the JSON array of eval items (no quotes around it — it's a JS variable assignment)\n - `__SKILL_NAME_PLACEHOLDER__` → the skill's name\n - `__SKILL_DESCRIPTION_PLACEHOLDER__` → the skill's current description\n3. Write to a temp file (e.g., `/tmp/eval_review_<skill-name>.html`) and open it: `open /tmp/eval_review_<skill-name>.html`\n4. The user can edit queries, toggle should-trigger, add/remove entries, then click \"Export Eval Set\"\n5. The file downloads to `~/Downloads/eval_set.json` — check the Downloads folder for the most recent version in case there are multiple (e.g., `eval_set (1).json`)\n\nThis step matters — bad eval queries lead to bad descriptions.\n\n### Step 3: Run the optimization loop\n\nTell the user: \"This will take some time — I'll run the optimization loop in the background and check on it periodically.\"\n\nSave the eval set to the workspace, then run in the background:\n\n```bash\npython -m scripts.run_loop \\\n --eval-set <path-to-trigger-eval.json> \\\n --skill-path <path-to-skill> \\\n --model <model-id-powering-this-session> \\\n --max-iterations 5 \\\n --verbose\n```\n\nUse the model ID from your system prompt (the one powering the current session) so the triggering test matches what the user actually experiences.\n\nWhile it runs, periodically tail the output to give the user updates on which iteration it's on and what the scores look like.\n\nThis handles the full optimization loop automatically. It splits the eval set into 60% train and 40% held-out test, evaluates the current description (running each query 3 times to get a reliable trigger rate), then calls Claude to propose improvements based on what failed. It re-evaluates each new description on both train and test, iterating up to 5 times. When it's done, it opens an HTML report in the browser showing the results per iteration and returns JSON with `best_description` — selected by test score rather than train score to avoid overfitting.\n\n### How skill triggering works\n\nUnderstanding the triggering mechanism helps design better eval queries. Skills appear in Claude's `available_skills` list with their name + description, and Claude decides whether to consult a skill based on that description. The important thing to know is that Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like \"read this PDF\" may not trigger a skill even if the description matches perfectly, because Claude can handle them directly with basic tools. Complex, multi-step, or specialized queries reliably trigger skills when the description matches.\n\nThis means your eval queries should be substantive enough that Claude would actually benefit from consulting a skill. Simple queries like \"read file X\" are poor test cases — they won't trigger skills regardless of description quality.\n\n### Step 4: Apply the result\n\nTake `best_description` from the JSON output and update the skill's SKILL.md frontmatter. Show the user before/after and report the scores.\n\n---\n\n### Package and Present (only if `present_files` tool is available)\n\nCheck whether you have access to the `present_files` tool. If you don't, skip this step. If you do, package the skill and present the .skill file to the user:\n\n```bash\npython -m scripts.package_skill <path/to/skill-folder>\n```\n\nAfter packaging, direct the user to the resulting `.skill` file path so they can install it.\n\n---\n\n## Claude.ai-specific instructions\n\nIn Claude.ai, the core workflow is the same (draft → test → review → improve → repeat), but because Claude.ai doesn't have subagents, some mechanics change. Here's what to adapt:\n\n**Running test cases**: No subagents means no parallel execution. For each test case, read the skill's SKILL.md, then follow its instructions to accomplish the test prompt yourself. Do them one at a time. This is less rigorous than independent subagents (you wrote the skill and you're also running it, so you have full context), but it's a useful sanity check — and the human review step compensates. Skip the baseline runs — just use the skill to complete the task as requested.\n\n**Reviewing results**: If you can't open a browser (e.g., Claude.ai's VM has no display, or you're on a remote server), skip the browser reviewer entirely. Instead, present results directly in the conversation. For each test case, show the prompt and the output. If the output is a file the user needs to see (like a .docx or .xlsx), save it to the filesystem and tell them where it is so they can download and inspect it. Ask for feedback inline: \"How does this look? Anything you'd change?\"\n\n**Benchmarking**: Skip the quantitative benchmarking — it relies on baseline comparisons which aren't meaningful without subagents. Focus on qualitative feedback from the user.\n\n**The iteration loop**: Same as before — improve the skill, rerun the test cases, ask for feedback — just without the browser reviewer in the middle. You can still organize results into iteration directories on the filesystem if you have one.\n\n**Description optimization**: This section requires the `claude` CLI tool (specifically `claude -p`) which is only available in Claude Code. Skip it if you're on Claude.ai.\n\n**Blind comparison**: Requires subagents. Skip it.\n\n**Packaging**: The `package_skill.py` script works anywhere with Python and a filesystem. On Claude.ai, you can run it and the user can download the resulting `.skill` file.\n\n**Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. In this case:\n- **Preserve the original name.** Note the skill's directory name and `name` frontmatter field -- use them unchanged. E.g., if the installed skill is `research-helper`, output `research-helper.skill` (not `research-helper-v2`).\n- **Copy to a writeable location before editing.** The installed skill path may be read-only. Copy to `/tmp/skill-name/`, edit there, and package from the copy.\n- **If packaging manually, stage in `/tmp/` first**, then copy to the output directory -- direct writes may fail due to permissions.\n\n---\n\n## Cowork-Specific Instructions\n\nIf you're in Cowork, the main things to know are:\n\n- You have subagents, so the main workflow (spawn test cases in parallel, run baselines, grade, etc.) all works. (However, if you run into severe problems with timeouts, it's OK to run the test prompts in series rather than parallel.)\n- You don't have a browser or display, so when generating the eval viewer, use `--static <output_path>` to write a standalone HTML file instead of starting a server. Then proffer a link that the user can click to open the HTML in their browser.\n- For whatever reason, the Cowork setup seems to disincline Claude from generating the eval viewer after running the tests, so just to reiterate: whether you're in Cowork or in Claude Code, after running tests, you should always generate the eval viewer for the human to look at examples before revising the skill yourself and trying to make corrections, using `generate_review.py` (not writing your own boutique html code). Sorry in advance but I'm gonna go all caps here: GENERATE THE EVAL VIEWER *BEFORE* evaluating inputs yourself. You want to get them in front of the human ASAP!\n- Feedback works differently: since there's no running server, the viewer's \"Submit All Reviews\" button will download `feedback.json` as a file. You can then read it from there (you may have to request access first).\n- Packaging works — `package_skill.py` just needs Python and a filesystem.\n- Description optimization (`run_loop.py` / `run_eval.py`) should work in Cowork just fine since it uses `claude -p` via subprocess, not a browser, but please save it until you've fully finished making the skill and the user agrees it's in good shape.\n- **Updating an existing skill**: The user might be asking you to update an existing skill, not create a new one. Follow the update guidance in the claude.ai section above.\n\n---\n\n## Reference files\n\nThe agents/ directory contains instructions for specialized subagents. Read them when you need to spawn the relevant subagent.\n\n- `agents/grader.md` — How to evaluate assertions against outputs\n- `agents/comparator.md` — How to do blind A/B comparison between two outputs\n- `agents/analyzer.md` — How to analyze why one version beat another\n\nThe references/ directory has additional documentation:\n- `references/schemas.md` — JSON structures for evals.json, grading.json, etc.\n\n---\n\nRepeating one more time the core loop here for emphasis:\n\n- Figure out what the skill is about\n- Draft or edit the skill\n- Run claude-with-access-to-the-skill on test prompts\n- With the user, evaluate the outputs:\n - Create benchmark.json and run `eval-viewer/generate_review.py` to help the user review them\n - Run quantitative evals\n- Repeat until you and the user are satisfied\n- Package the final skill and return it to the user.\n\nPlease add steps to your TodoList, if you have such a thing, to make sure you don't forget. If you're in Cowork, please specifically put \"Create evals JSON and run `eval-viewer/generate_review.py` so human can review test cases\" in your TodoList to make sure it happens.\n\nGood luck!\n","frontmatter":{"name":"skill-creator","description":"Create, edit, evaluate, and optimize skills, including benchmarking and description tuning for better triggering.","version":"1.0.0"},"isInternal":false,"tokens":7717,"sizeBytes":34743},{"name":".gitignore","path":".claude/skills/.gitignore","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/.gitignore","title":"Claude Directive: .gitignore","category":"claude-rule","format":"markdown","content":"# Claude Directive: .gitignore\n\nPath: `.claude/skills/.gitignore`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.claude/skills/.gitignore)","tokens":300,"sizeBytes":184},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/CLAUDE.md)","tokens":300,"sizeBytes":163},{"name":"README.md","path":"packages/ai-sdk-provider/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/README.md","title":"ai-sdk-provider Documentation","category":"plugin-manifest","format":"markdown","content":"# ai-sdk-provider Documentation\n\nPath: `packages/ai-sdk-provider/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/ai-sdk-provider/README.md)","tokens":300,"sizeBytes":203},{"name":"README.md","path":"packages/aiCore/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/README.md","title":"aiCore Documentation","category":"plugin-manifest","format":"markdown","content":"# aiCore Documentation\n\nPath: `packages/aiCore/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/aiCore/README.md)","tokens":300,"sizeBytes":176},{"name":"README.md","path":"packages/extension-table-plus/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/README.md","title":"extension-table-plus Documentation","category":"plugin-manifest","format":"markdown","content":"# extension-table-plus Documentation\n\nPath: `packages/extension-table-plus/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/packages/extension-table-plus/README.md)","tokens":300,"sizeBytes":218},{"name":"analyzer.md","path":"resources/skills/skill-creator/agents/analyzer.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/analyzer.md","title":"Subagent: analyzer","category":"subagent-persona","format":"markdown","content":"# Subagent: analyzer\n\nPath: `resources/skills/skill-creator/agents/analyzer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/analyzer.md)","tokens":300,"sizeBytes":222},{"name":"comparator.md","path":"resources/skills/skill-creator/agents/comparator.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/comparator.md","title":"Subagent: comparator","category":"subagent-persona","format":"markdown","content":"# Subagent: comparator\n\nPath: `resources/skills/skill-creator/agents/comparator.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/comparator.md)","tokens":300,"sizeBytes":228},{"name":"grader.md","path":"resources/skills/skill-creator/agents/grader.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/grader.md","title":"Subagent: grader","category":"subagent-persona","format":"markdown","content":"# Subagent: grader\n\nPath: `resources/skills/skill-creator/agents/grader.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/resources/skills/skill-creator/agents/grader.md)","tokens":300,"sizeBytes":216},{"name":"README.md","path":"src/main/services/agents/README.md","rawUrl":"https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/src/main/services/agents/README.md","title":"Subagent: readme","category":"subagent-persona","format":"markdown","content":"# Subagent: readme\n\nPath: `src/main/services/agents/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/src/main/services/agents/README.md)","tokens":300,"sizeBytes":190}],"systemPromptSnippet":"<yakaai_skills repo=\"CherryHQ/cherry-studio\">\n<!-- File: .agents/skills/create-skill/SKILL.md (Tokens: ~810 | Category: anthropic-skill) -->\n---\nname: create-skill\ndescription: Create a new skill in the current repository. Use when the user wants to create/add a new skill, or mentions creating a skill from scratch. This skill follows the workflow defined in .agents/skills/README.md and helps scaffold, validate, and sync new skills.\n---\n\n# Create Skill\n\nCreate a new skill in `.agents/skills/<skill-name>/` following the workflow defined in `.agents/skills/README.md`.\n\n## Workflow\n\n### Step 1: Gather Intent\n\nBefore creating anything, ask the user:\n\n1. **Skill name**: What should the skill be called? (lowercase, digits, hyphens only, e.g., `gh-create-pr`, `prepare-release`)\n2. **Description**: What should this skill do? Include specific trigger contexts (e.g., \"Use when user asks to create PRs\")\n3. **Is this a public skill?**: Should it be synced to `.claude/skills/` for shared use? (default: no, private only)\n4. **Test cases** (optional): Does the user want to set up evals for this skill?\n\nIf the user provides partial info (e.g., just a name), proceed with reasonable defaults and ask to confirm.\n\n### Step 2: Read Guidelines\n\nAlways read `.agents/skills/README.md` before creating a new skill to ensure compliance with the current workflow.\n\n### Step 3: Create Skill Structure\n\nCreate the following directory structure:\n\n```\n.agents/skills/<skill-name>/\n└── SKILL.md\n```\n\n**SKILL.md template:**\n\n```markdown\n---\nname: <skill-name>\ndescription: <description>\n---\n\n# <Skill Name>\n\n[Instructions for the skill]\n```\n\n**Frontmatter fields:**\n- `name`: Skill identifier (lowercase, digits, hyphens)\n- `description`: When to trigger (what the skill does + specific contexts)\n\n### Step 4: Sync (if public)\n\nIf the user wants a **public skill**, before validation:\n\n1. Add the skill name to `.agents/skills/public-skills.txt` (one per line, no inline comments)\n2. Run sync:\n ```bash\n pnpm skills:sync\n ```\n\nThis creates a symlink at `.claude/skills/<skill-name>/` pointing to `.agents/skills/<skill-name>/`.\n\n**Note**: `pnpm skills:check` primarily validates public skills (those in `public-skills.txt`) and also verifies related governance files, so you must sync first before validating.\n\n### Step 5: Validate\n\nRun the validation command:\n\n```bash\npnpm skills:check\n```\n\nIf there are issues, fix them and re-run.\n\n### Step 6: Summary\n\nPresent the user with:\n- Created files\n- Validation result\n- Next steps (how to use the skill)\n\n## Naming Rules\n\n- Use lowercase letters, digits, and hyphens only\n- Prefer short, action-oriented names (e.g., `gh-create-pr`)\n\n## Public vs Private Skills\n\n| Type | Location | Sync | Requires |\n|------|----------|------|----------|\n| Private | `.agents/skills/` | No | Just create the folder |\n| Public | Both | Yes | Add to `public-skills.txt` + run `pnpm skills:sync` |\n\n## Commands Reference\n\n```bash\n# Validate skill structure\npnpm skills:check\n\n# Sync public skills to Claude\npnpm skills:sync\n```\n\n## Constraints\n\n- Never create skills outside `.agents/skills/<skill-name>/`\n- Always run `pnpm skills:check` before completing\n- Public skills require both adding to `public-skills.txt` AND running `pnpm skills:sync`\n- If the skill-creator skill is available, you may use it for advanced skill development (evals, iterations), but this skill handles the basic creation workflow.\n\n<!-- File: .agents/skills/gh-create-issue/SKILL.md (Tokens: ~1421 | Category: anthropic-skill) -->\n---\nname: gh-create-issue\ndescription: Use when user wants to create a GitHub issue for the current repository. Must read and follow the repository's issue template format.\n---\n\n# GitHub Create Issue\n\nUse this skill when the user requests to create an issue. Must follow the repository's issue template format.\n\n## Workflow\n\n### Step 1: Determine Template Type\n\nAnalyze the user's request to determine the issue type:\n- If the user describes a problem, error, crash, or something not working -> Bug Report\n- If the user requests a new feature, enhancement, or additional support -> Feature Request\n- If the user is asking a question or needs help with something -> Questions & Discussion\n- If the user describes engineering work with no user-facing behavior change (a follow-up deferred from a pull request, technical debt, refactoring, tooling or CI work) -> Engineering Task\n- Otherwise -> Others\n\nEngineering Task is not a GitHub issue form and is not offered to regular users. Only select it when the request clearly describes internal engineering work.\n\n**If unclear**, ask the user which template to use. Do not default to \"Others\" on your own.\n\n#### Eligibility Check (Engineering Task only)\n\nEngineering Task is meant for maintainers and collaborators with write access. This is a request,\nnot an access control — nothing prevents anyone from calling `gh issue create` directly, and this\nskill does not try to. The check below is here so that a contributor without write access learns\nthat early and gets pointed somewhere more useful.\n\nBefore collecting any information, read the authenticated user's permission level:\n\n```bash\nrepo=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\nuser=\"$(gh api user --jq .login)\"\npermission=\"$(gh api \"repos/$repo/collaborators/$user/permission\" --jq .permission 2>/dev/null)\"\ncase \"$permission\" in\n admin | write) echo \"eligible\" ;;\n *) echo \"not eligible\" ;;\nesac\n```\n\nOnly `admin` and `write` are eligible (`maintain` reports as `write`). Always compare the returned\nvalue: on a public repository this endpoint answers `read` for any user, including one who is not a\ncollaborator at all, so a successful call proves nothing on its own. Do not use\n`repos/{owner}/{repo}/collaborators/{user}` here — it answers `204` for `read`- and `triage`-only\ncollaborators, who are not the intended audience for this template.\n\nIf the result is anything else, do not use this template. Explain that it is meant for maintainers\nwith write access, politely ask the contributor to use one of the public templates instead, and\noffer to help them file it there — their report is welcome, just not under this template. Do not\nquietly switch templates while keeping the Engineering Task labels or issue type.\n\n### Step 2: Read the Selected Template\n\n1. Read the corresponding template file from `.github/ISSUE_TEMPLATE/` directory.\n2. Identify required fields (`validations.required: true`), title prefix (`title`), labels (`labels`, if present), and issue type (`type`, if present).\n\nFor Engineering Task, read [references/engineering-task.md](references/engineering-task.md) instead — it lives outside `.github/ISSUE_TEMPLATE/` on purpose and carries its own title prefix, labels, issue type, and body structure.\n\n### Step 3: Collect Information\n\nBased on the selected template, ask the user for required information only. Follow the template's required fields and option constraints (for example, Platform and Priority choices).\n\n### Step 4: Build and Preview Issue Content\n\nCreate a temp file and write the issue content:\n- Use `issue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"`\n- Use the exact title prefix from the selected template.\n- Fill content following the template body structure and section order.\n- Apply labels exactly as defined by the template.\n- Keep all labels when there are multiple labels.\n- If template has no labels, do not add custom labels.\n- Apply the issue type exactly as defined by the template's `type` field.\n\nPreview the temp file content. **Show the file path** (e.g., `/tmp/gh-issue-body-XXXXXX.md`) and ask for confirmation before creating. **Skip this step if the user explicitly indicates no preview/confirmation is needed** (for example, automation workflows).\n\n### Step 5: Create Issue\n\nUse `gh issue create` command to create the issue.\n\nUse a unique temp file for the body:\n\n```bash\nissue_body_file=\"$(mktemp /tmp/gh-issue-body-XXXXXX).md\"\ncat > \"$issue_body_file\" <<'EOF'\n...issue body built from selected template...\nEOF\n```\n\nCreate the issue using values from the selected template:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\"\n```\n\nIf the selected template includes labels, append one `--label` per label:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --label \"<label_1_from_template>\" --label \"<label_2_from_template>\"\n```\n\nIf the selected template has no labels, do not pass `--label`.\n\nIf the selected template declares a `type`, pass it as well. `--body-file` does not carry the issue type over on its own, so omitting this leaves the issue untyped:\n\n```bash\ngh issue create --title \"<title_with_template_prefix>\" --body-file \"$issue_body_file\" --type \"<type_from_template>\"\n```\n\n`--template` and `--web` resolve against `.github/ISSUE_TEMPLATE/` on the default branch, so neither works for Engineering Task. Build the body locally for it.\n\nFor the other templates you may use `--template` as a starting point (use the exact template name from the repository):\n\n```bash\ngh issue create --template \"<template_name>\"\n```\n\nUse the `--web` flag to open the creation page in browser when complex formatting is needed:\n\n```bash\ngh issue create --web\n```\n\nClean up the temp file after creation:\n\n```bash\nrm -f \"$issue_body_file\"\n```\n\n## Notes\n\n- Must read template files under `.github/ISSUE_TEMPLATE/` (or `references/` for Engineering Task) to ensure following the correct format.\n- Treat template files as the only source of truth. Do not hardcode title prefixes, labels, or issue types in this skill.\n- Title must be clear and concise, avoid vague terms like \"a suggestion\" or \"stuck\".\n- Provide as much detail as possible to help developers understand and resolve the issue.\n- If user doesn't specify a template type, ask them to choose one first.\n\n<!-- File: .agents/skills/gh-create-pr/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/gh-create-pr/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-create-pr/agents/openai.yaml)\n\n<!-- File: .agents/skills/gh-create-pr/SKILL.md (Tokens: ~2414 | Category: anthropic-skill) -->\n---\nname: gh-create-pr\ndescription: Create or update GitHub pull requests using the repository-required workflow and template compliance. Use when asked to create/open/update a PR so the assistant reads `.github/pull_request_template.md`, fills every template section, preserves markdown structure exactly, and marks missing data as N/A or None instead of skipping sections.\n---\n\n# GitHub PR Creation\n\n## Stack tooling\n\nThis repository ships `.agents/skills/gh-stack/SKILL.md` as a public project skill; developers do not install the agent skill separately. Read it before operating on stacked branches or PRs. Agents that consume `.agents/skills/` discover it directly. If a Claude checkout is missing `.claude/skills/gh-stack`, run `pnpm skills:sync` followed by `pnpm skills:check`; do not download a separate global copy.\n\nBefore the first `gh stack` command in a task, verify the GitHub CLI and install the official extension if it is missing:\n\n```bash\ncommand -v gh >/dev/null 2>&1 || {\n echo \"GitHub CLI is required: https://cli.github.com/\" >&2\n exit 1\n}\ngh auth status\nif ! gh stack --help >/dev/null 2>&1; then\n gh extension install github/gh-stack\nfi\ngh stack --help >/dev/null\n```\n\nStop if authentication, installation, or the final verification fails. Do not infer a stack with ad hoc Git commands. For human-authored Cherry PRs, use `gh stack push`, create each compliant PR through this skill from bottom to top, then link the existing PRs with `gh stack link`; `gh stack submit --auto` creates PRs outside the template-compliant body flow and must not bypass this workflow.\n\n## Workflow\n\n1. Read `.github/pull_request_template.md` before drafting the PR body.\n2. Collect PR context from the current branch (base/head, scope, linked issues, testing status, breaking changes, release note content). Resolve the live base and run `pnpm change:scope --base <verified-base-ref>`; do not infer scope from the latest commit alone.\n3. Read `.agents/notes/README.md` and classify the change:\n - Fill `Agent Note` with the repository path, or `N/A — <reason>` for a local/mechanical change.\n - For a Spec PR, fill `Spec PR: This PR` and list every AC.\n - For an implementation layer, link the Spec PR and list only the AC IDs covered by this layer. Verify an `APPROVED` review whose `commit_id` equals the current Spec head; a stale approval does not authorize implementation.\n - For a direct bug fix with durable rationale, link its implemented `bug-fix` note and use `Spec PR: N/A`.\n - Automation-authored PRs (repository workflows and Dependabot) are exempt from these metadata fields. Do not make their bodies imitate a human-authored PR.\n4. For an implementation PR, complete the stack tooling preflight, then run `gh stack view --json`. If it exits 2, follow the `gh-stack` skill's remote-discovery procedure; missing local metadata does not prove the PR is standalone. Inspect every downstack implementation PR and aggregate only ACs backed by actual verification. Keep the note proposed on intermediate layers. If the current PR is the final layer and cumulative evidence covers the complete approved Spec, move the bilingual triplet to `implemented/` and run `pnpm agent-notes:check-transition --base <verified-spec-ref>` before publishing.\n5. Fill `Verification` with commands and scenarios actually run. Never present a planned, pending, skipped, or CI-only check as passed.\n6. Check if the current branch has been pushed to remote. If not, push it first:\n - Default remote is `origin`, but ask the user if they want to use a different remote.\n ```bash\n git push -u <remote> <head-branch>\n ```\n7. Determine the base branch:\n - Inspect the head branch before applying any default. If the head is `release/v<version>`, stop: never open a pull request from a release branch, especially not to `main`. Put an isolated fix on a topic branch and target the release branch, or let Post Release create the metadata sync branch.\n - Before defaulting an arbitrary topic branch to `main`, inspect its merge base and upstream. A product-code fix that started from `release/v<version>` must stop and be recreated from `main` as a hotfix; only a release-only repair or explicit backport recovery topic may target that exact release branch.\n - A `backport/v<version>/pr-<number>` head must target the matching `release/v<version>` base and its body must contain `<!-- release-backport-source-pr: <number> -->` on its own line for the exact source hotfix PR. A `release-sync/v<version>` head must target `main`, use the exact title `chore(release): sync v<version> metadata`, retain the `release-metadata-boundary: v<version>` body marker, and be squash-merged.\n - For official repo(CherryHQ/cherry-studio) as `origin`: default base is `main` from `origin`, but allow the user to explicitly indicate a base branch.\n - `main` is the active development line, including hotfix PRs. Do not target an old maintenance branch unless the user explicitly requests it.\n - Only classify a PR as a release hotfix when the user explicitly says it must be included in the active draft release. Use the title `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` with a lowercase alphanumeric kebab-case scope, exactly one space after the colon, and a non-empty description. The title grammar synchronizes the `hotfix` label automatically. Merging opens a separate backport PR only when exactly one draft semantic-version release has a matching active `release/v<version>` branch; otherwise automation stops without guessing a target.\n - If the hotfix is user-facing, provide one release-note line in each language so automation can update the active draft and stable release history. Put this exact structure inside the template's existing `release-note` fence; do not include bullet prefixes:\n ```text\n <!--LANG:en-->\n [Component] English description.\n <!--LANG:zh-CN-->\n [组件] 中文说明。\n <!--LANG:END-->\n ```\n - If the hotfix has no user-facing release note, keep `NONE` in the template's `release-note` fence. The code is still backported, but release metadata is unchanged. A provided bilingual block must satisfy the exact structure above.\n - For fork repo as `origin`: check available remotes with `git remote -v`, default base may be `upstream/main` or another remote. Always assume that user wants to merge head to CherryHQ/cherry-studio/main, unless the user explicitly indicates a base branch.\n - Ask the user to confirm the base branch if it's not the default.\n8. Create a temp file and write the PR body using a single Bash heredoc\n (avoids `mktemp` + `Write` tool path-mismatch on Windows):\n ```bash\n pr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\n cat > \"$pr_body_file\" <<'EOF'\n ...filled template body...\n EOF\n ```\n Fill content using the template structure exactly (keep section order,\n headings, checkbox formatting). If not applicable, write `N/A` or `None`.\n9. Inspect the temp file content via Bash `cat \"$pr_body_file\"` (the `Read`\n tool can fail on `/tmp/...` paths on Windows). If the user requests a preview\n or confirmation, show the full body and follow that request; otherwise,\n proceed with the authorized PR creation.\n10. Create the PR, adding `--draft` when the user requests a draft:\n ```bash\n gh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\n ```\n For a release hotfix, use an exact classifier-compatible title so the workflow synchronizes the label and separately validates any provided bilingual note:\n ```bash\n gh pr create --base main --head <head> --title \"hotfix: <description>\" --body-file \"$pr_body_file\"\n ```\n After creation, verify that the classifier added `hotfix`; if it did not, fix the title instead of adding the label manually. Also fix any malformed optional release-note block reported by the workflow.\n11. Clean up the temp file: `rm -f \"$pr_body_file\"`\n12. Report the created PR URL and summarize title/base/head, Agent Note/Spec, AC coverage, actual verification, and any required follow-up.\n\n## Constraints\n\n- Never skip template sections.\n- Never rewrite the template format.\n- Keep content concise and specific to the current change set.\n- PR title and body must be written in English.\n- Never use a `hotfix` title or label for an ordinary bug fix. It opts the PR into an automatic backport PR after merge when one matching draft release is active.\n- A release hotfix may use `NONE` when it has no user-facing release note. Never provide a partial, single-language, or otherwise malformed bilingual note; the backport workflow fails closed on malformed content.\n- Never default a `release/v<version>` head to `main`; a release branch is not a pull request source branch.\n- Never publish an implementation PR as ready when its current Spec head lacks an exact-head Approval. A Spec may remain unmerged and serve as the stack base.\n- Every human-authored PR fills `Agent Note`, `Spec PR`, and `Acceptance criteria`; `N/A` requires a concise reason. Automation-authored PRs (repository workflows and Dependabot) are exempt from this metadata requirement.\n- **Release note & Documentation checkbox** — both are driven by whether the change is **user-facing**. Use the table below:\n\n | Change type | Release note | Docs `[x]` |\n |---|---|---|\n | New user-facing feature / setting / UI | Describe the change | ✅ |\n | Bug fix visible to users | Describe the fix | ✅ if behavior changed |\n | Behavior change / default value change | Describe + `action required` | ✅ |\n | Security fix in a user-facing dependency | Describe the fix | ✅ if usage changed |\n | CI / GitHub Actions changes | `NONE` | ❌ |\n | Internal refactoring (user cannot tell) | `NONE` | ❌ |\n | Dev / build tooling changes | `NONE` | ❌ |\n | Dev-only dependency bump | `NONE` | ❌ |\n | Test-only / code style changes | `NONE` | ❌ |\n\n## Command Pattern\n\n```bash\n# read template\ncat .github/pull_request_template.md\n\n# prepare and inspect the PR body\npr_body_file=\"/tmp/gh-pr-body-$(date +%s).md\"\ncat > \"$pr_body_file\" <<'EOF'\n...filled template body...\nEOF\ncat \"$pr_body_file\"\n\n# create the authorized PR; add --draft when requested\ngh pr create --base <base> --head <head> --title \"<title>\" --body-file \"$pr_body_file\"\nrm -f \"$pr_body_file\"\n```\n\n<!-- File: .agents/skills/gh-pr-review/agents/openai.yaml (Tokens: ~300 | Category: anthropic-skill) -->\n# Agents Skill\n\nPath: `.agents/skills/gh-pr-review/agents/openai.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/agents/openai.yaml)\n\n<!-- File: .agents/skills/gh-pr-review/references/checklist-evolution.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/checklist-evolution.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/checklist-evolution.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/code-checklist.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/code-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/code-checklist.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/diagnosis.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/diagnosis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/diagnosis.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/doc-checklist.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/doc-checklist.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/doc-checklist.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/judgment-matrix.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/judgment-matrix.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/judgment-matrix.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/local-review.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/local-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/local-review.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/pr-review.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/pr-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/pr-review.md)\n\n<!-- File: .agents/skills/gh-pr-review/references/teams-review.md (Tokens: ~300 | Category: anthropic-skill) -->\n# References Skill\n\nPath: `.agents/skills/gh-pr-review/references/teams-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/gh-pr-review/references/teams-review.md)\n\n<!-- File: .agents/skills/gh-pr-review/SKILL.md (Tokens: ~3492 | Category: anthropic-skill) -->\n---\nname: gh-pr-review\ndescription: Automated Cherry Studio review for local branches, PRs, commits, files, architecture docs, and repository skills. Use for code or documentation reviews that need project-specific naming, main/renderer/shared placement and dependency rules, IpcApi and DataApi boundaries, lifecycle/service ownership, renderer hooks, React/UI conventions, and tests. Review depth adapts to diff size and runtime subagent capability (single-agent or multi-agent reviewer-verifier). Report-only by default; code fixes and GitHub submission each require explicit invocation-time authorization (`fix` / `submit`). Normal-review prompts and safe interruption behavior follow the interaction contract below. To diagnose gaps in the skill after a review session, run `/gh-pr-review diag`.\n---\n\n<!-- Based on https://github.com/Tencent/tgfx/tree/main/.codebuddy/skills/cr -->\n<!-- Adapted for agent runtimes and the Cherry Studio tech stack -->\n\n# /gh-pr-review — Code Review\n\nAutomated code review for local branches, PRs, commits, and files. Detects\nthe review target from arguments, then picks the review engine from diff size\nand runtime capability. Small diffs use single-agent review\n(`references/local-review.md`). Large diffs use the multi-agent\nreviewer–verifier flow (`references/teams-review.md`) only when independent\nsubagents are available; otherwise they fall back to single-agent review with\nthat limitation disclosed. PR targets add worktree setup and GitHub submission\n(`references/pr-review.md`) around the same engine-selection contract.\n\nCherry Studio-specific review rules live in\n`references/cherry-review-guidance.md`. Target review flows must load that file\nfor code, mixed, architecture-doc, and project-skill reviews so reviewers can\napply DataApi, service-boundary, renderer hook, React, UI, and type-contract\nchecks without relying on memory. That reference also defines which internal\ndocs, internal skills, external skills, and official websites to consult for\neach changed area; load only the relevant subset.\n\nAll user-facing text matches the user's language.\n\n## Interaction and interruption contract\n\nApart from the declared categories below, normal review is prompt-free: never\nask for mode selection, fix confirmation, finding selection, or submission\npreview. A leaf flow may request input only when it explicitly declares one of\nthese categories:\n\n- **Product decision** — in an interactive session, the Product Demand gate may\n ask the current user for a decision the review cannot derive. In an automated\n session, record the impact and open decision without deciding for the user.\n- **Safety or environment blocker** — continuing would require destructive\n action, new authority, or missing external configuration. Declared examples\n are a dirty/mismatched review worktree, a missing canonical remote, cleanup\n of unexplained changes, removal of a failed fix patch, and a pending review\n draft holding comments this run did not confirm. In an interactive session,\n preserve state and ask only for the decision needed to proceed.\n- **Explicit maintenance mode** — `diag` and separately requested checklist\n maintenance are interactive selection flows outside normal review. They may\n ask for the declared edit selection or persistent checkout/branch target.\n\nAn automated session never waits for user input. At a product decision it\ncontinues record-only as specified below. At a safety/environment blocker it\npreserves state, stops the affected flow safely, and reports the exact blocker\nand required decision. In an explicit maintenance mode it reports candidates\nor missing destination information, applies no selection-dependent edits, and\nstops safely. No leaf flow may introduce another prompt category.\n\n## Review Stages\n\nEvery review runs these stages in order. A later stage reviews only what\nsurvived the earlier ones, so a stage never re-litigates an earlier verdict.\n\nThis table is the single source of truth for stage scope and references; a\nleaf flow may not widen, narrow, or re-reference a stage.\n\n| # | Stage | Applies to | Reference |\n|---|-------|-----------|-----------|\n| 1 | **Product Demand** (gate) | any change whose semantics affect the product | below |\n| 2 | **Consumer** | any change that adds or expands shared surface | `references/consumer-review.md` |\n| 3 | **Architecture-First** | code, mixed, Cherry architecture docs, project skills | `references/cherry-review-guidance.md` |\n| 4 | **Implementation** | code, mixed | `references/code-checklist.md` (A/B) |\n| 4 | **Implementation** | docs | `references/doc-checklist.md` (A/B) |\n| 5 | **Style / conventions** | code, mixed | `references/code-checklist.md` (C) |\n| 5 | **Style / conventions** | docs | `references/doc-checklist.md` (C) |\n\nStage applicability follows the changed content, not the commit label: a\ndocumentation-only diff still runs stages 3–5 when it changes Cherry\narchitecture docs or project skills, and a code diff that also edits docs runs\nboth reference sets for stages 4–5.\n\n### Stage 1: Product Demand gate\n\nFirst inspect the semantics actually expressed or constrained by the change,\nthen decide whether it affects **product semantics, user-visible behavior, or\nproduct direction**. Change labels are not sufficient evidence: internal\nrefactors and non-user-facing fixes often have no product impact, while\nuser-facing fixes, docs, tests, or tooling can record, lock, or alter product\nbehavior.\n\nWhen there is product impact, determine whether the direction is already\nestablished in the current review context. Treat it as established only when\nthe current user explicitly decided it or an authoritative project artifact\nexplicitly records the accepted behavior and its approval by the responsible\nproject authority, such as a specification, an ADR, or an issue containing a\nmaintainer decision that settles the expected behavior. Do not infer acceptance\nfrom issue state, labels, milestone, assignment, or a link from the PR. A change\nlabel, PR body, implementation, or test demonstrates author intent or current\nbehavior but does not establish product approval on its own.\n\nClassify the gate into exactly one state:\n\n- **No product impact**: skip this stage entirely in both interactive and\n automated runs; say nothing about the skipped gate.\n- **Established direction**: compare the change with the recorded decision. If\n it aligns, continue without asking for another product decision. If it\n conflicts, report the product-direction mismatch and **stop the whole review\n immediately** — do not run Consumer, Architecture, Implementation, or Style\n stages, and do not report code findings. Applying an existing decision is\n not making a new one.\n- **Open product decision**:\n - **Interactive session (default)**: summarize the change's effect on\n product functionality and semantics, and ask the current user for the\n unresolved product decision. Do not infer automation from PR authorship,\n review ownership, or whether the user authored the change. If the user\n rejects the direction, stop the whole review as above; if the user\n approves it, continue with the remaining stages.\n - **Automated session (explicit only)**: use this mode only when the\n invocation prompt or workflow context explicitly identifies a headless,\n CI, batch, or other automated run. Make no product decision on the user's\n behalf. Run the remaining stages, and in the final report summarize the\n product impact, the direction the change takes, and the points needing\n human confirmation. Never phrase this as product approval having been\n obtained.\n\n## Authority model\n\nA review request authorizes analysis and reporting only. The review target,\nreview depth, and reviewer–verifier confidence never grant execution\nauthority; authority is granted explicitly at invocation time, and execution\nis prompt-free only after it has been granted:\n\n- **Report-only (default)**: every review, any target — findings are reported\n with fix guidance. No working-tree edits, no GitHub writes.\n- **Fix (explicit)**: granted only by the invocation — `fix` in `$ARGUMENTS`\n or equivalent explicit user wording (\"review and fix …\"). Local targets\n only. What each risk level then permits is owned by\n `references/judgment-matrix.md` § Handling by Risk Level; this section grants\n the authority and never restates the mapping.\n Applying fixes makes the session a coding task, so it must end with the\n validation selected per § Validation after applied fixes below.\n- **Submit (explicit)**: granted only by the invocation — `submit` in\n `$ARGUMENTS` or equivalent explicit user wording. PR flows then submit all\n confirmed findings without per-comment prompts. Approving or merging always\n requires its own explicit request.\n\n## Validation after applied fixes\n\nNever run local lint, test, or format during a review that edited nothing.\nWhen fixes were applied, select the validation matching the changed surface,\nfollowing `AGENTS.md` § Operational Rules (\"Check what you changed, not the\nwhole repo\"), and report the results:\n\n- Docs/markdown-only fixes — including this skill's own files — run\n `pnpm docs:check`.\n- Code fixes run `pnpm lint` (which already ends with `pnpm format`, so never\n invoke `format` again) plus the tests covering the change: a per-project\n wrapper such as `pnpm test:main <file>` or `pnpm exec vitest run <file>`.\n Never `pnpm test <path>` — that script chains several vitest invocations and\n the path reaches only the last one.\n- Reserve the full `pnpm test` for a broad change whose affected tests cannot\n be named, and use `pnpm test:lint` when the CI-equivalent lint gate matters\n (`pnpm lint` tolerates oxlint warnings that CI denies).\n\n## Route\n\nFirst strip authority modifiers from `$ARGUMENTS` (equivalent explicit user\nwording in the conversation counts the same; both default to `false`). Call\nthe remainder `REVIEW_TARGET` — every rule below, and every leaf flow, reads\n`REVIEW_TARGET`, never the raw `$ARGUMENTS`:\n\n- `fix` → `AUTHORIZED_FIX = true` (meaningful for local targets)\n- `submit` → `AUTHORIZED_SUBMIT = true` (meaningful for PR targets)\n\nBefore choosing a review engine, inspect the runtime's exposed coordination\ncapabilities. Set `HAS_SUBAGENTS = true` only when it can launch an independent\nreviewer and a fresh independent verifier. Parallel execution is not required;\nsequential subagents still satisfy the isolation contract.\n\n### Rules\n\nMatch the **first** applicable rule top-to-bottom:\n\n1. `REVIEW_TARGET` is `diag` → `references/diagnosis.md`.\n2. `REVIEW_TARGET` is `checklist`, or the user explicitly asks to adopt the\n proposed checklist candidates → `references/checklist-evolution.md`,\n entering at its Step 2. Maintenance runs only in the session that produced\n the candidates; it reviews nothing.\n3. `REVIEW_TARGET` is a PR number or URL containing `/pull/` →\n `references/pr-review.md` (pass `AUTHORIZED_SUBMIT` and `HAS_SUBAGENTS`;\n the wrapper collects the exact PR scope before selecting the engine).\n4. Everything else: derive the scope and `SMALL_SCOPE` per § Scope derivation\n below, then select the engine.\n - `SMALL_SCOPE = true` → `references/local-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = true` →\n `references/teams-review.md`.\n - `SMALL_SCOPE = false` with `HAS_SUBAGENTS = false` →\n `references/local-review.md`; pass `LIMITED_SINGLE_AGENT = true` so the\n report explicitly states that a large diff received single-agent review\n without independent adversarial verification.\n - Pass `AUTHORIZED_FIX` (commit and range targets are immutable history —\n always report-only regardless of the flag).\n\nEach `→` means: `Read` the target file and follow it as the sole remaining\ninstruction for how to obtain diffs, apply fixes, and submit results. Do NOT\nreview from memory or habit. The skill-wide sections — § Review Stages,\n§ Authority model, § Validation after applied fixes, and § Scope derivation —\nstay binding; the leaf flows reference them by name.\n\nNever ask the user anything to route. Pass `REVIEW_TARGET`, the resolved\nscope, `SMALL_SCOPE`, and the authority flags to the target file.\n\n### Scope derivation\n\nReached only from Rule 4 above; `diag` and `checklist` targets never enter this\nsubsection. It is the **sole owner** of how a review scope and its size are\nderived — leaf flows reference it and never restate it.\n\nResolve `REVIEW_TARGET` into the review scope:\n\n| `REVIEW_TARGET` | Scope |\n|---|---|\n| empty, uncommitted changes exist | uncommitted changes only — `git diff HEAD` (staged + unstaged tracked files), plus untracked (`??`) files from `git status --porcelain`, reviewed as new code |\n| empty, clean tree | branch diff against the base: `git merge-base origin/{main\\|master} HEAD`, then `git diff <merge-base-sha>`, plus untracked files |\n| commit hash | validate with `git rev-parse --verify`, then `git show` |\n| commit range (`A..B` / `A...B`) | validate both endpoints, then `git diff A~1..B` |\n| file/directory paths | verify each path exists, then the full contents of the resolved files |\n| PR number or `/pull/` URL | the PR's merge-base diff, collected by `references/pr-review.md` |\n\nThe **resolved review scope**, not a diff, decides whether there is work: for a\npath target it is the set of files resolved from the given paths; for every\nother target it is the diff. A clean tree does not make a path target empty.\nIf the resolved scope is empty, show the usage examples below and exit.\n\nThen measure what the leaf flow will actually read — a diff for diff-shaped\ntargets, full file text for path targets:\n\n- **Diff-shaped targets** (uncommitted changes, branch/merge-base diff, a\n commit, a commit range, a PR): `CHANGED_LINES` is the sum of numeric\n additions and deletions from `git diff --numstat` for the complete review\n scope, and `CHANGED_FILES` is the number of unique changed paths in it.\n- **File/directory path targets**: the leaf flow reviews full contents, so\n measure full contents — `CHANGED_FILES` is the number of files resolved\n from the given paths (directories expand recursively, excluding ignored\n paths), and `CHANGED_LINES` is the total line count of those files. A\n clean tree never makes a path target small by default.\n- **Untracked text files** in a diff-shaped scope count as one file each with\n their full line count as additions.\n- Generated files count normally in both totals; do not exclude them because\n they are generated.\n- Any binary file — a binary diff (`-`/`-` in `--numstat`), an untracked\n binary, or a binary resolved from a path target — counts as a file and makes\n the scope non-small, because its line size is unknown.\n\nSet `SMALL_SCOPE = true` only when `CHANGED_LINES <= 1000`,\n`CHANGED_FILES <= 20`, and the scope contains no binary file. Both numeric\nconditions must hold. `SMALL_SCOPE` is the name every flow uses for this\nresult.\n\n### Usage examples\n\nPrint this list when the resolved scope is empty:\n\n```\n/gh-pr-review review uncommitted changes, else the branch diff\n/gh-pr-review a1b2c3d review a commit\n/gh-pr-review a1b2c3d..e4f5g6h review a commit range\n/gh-pr-review src/foo.ts review files or directories\n/gh-pr-review 123 review a PR (also accepts a /pull/ URL)\n/gh-pr-review <target> fix also apply low-risk fixes (local targets)\n/gh-pr-review <pr> submit also publish the review to GitHub\n/gh-pr-review checklist adopt this session's proposed checklist items\n/gh-pr-review diag diagnose gaps in this skill\n```\n\n<!-- File: .agents/skills/prepare-release/SKILL.md (Tokens: ~4065 | Category: anthropic-skill) -->\n---\nname: prepare-release\ndescription: Prepare a new release by collecting commits, generating bilingual release notes, updating version files, and creating a release branch. Use when asked to prepare/create a release, bump version, or run `/prepare-release`.\n---\n\n# Prepare Release\n\nAutomate the Cherry Studio release workflow: collect changes → generate bilingual release notes → update files → create release branch → trigger CI/CD.\n\n## Arguments\n\nParse the version intent from the user's message. Accept any of these forms:\n- Bump type keyword: `patch`, `minor`, `major`\n- Exact version: strict `x.y.z` or `x.y.z-<prerelease>` without build metadata (e.g. `1.8.0`, `1.8.0-beta.1`, `1.8.0-rc.1`)\n- Natural language: \"prepare a beta release\", \"bump to 1.8.0-rc.2\", etc.\n\nDefaults to `patch` if no version is specified. Always echo the resolved target version back to the user before proceeding with any file edits.\n\n- `--dry-run`: Preview only, do not create a release branch.\n\n## Workflow\n\n### Step 1: Determine Version\n\n1. For an interactive local run, fetch `origin/main` and all tags, then verify that the checkout is a clean `main` at exactly `origin/main`:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test -z \"$(git status --porcelain)\"\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n ```\n Stop before editing files if any check fails. This prevents a standalone run from creating a release branch from an arbitrary or stale checkout.\n In GitHub Actions, use the workflow's frozen dispatch SHA and leave checkout validation to the workflow. Do not fetch or compare the later `origin/main` head.\n2. Read the current version from `package.json`. Use it for version increments even if that release has since been withdrawn; never reuse the withdrawn version.\n3. Select the latest published, non-draft GitHub Release whose tag is strict `v<semver>` as the release-note baseline. Non-semver preview releases and drafts are never a baseline:\n ```bash\n gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty'\n ```\n Stop if no published baseline exists or its Git tag is missing (`git rev-parse --verify refs/tags/{baseline-tag}`). Compare its version with the current package version using `semver`: if main is behind, stop and require the latest Post Release metadata PR to be merged. If main is ahead, allow preparation using the published baseline for release notes and the package version for version increments. For example, after withdrawing 2.1.1, main at 2.1.1 with a published baseline of 2.1.0 prepares 2.1.2 and includes changes since 2.1.0.\n In GitHub Actions, use the workflow-provided baseline tag and collection base without repeating these checks.\n4. Compute the new version based on the argument:\n - `patch` / `minor` / `major`: bump from the current version.\n - An exact version must match `^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\.[0-9A-Za-z-]+)*)?$` and pass `semver.valid`; build metadata such as `+build.1` is not accepted.\n - In both cases, require the result to be strictly greater than the current version according to semver precedence. Reject equal versions and downgrades.\n\n### Step 2: Collect Commits\n\n1. Determine the release-note collection base from the published baseline selected in Step 1, not from the package version:\n - If the baseline tag is an ancestor of `HEAD`, use the tag.\n - Otherwise, use the latest commit whose full message contains the exact marker `release-metadata-boundary: <baseline-tag>`. This machine marker is added to the Post Release pull request body and survives the required squash merge.\n - For metadata pull requests created before the machine marker existed, accept a subject exactly equal to `chore(release): sync <baseline-tag> metadata` or that subject followed only by GitHub's squash suffix ` (#<PR-number>)`.\n - Stop with an error if the tag is not an ancestor and its metadata sync commit is missing; otherwise already-released hotfixes could be included again.\n2. List all commits since that base:\n ```bash\n git log <collection-base>..HEAD --format=\"%H %s\" --no-merges\n ```\n3. For each commit, get the full body:\n ```bash\n git log <hash> -1 --format=\"%B\"\n ```\n4. Extract the content inside `` ```release-note `` code blocks from each commit body.\n5. Extract the conventional commit type from the title (`feat`, `fix`, `refactor`, `perf`, `docs`, etc.).\n6. **Skip** these commits as standalone release-note candidates, but still inspect their effects when reconciling candidates with the final code in Step 3:\n - Titles starting with `🤖 Daily Auto I18N`\n - Titles starting with `Merge`\n - Titles starting with `chore(deps)`\n - Titles starting with `chore: release`\n - Titles starting with `chore(release)`\n - Commits where the release-note block says `NONE`\n\n### Step 3: Generate Bilingual Release Notes\n\nGenerate release notes in **both English and Chinese** from the final user-visible changes relative to the published baseline. Commit titles and `release-note` blocks are candidate descriptions, not proof that a change will ship.\n\n**Reconcile net changes before drafting:**\n\n1. Inspect `git diff --name-status <baseline-tag> <release-head>`, then read the relevant patches and code at both endpoints. `<release-head>` is the source `HEAD` before release preparation (the frozen dispatch SHA in CI). Compare the two endpoint trees, not a three-dot merge-base diff. The collection base is only for discovering commits; when it differs from the published tag, also inspect user-visible differences missing from that commit range.\n2. Group candidates by user-visible behavior and trace related patches in chronological order, including commits excluded in Step 2. Detect explicit reverts, manual undoing, replacements, partial reversals, and reintroductions from the code; do not rely on commit wording or matching hashes alone.\n3. Omit a change introduced and fully undone during this cycle, including fixes that only addressed that temporary change. For partial reversals, replacements, or reintroductions, describe only the final outcome that differs from the published baseline, once per distinct user-visible change.\n4. If a reversal removes or changes behavior that already existed in the published baseline, describe the resulting user-visible removal or restoration. Do not discard all revert commits indiscriminately. An implementation rewrite that preserves the same user-visible behavior does not by itself justify a release-note entry.\n5. Verify each proposed item against the endpoint diff and final code, and ensure the English and Chinese versions describe the same outcome. If the claimed effect cannot be substantiated, omit it and report the uncertainty in the preparation summary rather than inventing a release-note claim.\n\n**Recommended format:**\n\n```\n<!--LANG:en-->\nCherry Studio {version} - {Brief English Title}\n\n✨ New Features\n- [Component] Description\n\n🐛 Bug Fixes\n- [Component] Description\n\n💄 Improvements\n- [Component] Description\n\n⚡ Performance\n- [Component] Description\n\n<!--LANG:zh-CN-->\nCherry Studio {version} - {简短中文标题}\n\n✨ 新功能\n- [组件] 描述\n\n🐛 问题修复\n- [组件] 描述\n\n💄 改进\n- [组件] 描述\n\n⚡ 性能优化\n- [组件] 描述\n<!--LANG:END-->\n```\n\nThe language markers are the machine-readable contract: include each marker once, keep them in order, and provide non-empty English and Chinese sections. Titles and surrounding explanatory text are presentation choices, not validation requirements.\n\n**Rules:**\n- Only include categories that have entries (omit empty categories).\n- Each distinct surviving user-visible change appears once in the appropriate category; combine related commits and omit canceled or superseded claims.\n- Prefer wording from the `release-note` field, or otherwise the commit title, only when it matches the verified final outcome.\n- Component tags should be short: `[Chat]`, `[Models]`, `[Agent]`, `[MCP]`, `[Settings]`, `[Data]`, `[Build]`, etc.\n- Chinese translations should be natural, not machine-literal.\n- Do NOT include commit hashes or PR numbers.\n- Read the **existing** release notes in `electron-builder.yml` as a style reference before writing.\n\n**IMPORTANT: User-Focused Content Only**\n\nRelease notes are for **end users**, not developers. Exclude anything users don't care about:\n\n- **EXCLUDE** internal refactoring, code cleanup, or architecture changes\n- **EXCLUDE** CI/CD, build tooling, or test infrastructure changes\n- **EXCLUDE** dependency updates (unless they add user-visible features)\n- **EXCLUDE** documentation updates\n- **EXCLUDE** developer experience improvements\n- **EXCLUDE** technical debt fixes with no user-visible impact\n- **EXCLUDE** overly technical descriptions (e.g., \"fix race condition in Redux middleware\")\n\n**INCLUDE** only changes that users will notice:\n- New features they can use\n- Bug fixes that affected their workflow\n- UI/UX improvements they can see\n- Performance improvements they can feel\n- Security fixes (simplified, without implementation details)\n\n**Keep descriptions simple and non-technical:**\n- ❌ \"Fix streaming race condition causing partial tool response status in Redux state\"\n- ✅ \"Fix tool status not stopping when aborting\"\n- ❌ \"Auto-convert reasoning_effort to reasoningEffort for OpenAI-compatible providers\"\n- ✅ \"Fix deep thinking mode not working with some providers\"\n\n### Step 4: Update Files\n\n1. **`package.json`**: Update the `\"version\"` field to the new version.\n2. **`electron-builder.yml`**: Replace the content under `releaseInfo.releaseNotes: |` with the generated notes. Preserve the 4-space YAML indentation for the block scalar content.\n3. **`resources/cherry-studio/release-history.json`**: Never edit by hand; the notes must match `electron-builder.yml` byte for byte. Run `node scripts/release/sync-release-history.js --target-version {version}`, which prepends (or replaces) the entry for a stable release and leaves the file untouched for a prerelease. In GitHub Actions, the workflow runs this itself after the Claude step.\n4. **Validate source metadata**: For an interactive local run, run `node scripts/release/validate-prepared-release.js --target-version {version}` before generating the product manifest, and stop if it rejects the changed paths, version ordering, bilingual sections, or stable history. In GitHub Actions, leave validation to the workflow step that runs after Claude.\n5. **Built-in knowledge**: For an interactive local run, run `pnpm build:builtin-knowledge` after validation. This refreshes `resources/builtin-agents/cherry-assistant/product-manifest.json` with the new package version. Never edit the generated manifest by hand. In GitHub Actions, do not run the generator: the workflow runs the same validator first, then runs the trusted generator itself.\n\n### Step 5: Present for Review\n\nShow the user:\n- The new version number.\n- The full generated release notes.\n- A summary of which files were modified.\n\nIf `--dry-run` was specified, stop here.\n\nOtherwise, ask the user to confirm before proceeding to Step 6.\n\n### Step 6: Create Release Branch\n\n1. For an interactive local run, repeat Step 1 items 1-3 immediately before creating the branch, reading the original package version from `HEAD:package.json`. Require the published baseline to still match the one used to collect release notes; otherwise regenerate the notes before proceeding. Because Step 4 has intentionally prepared and validated release metadata, replace Step 1's clean-worktree assertion with `git status --short` and stop unless every listed path is one of the four allowed release metadata files. Then create and push a signed, DCO-compliant release commit:\n ```bash\n git fetch origin refs/heads/main:refs/remotes/origin/main --tags\n test \"$(git branch --show-current)\" = main\n test \"$(git rev-parse HEAD)\" = \"$(git rev-parse origin/main)\"\n test \"$(node -p \"require('./package.json').version\")\" = \"{version}\"\n CURRENT_VERSION=\"$(git show HEAD:package.json | jq -r .version)\"\n LATEST_PUBLISHED=\"$(gh release list --limit 1000 --json isDraft,publishedAt,tagName --jq '[.[] | select(.isDraft == false and (.tagName | test(\"^v(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)\\\\.(0|[1-9][0-9]*)(-[0-9A-Za-z-]+(\\\\.[0-9A-Za-z-]+)*)?$\")))] | sort_by(.publishedAt) | last | .tagName // empty')\"\n test \"$LATEST_PUBLISHED\" = \"{baseline-tag}\"\n git rev-parse --verify \"refs/tags/$LATEST_PUBLISHED\"\n node -e \"const semver = require('semver'); process.exit(semver.gte(process.argv[1], process.argv[2]) ? 0 : 1)\" \"$CURRENT_VERSION\" \"${LATEST_PUBLISHED#v}\"\n REPO=\"$(gh repo view --json nameWithOwner --jq .nameWithOwner)\"\n gh api --paginate --slurp \"repos/$REPO/releases?per_page=100\" | TAG=\"v{version}\" node scripts/release/validate-release-state.js prepare\n test -z \"$(git ls-remote --heads origin refs/heads/release/v{version})\"\n git status --short\n UNEXPECTED_RELEASE_PATHS=\"$(git status --porcelain | cut -c4- | grep -Ev '^(package\\.json|electron-builder\\.yml|resources/cherry-studio/release-history\\.json|resources/builtin-agents/cherry-assistant/product-manifest\\.json)$' || true)\"\n test -z \"$UNEXPECTED_RELEASE_PATHS\"\n git checkout -b release/v{version}\n git add package.json electron-builder.yml resources/cherry-studio/release-history.json resources/builtin-agents/cherry-assistant/product-manifest.json\n git commit -S --signoff -m \"chore(release): prepare v{version}\"\n git cat-file commit HEAD | grep -q '^gpgsig '\n git log -1 --format=%B | grep -q '^Signed-off-by: '\n git push -u origin release/v{version}\n ```\n2. In GitHub Actions, stop after updating `package.json` and `electron-builder.yml`. Temporary helper files and local Git operations are allowed; the workflow extracts those two file changes, restores the frozen source SHA, and discards everything else. It then derives the release history, validates, generates the product manifest, creates the branch, and uses GitHub's API to create and verify the signed, DCO-compliant commit. Never push from the Claude step.\n3. Report the release branch and next steps. Do not create a PR yet: the release must be built and published from this branch first.\n\n## CI Trigger Chain\n\n- Wait for the **CI** push run on the new `release/v{version}` commit to succeed. **`auto-release-build.yml`** revalidates that exact live branch head and dispatches **`release.yml`** with `all`; it builds macOS, Windows, and Linux and creates or updates the draft GitHub Release. Use **`release.yml`** manually only to retry a failed all-platform build or one platform for the unchanged tagged commit.\n- While a single draft semantic-version release is active, **`backport-release-fixes.yml`** opens a backport PR for the first merged `hotfix: <description>` or `hotfix(<kebab-case-scope>): <description>` PR from `main`, applies any optional bilingual release note, then appends consecutive hotfixes and source markers to that same open topic branch. It manages every source PR's `hotfix` and backport-status labels and reports failures on the source PR; never merge `main` into the release branch.\n- Review the backport PR, wait for its CI, and merge it. After the resulting release-branch push passes CI, the exact-head all-platform draft rebuild starts automatically.\n- A successful exact-head all-platform build starts **`publish-release.yml`**. Approve the `release` Environment deployment after inspecting the draft. Publication then acquires the release-state lock, revalidates the approved run, release branch, tag, draft, artifacts, open PRs, and pending hotfixes, and publishes only if they still agree. The draft body contains the bilingual `electron-builder.yml` notes followed by GitHub's generated changes. The final fetched `main` SHA is the hotfix cutoff; a hotfix merged after that snapshot belongs to the next release. Publication triggers **`post-release.yml`**, which uses the published tag as its source, applies only the release metadata delta to the latest `main`, and creates a `release-sync/v{version}` metadata-only PR.\n- The metadata PR synchronizes only `package.json`, `electron-builder.yml`, release history, and the generated product manifest. It triggers **`ci.yml`**; merge it only after CI passes.\n- When squash-merging the metadata PR, set the commit title to exactly `chore(release): sync v{version} metadata` with only GitHub's optional PR-number suffix, and keep `release-metadata-boundary: v{version}` on its own line in the squash commit body so the next release can find the boundary reliably.\n\n## Constraints\n\n- Always read `electron-builder.yml` before modifying it to understand the current format.\n- Never retain changes outside `package.json`, `electron-builder.yml`, `resources/cherry-studio/release-history.json`, and the generated `resources/builtin-agents/cherry-assistant/product-manifest.json`.\n- Never push directly to `main`.\n- Never create the release metadata PR before the GitHub Release is published; `post-release.yml` owns that step.\n- Always show the generated release notes to the user before creating the release branch (unless running in CI with no interactive user).\n\n<!-- File: .agents/skills/README.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Skills Skill\n\nPath: `.agents/skills/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.md)\n\n<!-- File: .agents/skills/README.zh.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Skills Skill\n\nPath: `.agents/skills/README.zh.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/README.zh.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/AGENTS.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/AGENTS.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/README.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Vercel-react-best-practices Skill\n\nPath: `.agents/skills/vercel-react-best-practices/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/README.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-event-handler-refs.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/advanced-init-once.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-init-once.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/advanced-use-latest.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/async-api-routes.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-api-routes.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-api-routes.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/async-defer-await.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-defer-await.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-defer-await.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/async-dependencies.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-dependencies.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-dependencies.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/async-parallel.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-parallel.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-parallel.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/async-suspense-boundaries.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-barrel-imports.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/bundle-conditional.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-conditional.md)\n\n<!-- File: .agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md (Tokens: ~300 | Category: anthropic-skill) -->\n# Rules Skill\n\nPath: `.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/CherryHQ/cherry-studio/HEAD/.agents/skills/vercel-react-best-practices/rules/bundle-defer-third-party.md)\n\n<!-- ... +99 more modular skills available via /api/skills/CherryHQ/cherry-studio?path={path} -->\n</yakaai_skills>"}