From pi-dev
Use when creating a backend architecture document. Reads existing project docs to determine what decisions matter for this specific project, then interviews accordingly. Writes to 04_tech/.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pi-dev:backend-architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Adaptive skill. Reads existing project documents first, determines which architectural decisions are relevant to THIS project, then interviews the user on those specific decisions.
Adaptive skill. Reads existing project documents first, determines which architectural decisions are relevant to THIS project, then interviews the user on those specific decisions.
No fixed template — sections are derived from what the project needs.
Scan all docs → Identify relevant decision areas → Interview on those areas only
→ Generate doc with sections appropriate to this project → Write
Run:
find . -maxdepth 3 -type d -name "docs" | grep -v node_modules | grep -v ".git" | sort
./docs)docs/ and create it if missingRead ALL of the following that exist:
| Document | What to extract |
|---|---|
docs/01_product/01_prd.md | Scale hints, user type, offline needs, performance expectations |
docs/01_product/03_product_principles.md | Technical implications of each principle |
docs/02_business/domain_model.md | Entities, subdomains, invariants — shapes API structure |
docs/02_business/business_rules.md | Rules that must be enforced server-side |
docs/02_business/data_model.md | Tables, relationships, query patterns |
docs/03_design/ux_spec.md | Flows that need API support, real-time needs, offline flows |
docs/05_scrum/discovery/S*.md | Slice scopes — what backend work is coming first |
After reading, tell the user:
"I found [list of docs]. Based on these, the decisions that matter most for this project's backend are: [list decisions you identified]. I'll focus the interview on these."
Then ask: "Is there anything I missed or a concern I should add?" (free text)
Based on what you found, determine which of these areas need decisions:
Always ask:
Ask if data_model.md exists or entities found:
Ask if business_rules.md has complex invariants:
Ask if ux_spec.md has real-time features (live updates, notifications):
Ask if PRD suggests mobile or offline:
Ask if multiple subdomains in domain model:
Ask if slices exist:
Ask if no existing docs:
Ask ONLY the questions relevant to this project based on Step 0. Use AskUserQuestion. One question at a time.
For each decision area identified, ask the specific question. Examples:
Stack: "What is the backend language and framework?" (free text or "not decided")
API style: "What API style?" (options: REST / GraphQL / tRPC / gRPC / Not decided)
Auth: "How will authentication work?" (options: JWT / Session / OAuth/SSO / Magic link / Not decided) Follow up if needed: "Any authorization model? (roles, per-resource permissions, none)"
Data access (if data model exists): "For [Entity from data_model], what are the most frequent read patterns? Any risk of large result sets?" (free text)
Rule enforcement (if complex business rules found): "[Rule X] from business_rules.md — enforced at DB level (constraint), application level, or both?" (per critical rule)
Real-time (if ux_spec suggests it): "[Flow X] in UX spec seems to need live updates. How should this work?" (options: Polling / WebSockets / Server-Sent Events / Not needed / Not decided)
Module boundaries (if multiple subdomains): "How do the [subdomain list] subdomains map to code structure?" (options: Single module / Feature folders / Separate packages / Not decided)
Error handling: "What is the error response format? How does the API communicate failures to clients?" (free text)
Deployment: "How will the backend be deployed?" (options: Single server / Serverless / Containers / Not decided)
Generate sections based on what was actually discussed. Do not include empty sections.
# Backend Architecture
**Project:** [name]
**Date:** [today]
## Context
[Brief summary of what existing docs informed this architecture — which docs were read, key constraints found]
## Stack Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| Language/Framework | [answer] | [why, linked to project context] |
| API style | [answer] | [why] |
| Auth | [answer] | [why] |
| Deployment | [answer] | [why] |
| [other decisions made] | | |
## Internal Structure
[How the backend is organized internally — derived from subdomain analysis if available]
## Data Access
[Only if data_model.md existed — key patterns, ORM choice, query risks identified]
## Business Rule Enforcement
[Only if complex rules found — where each critical rule is enforced and why]
## API Design Conventions
[Error format, versioning, pagination, naming — based on API style chosen]
## [Real-time / Sync] (only if applicable)
[Strategy and rationale — only if ux_spec or PRD indicated this is needed]
## First Slice Backend Needs
[Only if slices exist — what the backend must deliver for S1]
## Open Decisions
[Questions that came up but weren't resolved — with context for when to decide]
Write to docs/04_tech/backend_architecture.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