/pr-review-fix
Periodically analyze open pull requests for CI failures, code review feedback, and quality issues, then fix them in batch. Use this skill when the user asks to check PR status, triage CI failures, fix review comments, analyze open PRs, or run a scheduled PR health check across
$ npx -y skills add TencentCloudBase/CloudBase-AI-Toolkit --skill pr-review-fix --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/pr-review-fix
Context preview
The summary Claude sees to decide when to auto-load this skill.
Periodically analyze open pull requests for CI failures, code review feedback, and quality issues, then fix them in batch. Use this skill when the user asks to check PR status, triage CI failures, fix review comments, analyze open PRs, or run a scheduled PR health check across
SKILL.md
pr-review-fix.SKILL.mdname: pr-review-fix
description: Periodically analyze open pull requests for CI failures, code review feedback, and quality issues, then fix them in batch. Use this skill when the user asks to check PR status, triage CI failures, fix review comments, analyze open PRs, or run a scheduled PR health check across the repository.
alwaysApply: false
PR Review & Fix
Systematically analyze open pull requests for CI failures, code review feedback, and code quality issues — then fix them efficiently.
When to use this skill
Use this skill when you need to:
- Check the status of all open PRs (CI, reviews, conflicts)
- Triage and fix CI build/test failures on PR branches
- Address code review feedback (reviewer comments, requested changes)
- Run a scheduled health check across all open PRs
- Fix multiple PRs in a single session without losing context
**Do NOT use for:**
- Creating new PRs or new features
- Merging PRs (that's a manual decision)
- General code refactoring unrelated to PR feedback
- Reviewing code as a reviewer (this skill is for *responding* to reviews)
Workflow
Phase 1 — Discovery
1. Read `references/discovery.md` for the full discovery procedure. 2. Fetch the list of open PRs from GitHub:
gh pr list --state open --json number,title,headRefName,statusCheckRollup,reviewDecision,mergeable --limit 30
3. For each PR, classify its health status:
- **🔴 CI Failed** — at least one required check failed
- **🟡 Changes Requested** — reviewer left requested changes
- **🟢 Healthy** — CI passing + approved or no review yet
- **⚪ Conflict** — merge conflicts detected
Phase 2 — Triage
1. Read `references/triage.md` for prioritization rules. 2. Prioritize by severity: CI failures > review changes > conflicts. 3. For each failing PR, identify root cause category:
- **Build error** — TypeScript/webpack compilation failure
- **Test failure** — vitest/jest test assertion or timeout
- **Lint/type error** — ESLint, type-check, or format issues
- **Review feedback** — code style, logic, security, or design concerns
4. Present a summary table to the user before proceeding to fixes.
Phase 3 — Fix
1. Read `references/fix-workflow.md` for the fix procedure. 2. For each PR to fix (in priority order): a. Stash current work: `git stash` b. Check out the PR branch: `git checkout -B <branch> github/<branch>` c. Reproduce the issue locally (build, test, or lint) d. Apply the fix e. Verify locally: build → test → lint f. Commit with conventional-changelog format: `fix(<scope>): 🔧 <description>` g. Push: `git push github <branch>` h. Return to original branch: `git checkout <original> && git stash pop` 3. After all fixes, present a completion summary.
Phase 4 — Verify
1. After pushing fixes, wait 1-2 minutes for CI to trigger. 2. Check CI status for each fixed PR:
gh pr checks <number>
3. If CI still fails, loop back to Phase 3 for that PR.
Routing
| Task | Read | | --- | --- | | Discover and list open PR status | `references/discovery.md` | | Prioritize which PRs to fix first | `references/triage.md` | | Execute fixes on PR branches | `references/fix-workflow.md` | | Understand project CI pipeline | `references/ci-pipeline.md` | | Common fix patterns and recipes | `references/fix-recipes.md` |
Git safety rules
- **Never force-push** to a PR branch unless explicitly asked.
- **Never amend** commits that are already pushed.
- **Always stash** before switching branches.
- **Always verify** build + test locally before pushing.
- **One commit per fix session** — keep the diff reviewable.
Commit conventions
Follow the project's conventional-changelog format:
fix(<scope>): 🔧 <english description>
Where `<scope>` is the affected module (e.g., `cloudrun`, `security`, `code-quality`, `test`).
Minimum self-check
- Did you fetch the latest remote state before analyzing?
- Did you reproduce the failure locally before attempting a fix?
- Did you verify build + test pass after applying the fix?
- Did you switch back to the original branch after each fix?
- Did you present a clear summary of what was fixed and what remains?
Read more
name: pr-review-fix description: Periodically analyze open pull requests for CI failures, code review feedback, and quality issues, then fix them in batch. Use this skill when the user asks to check PR status, triage CI failures, fix review comments, analyze open PRs, or run a scheduled PR health check across the repository. alwaysApply: false
PR Review & Fix
Systematically analyze open pull requests for CI failures, code review feedback, and code quality issues — then fix them efficiently.
When to use this skill
Use this skill when you need to:
- Check the status of all open PRs (CI, reviews, conflicts)
- Triage and fix CI build/test failures on PR branches
- Address code review feedback (reviewer comments, requested changes)
- Run a scheduled health check across all open PRs
- Fix multiple PRs in a single session without losing context
**Do NOT use for:**
- Creating new PRs or new features
- Merging PRs (that's a manual decision)
- General code refactoring unrelated to PR feedback
- Reviewing code as a reviewer (this skill is for *responding* to reviews)
Workflow
Phase 1 — Discovery
1. Read `references/discovery.md` for the full discovery procedure. 2. Fetch the list of open PRs from GitHub:
gh pr list --state open --json number,title,headRefName,statusCheckRollup,reviewDecision,mergeable --limit 30
3. For each PR, classify its health status:
- **🔴 CI Failed** — at least one required check failed
- **🟡 Changes Requested** — reviewer left requested changes
- **🟢 Healthy** — CI passing + approved or no review yet
- **⚪ Conflict** — merge conflicts detected
Phase 2 — Triage
1. Read `references/triage.md` for prioritization rules. 2. Prioritize by severity: CI failures > review changes > conflicts. 3. For each failing PR, identify root cause category:
- **Build error** — TypeScript/webpack compilation failure
- **Test failure** — vitest/jest test assertion or timeout
- **Lint/type error** — ESLint, type-check, or format issues
- **Review feedback** — code style, logic, security, or design concerns
4. Present a summary table to the user before proceeding to fixes.
Phase 3 — Fix
1. Read `references/fix-workflow.md` for the fix procedure. 2. For each PR to fix (in priority order): a. Stash current work: `git stash` b. Check out the PR branch: `git checkout -B <branch> github/<branch>` c. Reproduce the issue locally (build, test, or lint) d. Apply the fix e. Verify locally: build → test → lint f. Commit with conventional-changelog format: `fix(<scope>): 🔧 <description>` g. Push: `git push github <branch>` h. Return to original branch: `git checkout <original> && git stash pop` 3. After all fixes, present a completion summary.
Phase 4 — Verify
1. After pushing fixes, wait 1-2 minutes for CI to trigger. 2. Check CI status for each fixed PR:
gh pr checks <number>
3. If CI still fails, loop back to Phase 3 for that PR.
Routing
| Task | Read | | --- | --- | | Discover and list open PR status | `references/discovery.md` | | Prioritize which PRs to fix first | `references/triage.md` | | Execute fixes on PR branches | `references/fix-workflow.md` | | Understand project CI pipeline | `references/ci-pipeline.md` | | Common fix patterns and recipes | `references/fix-recipes.md` |
Git safety rules
- **Never force-push** to a PR branch unless explicitly asked.
- **Never amend** commits that are already pushed.
- **Always stash** before switching branches.
- **Always verify** build + test locally before pushing.
- **One commit per fix session** — keep the diff reviewable.
Commit conventions
Follow the project's conventional-changelog format:
fix(<scope>): 🔧 <english description>
Where `<scope>` is the affected module (e.g., `cloudrun`, `security`, `code-quality`, `test`).
Minimum self-check
- Did you fetch the latest remote state before analyzing?
- Did you reproduce the failure locally before attempting a fix?
- Did you verify build + test pass after applying the fix?
- Did you switch back to the original branch after each fix?
- Did you present a clear summary of what was fixed and what remains?
AI writes the code. CloudBase runs the backend. The CloudBase integration layer for AI coding tools: Plugin installs the stack, Skills steer how code is written, MCP operates databases, functions, storage, and deploys from chat.
Repo: TencentCloudBase/CloudBase-AI-Toolkit
Other skills on cloudbase-ai-toolkit.
- /ai-model-nodejs
Use this skill for Node.js backend AI via @cloudbase/node-sdk (>=3.16.0) — cloud functions, CloudRun, Express, Koa, NestJS, serverless APIs, scheduled jobs, LLM proxies. Only SDK supporting image generation (ai.createImageModel + generateImage). Text models via ai.createModel
Open skill - /ai-model-web
Use this skill when a browser/Web app (React, Vue, Angular, Next, Nuxt, static sites, SPAs, dashboards, AI chat UI) needs AI models via @cloudbase/js-sdk. Default routing for page/页面/Web/前端/frontend/网页/H5 AI — call directly from browser, do NOT propose a Node.js proxy. Covers
Open skill - /ai-model-wechat
Use this skill for WeChat Mini Program AI via wx.cloud.extend.AI (小程序, 企业微信小程序, wx.cloud apps). Features generateText and streamText with callbacks (onText, onEvent, onFinish). Models via wx.cloud.extend.AI.createModel with groups hunyuan-exp (小程序成长计划), cloudbase (main managed),
Open skill - /auth-nodejs-cloudbase
CloudBase Node SDK auth guide for server-side identity, user lookup, and custom login tickets. This skill should be used when Node.js code must read caller identity, inspect end users, or bridge an existing user system into CloudBase; not when configuring providers or building
Open skill - /auth-tool-cloudbase
CloudBase auth provider configuration and login-readiness guide. This skill should be used when users need to inspect, enable, disable, or configure auth providers, publishable-key prerequisites, login methods, SMS/email sender setup, or other provider-side readiness before
Open skill - /auth-web-cloudbase
CloudBase Web Authentication Quick Guide for frontend integration after auth-tool has already been checked. Provides concise and practical Web authentication solutions with multiple login methods and complete user management.
Open skill

