From pi-dev
Use when creating a Business Rules document. Starts from invariants already defined in the domain model, then expands with additional rules per subdomain. Writes to 02_business/.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pi-dev:business-rulesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Define business rules per domain area. Starts from what's already in the domain model — doesn't ask again for what's known.
Define business rules per domain area. Starts from what's already in the domain model — doesn't ask again for what's known.
Read domain model → Present known invariants → Expand per subdomain
→ Validation rules → State transitions → Write
Run:
find . -maxdepth 3 -type d -name "docs" | grep -v node_modules | grep -v ".git" | sort
./docs)docs/ and create it if missingRead docs/02_business/domain_model.md. Extract:
If domain model doesn't exist: tell user to run pi-dev:domain-model first. Business rules need the domain model as foundation.
Tell user:
"I found [N] invariants in the domain model: [list them]. These will be included as Critical Rules. Now I'll ask about additional rules per subdomain."
Q1: "The domain model defines these invariants: [list]. Are any of these wrong or outdated? Anything to add?" (free text or "All correct")
For each subdomain found in the domain model, ask:
Q2: "What additional rules govern [subdomain name] beyond the invariants already listed? Use: 'must', 'cannot', 'only when', 'always'." (free text or "None beyond invariants")
Ask per subdomain. Skip subdomains where user answers "None."
Q3: "What data validations exist? (required fields, formats, value ranges, uniqueness constraints)" (free text) Example: "Amount must be > 0. Account name max 100 chars. Email must be unique per user."
If the domain model defined entities with states, ask for each:
Q4: "Entity [X] has states [list from domain model]. What are the allowed transitions and conditions for each?" (free text) Example: "Apartado: Active → Dissolved when fully consumed. Cannot go back to Active once Dissolved."
If no states in domain model: skip this step.
Q5: "Which critical rules should the frontend enforce for UX feedback (not just the backend)?" (free text or "None — backend only")
This determines which rules need client-side validation vs. server-only enforcement.
# Business Rules
**Project:** [name]
**Date:** [today]
**Source:** Derived from `docs/02_business/domain_model.md` + additional rules
## 1. Critical Rules (must never be violated)
These rules, if broken, corrupt data or destroy user trust. Enforced at all layers.
1. [Invariant from domain model + Q1 additions]
2. [...]
## 2. Rules by Subdomain
### [Subdomain 1]
- [rule — phrased as must/cannot/only when/always]
- [...]
### [Subdomain 2]
- [...]
## 3. Validation Rules
| Field / Entity | Validation | Error message |
|----------------|-----------|---------------|
| [field] | [rule] | [message shown to user] |
## 4. State Transitions
### [Entity with states]
**States:** [list]
**Allowed transitions:**
- [State A] → [State B]: when [condition]
- [State B] → [State C]: when [condition]
- [State B] → [State A]: **never** (irreversible)
## 5. Frontend vs Backend Enforcement
| Rule | Backend | Frontend |
|------|---------|----------|
| [rule] | ✅ always | ✅ UX feedback |
| [rule] | ✅ always | ❌ backend only |
Write to docs/02_business/business_rules.md. Create folder if missing.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Applies a firm's KYC/AML rules grid to parsed onboarding records: assigns risk rating, checks required documents, outputs rule outcomes with citations, and routes for escalation.
Generates daily or weekly digests of activity from connected sources (chat, email, docs, tasks, CRM), highlighting action items, decisions, mentions, and project updates.
npx claudepluginhub pirras-torres/pirras-marketplace --plugin pi-dev