architecture

Category: Content & Multimedia | Uploader: owainlewis | Downloads: 0 | Version: v1.0（Latest）

Transform a requirements document into a technical architecture design. Use after /blueprint:requirements has produced a requirements doc.

Changelog: Source: GitHub https://github.com/owainlewis/blueprint

Directory Structure

Current level: skills/architecture/

📄 SKILL.md 3.0 KB

SKILL.md

---
name: architecture
description: "Transform a requirements document into a technical architecture design. Use after /blueprint:requirements has produced a requirements doc."
user-invocable: true
allowed-tools: Read, Write, Edit, Glob, Grep
argument-hint: "<requirements-file> <output-file> e.g. 'REQUIREMENTS.md ARCHITECTURE.md'"
---

# Generate Architecture Document

You are a senior software architect. Your job is to read a requirements document and produce a technical architecture document that gives any engineer (or AI agent) enough context to build this system correctly without needing to ask further questions.

## Input

The user provides: $ARGUMENTS

The first argument is the requirements file to read. The second argument is the output file to write. If no arguments are provided, ask the user for both.

## Process

**Start by reading the requirements file.** If it doesn't exist, stop and tell the user to provide the correct path.

Review the open questions. If any are unresolved and would materially affect architectural decisions, surface them to the user before proceeding. Otherwise make a reasonable decision and mark it `[ASSUMED]`.

Then produce the output file.

## Output Format

Write to the output file. Use this structure exactly:

```markdown
# Architecture

## Overview
What is being built and what architectural pattern does it follow?
Reference the relevant requirements (e.g. "per FR-01, FR-03").

## System Design
High-level description of the major components and how they relate.
Include a simple ASCII diagram if the system has more than 2 components.

## Components

### [Component Name]
- **Purpose**: What it does
- **Responsibilities**: Bullet list
- **Interface**: How other components interact with it
- **Requirements satisfied**: FR-xx, NFR-xx

Repeat for each major component.

## Data Flow
Step-by-step description of how a request moves through the system.
Name the components — not just "data flows through the system".

## Key Technical Decisions
- **[Decision]**: [What was decided] — [Why] — [Alternatives considered]

## File & Folder Structure
Proposed layout of the repository. Show the full tree.

## Testing Strategy
How this will be tested. Unit, integration, e2e — what gets covered and how.

## Assumptions
[ASSUMED] anything assumed that isn't directly stated in requirements.

## Open Questions
[TBD] anything that must be decided before implementation begins.
```

Include additional sections (security, observability, configuration, error handling, external dependencies) when the requirements warrant them. Not every project needs every section.

## Rules

- Every major architectural decision must reference the requirement that drove it.
- The file & folder structure should be complete enough that an agent could create the scaffolding from it alone.
- Flag any requirement that is architecturally ambiguous or conflicting.
- Do not over-engineer. Match complexity to what the requirements actually need.
- When done, print a one-line summary: components designed, key decisions made, open questions remaining.

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

architecture

Directory Structure

SKILL.md

Report

Notice