菜单
Explicit helper for authentication and payment implementation with Clerk, Supabase Auth, or Stripe. Do NOT load for: general UI work, database design, or non-auth features.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
HAR: Execute Plans.md tasks from single task to full parallel team run. Trigger: implement, execute, do everything, breezing, team run, parallel. Do NOT load for: planning, review, release, setup.
Browser automation through the repo agent-browser CLI. Explicit helper for navigation, forms, screenshots, scraping, and web-app checks. Prefer Browser Use or Playwright when available. Do NOT load for: sharing URLs, embedding links, or editing screenshot files.
CI red? Call us. Pipeline fire brigade deploys. Use when user mentions CI failures, build errors, test failures, or pipeline issues. Do NOT load for: local builds, standard implementation work, reviews, or setup.
Explicit helper for CRUD scaffolding and API endpoint generation. Do NOT load for: UI components, form design, database schema discussion, or general implementation.
Deploy to Vercel/Netlify. One-way ticket to production arranged. Use when user mentions deployment, Vercel, Netlify, analytics, or health checks. Do NOT load for: implementation work, local development, reviews, or setup.
Generate an Acceptance Demo HTML for non-engineer vibecoders right before ship/wait/reject decision. Reads back the acceptance_criteria that were stored as personal-preference.v1 by harness-plan-brief (joined by user_request_hash), then renders a single-file HTML showing each criterion as verified or unverified along with a ship/wait/reject recommendation. Use when the user asks for an acceptance review, wants to decide whether to ship a delivered task, or says: acceptance demo, accept demo, acceptance decision, acceptance review, ship/wait/reject decision, acceptance inspection. Do NOT load for: implementation, code review, release work.
| name | auth |
| description | Explicit helper for authentication and payment implementation with Clerk, Supabase Auth, or Stripe. Do NOT load for: general UI work, database design, or non-auth features. |
| description-en | Explicit helper for authentication and payment implementation with Clerk, Supabase Auth, or Stripe. Do NOT load for: general UI work, database design, or non-auth features. |
| allowed-tools | ["Read","Write","Edit","Bash"] |
| user-invocable | false |
| disable-model-invocation | true |
A set of skills responsible for implementing authentication and payment features.
| Feature | Details |
|---|---|
| Authentication | See references/authentication.md |
| Payments | See references/payments.md |
Since authentication and payment features always carry high security risk, always display the following before starting work:
🔐 Security Checklist
This work is security-critical. Please confirm the following:
### Authentication
- [ ] Passwords are hashed (bcrypt/argon2)
- [ ] Session management is secure (HTTPOnly Cookie)
- [ ] CSRF protection is implemented
- [ ] Rate limiting (brute-force protection)
### Payments
- [ ] Sensitive data (card numbers, etc.) is not stored on the server
- [ ] Stripe/payment provider SDK is used correctly
- [ ] Webhook signature verification
- [ ] Amount tampering prevention (amount finalized server-side)
### Common
- [ ] Error messages are not overly detailed (prevent information leakage)
- [ ] Sensitive information is not written to logs
⚠️ Caution Level: 🔴 High
This feature carries the following risks:
- Credential exposure
- Unauthorized access
- Fraudulent payment manipulation
Expert review is recommended.
🔐 Building login and payment features safely
1. **"Hash" passwords**
- Store passwords in a form that cannot be reversed
- Safe even if data is leaked
2. **Do not store card information on your server**
- Delegate to a dedicated service like Stripe
- Never store anything on your own server
3. **Keep error messages vague**
- Use "Authentication failed" instead of "Password is incorrect"
- Don't give hints to malicious actors