- Home
- Skills
- Mattgierhart
- Prd Driven Context Engineering
- Prd V06 Architecture Design
prd-v06-architecture-design_skill
- Python
17
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill mattgierhart/prd-driven-context-engineering --skill prd-v06-architecture-design- SKILL.md10.8 KB
Overview
This skill defines how system components connect during PRD v0.6 Architecture, turning stack selections, risks, and feature needs into concrete architecture decisions. It produces ARC- entries that record choices, rationale, alternatives, and consequences. The outputs feed the v0.6 Technical Specification and drive downstream implementation, security, and operations work.
How this skill works
The skill pulls TECH- (technology choices), RISK- (constraints and threats), and FEA- (feature requirements) to shape boundaries, component placement, and integration patterns. It maps component relationships, picks patterns for build vs buy items, and writes ARC- decision records with context and rationale. Diagrams, trust boundaries, and quality gates are created to ensure each major decision has an associated ARC- entry.
When to use it
- When asked to design architecture, system design, or component connectivity
- After TECH- stack selection and before drafting the technical specification
- When high-priority RISK- entries need architectural mitigations
- When deciding how Buy/Integrate services will connect or be abstracted
- When you need documented decisions for downstream teams (security, infra, dev)
Best practices
- Start with a modular monolith for MVP; extract services only with evidence
- Map each high-priority RISK- to at least one ARC- mitigation decision
- Abstract critical vendors behind adapter layers if switching is plausible
- Define clear trust boundaries and data flow before detailing components
- Record every major decision as an ARC- entry with alternatives and consequences
Example use cases
- Choose between monolith, modular monolith, or microservices based on TECH- and RISK- inputs
- Define an adapter layer for authentication provider to avoid vendor lock-in
- Design webhook handling: verify signature, idempotency, enqueue events, then process
- Document caching and read-replica strategy to address scaling RISK-007
- Produce ARC- entries for security (JWT strategy), performance (CDN/caching), and devops (CI/CD)
FAQ
An ARC- entry documents an architectural decision with context, rationale, rejected alternatives, and consequences. It creates traceability from risks and tech choices to concrete design actions used by downstream teams.
When should we move from monolith to microservices?
Move only when you have operational evidence—clear scaling hotspots, independent release needs, or team boundaries. The skill recommends starting monolith and extracting services when justified.