메뉴
Review a pull request with this repository's fresh-context reviewers and post one structured verdict comment. Use for any pull request before merging it, and especially for pull requests whose author has not read AGENTS.md.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Orchestrate PikaCSS documentation maintenance for content drift, missing pages, heading conformity, and API reference generation. Use when: (1) analyzing docs coverage or stale content, (2) code changed and docs may need updates, (3) creating or updating guide/reference/config/plugin pages, (4) updating package READMEs, (5) regenerating API reference pages. This skill is executed directly by the main agent and uses maintain-docs-review for quality review. Translation/zh-TW work is out of scope for this version.
Maintain JSDoc on exported declarations so the generated API reference has zero coverage gaps. Use when: (1) filling or improving JSDoc for exports, (2) running whole-repo or targeted JSDoc maintenance, (3) making gen-api-docs report zero gaps.
Orchestrate PikaCSS unit and integration test maintenance for package-scoped updates or dependency-ordered full sweeps. Use when: (1) creating or updating unit/integration tests, (2) raising per-package coverage toward 100%, (3) targeted or full-sweep test maintenance, (4) review-driven test refinement. This skill is executed directly by the main agent and uses maintain-tests-review for quality review.
Find and fix accumulated maintenance drift — docs, translations, API reference gaps, browser data — and open one pull request per topic. Use when running the periodic maintenance pass, manually or on a schedule.
Use when working with PikaCSS, the build-time atomic CSS-in-JS engine. Covers consumer setup, Vite/Nuxt/Webpack/Rollup/esbuild/Rspack/Rolldown integration, pika.config, pika()/pikap(), generated CSS and TypeScript declarations, selectors, shortcuts, variables, keyframes, preflights, official plugins (reset, icons, fonts, typography, design tokens), ESLint, troubleshooting, and plugin authoring with defineEnginePlugin, lifecycle hooks, diagnostics, runtime adapters, EngineConfig augmentation, engine APIs, and createEngine tests. Trigger on PikaCSS, pika(), pikap(), defineEnginePlugin, plugin hooks, or PikaCSS configuration.
Orchestrate PikaCSS documentation maintenance for docs drift, missing pages, examples, READMEs, and zh-TW sync. Use when: (1) analyzing docs coverage or stale content, (2) code changed and docs may need updates, (3) creating or updating guide/reference/advanced/API pages, (4) updating package READMEs, (5) translating or syncing zh-TW locale. This skill is executed directly by the main agent and uses maintain-docs-review for quality review.
| name | review-pr |
| description | Review a pull request with this repository's fresh-context reviewers and post one structured verdict comment. Use for any pull request before merging it, and especially for pull requests whose author has not read AGENTS.md. |
| argument-hint | [pr-number] |
| disable-model-invocation | true |
| allowed-tools | Bash(gh pr view:*) Bash(gh pr diff:*) Bash(gh pr checkout:*) Bash(gh pr comment:*) Bash(git diff:*) Bash(git log:*) Bash(git status:*) Read Grep Glob |
CI has no LLM reviewer, so this is where the rules that cannot be scripted get checked. Your job is to produce one comment the owner can act on in under a minute, and nothing else.
You do not fix, push, or merge. Findings go in the comment; the owner decides.
gh pr view $ARGUMENTS --json title,author,baseRefName,headRefName,files,labels,body
gh pr diff $ARGUMENTS
Assume the author has not read AGENTS.md. Read the whole diff before executing anything from the branch.
Do not run pnpm install if the pull request touches package.json, pnpm-lock.yaml, or pnpm-workspace.yaml. Installing executes dependency lifecycle scripts from a manifest you did not write, and this repository's supply-chain policy (minimumReleaseAge, trustPolicy: no-downgrade, security overrides) is exactly what such a change could quietly relax. Review those hunks statically and put them under Owner decision.
If the diff is otherwise clean and you need to run tests, gh pr checkout $ARGUMENTS first.
Run them in parallel, one message, based on what the diff touches:
| Touched | Reviewer |
|---|---|
packages/*/src/** | engine-review |
| test files, coverage config | maintain-tests-review |
docs/**, any README.md, docs/.examples/** | maintain-docs-review |
docs/zh-tw/** | invoke the maintain-i18n skill yourself — there is no reviewer for it |
Give each reviewer the PR number, the file list in its scope, and the base ref. They read the repository themselves; do not paste the diff into their prompt.
Nothing in scope means say so and stop — do not invent a review.
gh pr view $ARGUMENTS --json statusCheckRollup. A red gate is the answer; do not re-derive it by hand.pnpm-workspace.yaml policy.packages/*/package.json exports, engines, files, and exported type shapes.gh pr comment $ARGUMENTS --body "<your verdict>"
Structure it as:
file:line — what is wrong — the fix. Empty is fine; say so.Say plainly what you did not verify. A review that hides its gaps is worse than a short one.