prd-v06-architecture-design

Translate stack decisions and constraints into coherent system architecture with ARC- entries.

193|9|Updated Jul 10, 2025
One-click install
npx skills add https://github.com/mattgierhart/PRD-driven-context-engineering --skill prd-v06-architecture-design
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: prd-v06-architecture-design
Source: https://github.com/mattgierhart/PRD-driven-context-engineering/tree/main/.claude/skills/prd-v06-architecture-design
Command: npx skills add https://github.com/mattgierhart/PRD-driven-context-engineering --skill prd-v06-architecture-design

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Architecture decisions are often scattered, hard to audit, and slow to implement. prd-v06-architecture-design provides a structured approach to convert stack decisions, constraints, and features into a coherent architecture design with traceable rationale.

Core Features & Use Cases

  • Map and document Architecture Decision Categories (Structure, Integration, Security, Performance, Data, DevOps) and generate ARC- entries with rationale.
  • Define system boundaries and component relationships to establish clear ownership and integration patterns.
  • Support a design workflow that responds to requests for architecture design, system overview, and explicit connection patterns, while linking to TECH-, RISK-, and FEA- inputs.

Quick Start

Provide your TECH- decisions, RISK- constraints, and FEA- features, then request an Architecture Design to generate a structured system design.

Frequently Asked Questions about prd-v06-architecture-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I document system architecture decisions with traceable rationale?

Document system architecture decisions by generating structured ARC- entries that capture rationale across Structure, Integration, Security, Performance, Data, and DevOps categories. This maps stack decisions and constraints into a coherent, auditable architecture design.

What is the best way to define component relationships and system boundaries?

Define component relationships and system boundaries by establishing clear ownership and integration patterns within the architecture design. This process translates technical constraints into explicit connection patterns between system components.

Can I use this system design workflow with existing feature and risk documentation?

Yes, the system design workflow explicitly integrates with existing feature and risk documentation by linking ARC- entries to FEA- features, RISK- constraints, and TECH- decisions to generate a structured technical specification.

How to create a coherent technical architecture from scattered stack decisions?

Create a coherent technical architecture by consolidating scattered stack decisions, features, and constraints into a structured system design. This produces traceable architecture decision entries that guide the v0.6 Technical Specification.

When do I need to generate architecture decision records for integration patterns?

Generate architecture decision records when you need to audit system integration patterns, establish component ownership, or translate technical stack decisions into a formal technical architecture with documented rationale.

Does this architecture design approach work without predefined dependencies?

Yes, the architecture design approach operates without dependencies, requiring only your TECH- decisions, RISK- constraints, and FEA- features as inputs to generate the structured system design and architecture entries.