architect

Map domain problems into software abstractions, boundaries, and dependency directions.

Updated Feb 26, 2026
One-click install
npx skills add https://github.com/rockandrolla13/blueprint --skill architect-rockandrolla13
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architect
Source: https://github.com/rockandrolla13/blueprint/tree/main/architect
Command: npx skills add https://github.com/rockandrolla13/blueprint --skill architect-rockandrolla13

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Decompose a domain problem into a structured software architecture by identifying domain concepts, boundaries, and abstractions to enable consistent design decisions.

Core Features & Use Cases

  • Domain mapping: identify core concepts and relationships to shape the architecture.
  • Boundary drawing: partition the system into modules with clear responsibilities and interfaces.
  • Abstraction decisions: decide between modules, packages, classes, and protocols to separate concerns.
  • Dependency guidance: ensure domain logic remains independent of infrastructure and orchestration layers.

Quick Start

Provide a domain problem statement and constraints, and I will return a boundary-driven architecture plan.

Frequently Asked Questions about architect

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

FAQPage Schema
How do I decompose a domain problem into software architecture with clear module boundaries?

To decompose a domain problem into software architecture, you map core domain concepts and relationships to partition the system into modules with clear responsibilities, interfaces, and abstraction layers for scalable design.

What is dependency direction in system architecture and how does it prevent infrastructure leakage?

Dependency direction in system architecture ensures domain logic remains independent of infrastructure and orchestration layers, preventing infrastructure leakage by forcing dependencies to point inward toward core abstractions rather than outward to external systems.

How do I design abstractions and interfaces to separate concerns in a software system?

Designing abstractions to separate concerns involves deciding between modules, packages, classes, and protocols to partition the system, ensuring each component has clear responsibilities and boundaries that enforce consistent architectural decisions.

Can I use this approach for a system where I know the problem space but need help with domain mapping?

Yes, this approach is designed for users who know the problem space but need help with domain mapping, translating domain concepts and relationships into structured software boundaries and abstraction decisions for scalable architecture.

What's the best way to structure a domain problem statement for boundary-driven architecture planning?

The best way to structure a domain problem statement for boundary-driven architecture planning is to provide the domain problem statement alongside your system constraints, which yields a structured architecture plan with clear module boundaries and interfaces.