prd-v06-architecture-design_skill

This skill converts TECH-, RISK-, and FEA- inputs into ARC- entries and coherent system designs that guide implementation.
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational