القائمة
Execute a unit of work end-to-end: plan, implement, validate with typecheck and tests, then commit. Use when user wants to do work, build a feature, fix a bug, or implement a phase from a plan.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Guides Stripe integration decisions — API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, Treasury financial accounts, integration surfaces (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, creating connected accounts, or implementing secure key handling.
Review and auto-fix code against project rules and conventions. Use after completing a feature, big refactor, or before committing. Invoke with /code-review. Checks modified/created files for file naming, React patterns, tRPC types, Zod schemas, forms, TailwindCSS colors, code elegance, and component size / single-responsibility / folder organization, then directly fixes violations in place (flags large refactors for user confirmation).
Invoke when the user says "fix feedback", mentions Faster Fixes, or wants to check, triage, or fix issues that clients reported through a website feedback widget. This skill fetches client-submitted bug reports and comments from the Faster Fixes platform via MCP, then locates and fixes each reported issue in the codebase. Covers reviewing new client reports, triaging widget-collected feedback, fixing bugs clients found on the live site, processing comments left via an on-page widget. Does NOT cover code review comments, fixing feedback-form UI bugs, responding to product feedback, refactoring feedback components, or creating surveys.
Create and configure Inngest durable functions. Covers triggers (events, cron, invoke), step execution and memoization, idempotency, cancellation, error handling, retries, logging, and observability.
Design and send Inngest events. Covers event schema and payload format, naming conventions, IDs for idempotency, the ts param, fan-out patterns, and system events like inngest/function.failed.
Configure Inngest flow control for functions. Covers concurrency limits with keys, throttling, rate limiting, debounce, priority, singleton, and event batching.
| name | do-work |
| description | Execute a unit of work end-to-end: plan, implement, validate with typecheck and tests, then commit. Use when user wants to do work, build a feature, fix a bug, or implement a phase from a plan. |
| disable-model-invocation | true |
Execute a complete unit of work: plan it, build it, validate it, commit it.
Read any referenced plan or PRD. Explore the codebase to understand the relevant files, patterns, and conventions. If the task is ambiguous, ask the user to clarify scope before proceeding.
Use gh api --jq, not gh issue view — long bodies get truncated.
gh api repos/OWNER/REPO/issues/N --jq '.body' > /tmp/issue-N.md
If the text ends in ... (truncated), page it in slices:
gh api repos/OWNER/REPO/issues/N --jq '.body[1200:2400]'
Read linked ## Parent / ## Blocked by issues the same way.
If the task has not already been planned, create a plan for it.
Work through the plan step by step. Make sure to follow coding standards
Run the feedback loops and fix any issues. Repeat until both pass cleanly.
pnpm run typecheck
pnpm run test
Once typecheck and tests pass, pause to let the user review, then commit the work.
Never add a Co-Authored-By: Claude line (or any co-authorship line) to commit messages
If the task is complete, and was coming from a github issue, hand it off for QA:
Remove the ready-for-agent label (if present) and add the ready-for-qa label
Leave a QA checklist comment so a human (or a later QA pass) can verify the work before closing. The checklist must be:
- [ ] ...) so they can be ticked off.Use this shape:
## QA checklist
How to verify before closing:
- [ ] <observable behavior> — <how to trigger> → <expected result>
- [ ] <edge case to spot-check>
- [ ] No regression in <adjacent area touched>
If the task is NOT complete, keep the ready-for-agent label and leave a
comment on the GitHub issue describing what was done and what remains.