菜单
Process PR comments systematically—read all, categorize, fix blocking items, batch changes, reply to threads, and re-review
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Guides Stripe integration decisions across API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, tax and registrations (Stripe Tax, automatic_tax, product tax codes), Treasury financial accounts, integration options (Checkout, Payment Element), migrating from deprecated Stripe APIs, and security best practices (API key management, restricted keys, webhooks, OAuth). Use when building, modifying, or reviewing any Stripe integration, including accepting payments, building marketplaces, integrating Stripe, processing payments, setting up subscriptions, collecting sales tax, VAT, or GST, creating connected accounts, or implementing secure key handling.
Branch naming, commit messages, and PR process for this project
Security checklist for code review—validates auth, input validation, secrets, database safety, Stripe integration, XSS prevention, and dependencies
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
Architecture patterns for Next.js 16 App Router apps. Use when scaffolding a new app, adding a feature, refactoring code into feature folders, deciding where queries/actions/components live, placing Suspense boundaries, choosing the client/server boundary, designing skeletons, preventing CLS, or enabling Cache Components. Also use when the user asks about RSC composition, `params.then()`, `'use cache'`, `cacheTag`, `updateTag`, or static-shell prerendering.
Open a pull request for the current branch in ignite-starter using the repository PR template. Use whenever the user asks to open, create, or raise a PR / pull request, or to prepare a branch for review. Runs the verification gate, writes a Conventional Commit, and fills the template.
| name | address-pr-comments |
| description | Process PR comments systematically—read all, categorize, fix blocking items, batch changes, reply to threads, and re-review |
| disable-model-invocation | true |
1. Read ALL comments before making any changes
2. Group into: must-fix | suggestion | question | nitpick
3. Address all must-fix items first
4. Batch related changes into a single commit per logical concern
5. Reply to every comment thread (fixed / explained / deferred)
6. Push, then request re-review
| Category | Description | Action |
|---|---|---|
[blocking] | Must be fixed before merge | Fix it |
[suggestion] | Reviewer recommendation | Fix if agreed; explain if not |
[question] | Reviewer needs clarification | Clarify in code or comment |
[nitpick] | Style or minor preference | Fix or defer with an issue |
# Always on your feature branch — never commit directly to main
git add -p # Interactive staging — only related changes
git commit -m "fix(auth): add Zod validation to sign-in action per PR review"
git push origin feat/my-feature
One commit per logical concern — not one commit per reviewer comment.
After fixing:
Fixed in
abc1234. Added Zod schema validation before the DB call.
When disagreeing:
I've kept the current approach because [reason]. Happy to align if you still feel strongly — let me know.
When deferring to a follow-up issue:
Good catch — created #456 to track this. Keeping this PR focused on the auth flow for now.
When clarifying (no code change):
This is intentional —
safePromisereturns[null, data]on success, so the destructuring order is correct. Added a comment for clarity.
@reviewer Re-review ready after latest push)[blocking] comments addressedbun run lint passesbun tsc passesbun run test passes