Generate architecture doc
Skill eroveda/blueprint-skills/skills/generate-architecture-doc
Domain decomposition + IEEE SWEBOK documentation skills for Claude Code
npx -y skills add eroveda/blueprint-skills --skill generate-architecture-docAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generates ARCHITECTURE.md following IEEE 15289 standards. Use when documenting a new or existing project's technical architecture. Do NOT use for user-facing docs (use generate-user-guide) or API docs (use generate-api-catalog). Trigger with "generate architecture doc", "document the architecture", or "create ARCHITECTURE.md".
SKILL.md
3.8 KB, as published. Nobody here has run it
Generate Architecture Documentation
You create professional ARCHITECTURE.md files following IEEE/ISO 15289 (Life-cycle Information Items).
Document Structure
# Architecture — [Project Name]
## Overview
Brief description of the system's purpose, scope, and primary actors.
## Tech Stack
| Layer | Technology | Version | Purpose |
|---|---|---|---|
| Runtime | ... | ... | ... |
| Framework | ... | ... | ... |
| Database | ... | ... | ... |
| Auth | ... | ... | ... |
## Component Architecture
### Module: [name]
- **Responsibility**: ...
- **Public API**: classes/interfaces exposed
- **Dependencies**: other modules consumed
- **Database**: tables owned
(Repeat for each module)
## Data Model
### Entities
For each entity:
- **Name** and primary key
- **Fields** with types and constraints
- **Relationships** to other entities
- **Indexes** for performance
### Schema Changes
List of schema migrations or changes in order, with what each one does.
## API Contracts
(Adapt this section to the project's interface type: REST endpoints, GraphQL schema, gRPC services, CLI commands, SDK methods, or message queue topics)
### Endpoints by Resource
For each resource (e.g., Task, Project, User):
- HTTP method + path
- Request/response schemas
- Auth requirements
- Error responses
## Cross-Cutting Concerns
### Authentication & Authorization
- Auth mechanism (JWT, OAuth, etc.)
- Token claims structure
- Role-based access control rules
### Multi-Tenancy (if applicable)
- Tenant isolation strategy
- Tenant ID propagation
- Cross-tenant data leak prevention
### Rate Limiting (if applicable)
- Limits per tenant/user
- Implementation strategy
- Headers exposed (X-RateLimit-*)
### Logging & Observability
- Log levels and structure
- Tracing/metrics endpoints
## Non-Functional Requirements
| NFR | Target | Validation |
|---|---|---|
| Response time (P95) | < 100ms | Load test |
| Concurrent users | 500 | Stress test |
| Availability | 99.9% | Uptime monitoring |
## Architectural Decisions (ADRs)
### ADR-001: [Decision title]
- **Status**: Accepted/Superseded
- **Context**: Why this decision was needed
- **Decision**: What was decided
- **Consequences**: Trade-offs
(Repeat for each significant decision)
## Standards Compliance
- IEEE SWEBOK v4.0 — used for component categorization
- ISO/IEC/IEEE 12207 — software lifecycle processes
- ISO/IEC/IEEE 15289 — documentation standards
- (Additional standards as applicable)
## Glossary
Definitions of domain-specific terms used throughout the codebase.
How to Use
- Read the project structure: source files, package layout, README
- Identify modules and their responsibilities
- Map entities and relationships from data model definitions (ORM models, schema files, migration scripts)
- Extract interfaces from the codebase (API endpoints, CLI commands, SDK methods, message handlers)
- Identify cross-cutting concerns from middleware, interceptors, decorators, or framework configuration
- Generate the document in the order above
- Save as ARCHITECTURE.md in project root
Quality Checklist
- Tech stack table with exact versions
- Each module has Responsibility, Public API, Dependencies
- Entity diagram or table with all fields
- All endpoints documented (no orphan controllers)
- Auth flow described step-by-step
- At least 3 ADRs for significant decisions
- Standards compliance section
- No code blocks longer than 20 lines (link to file instead)