architecture-doc-template
Generates ARCHITECTURE.md files for PHP projects. Creates layer documentation, component descriptions, and architectural diagrams.
Best use case
architecture-doc-template is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Generates ARCHITECTURE.md files for PHP projects. Creates layer documentation, component descriptions, and architectural diagrams.
Teams using architecture-doc-template should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/architecture-doc-template/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How architecture-doc-template Compares
| Feature / Agent | architecture-doc-template | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Generates ARCHITECTURE.md files for PHP projects. Creates layer documentation, component descriptions, and architectural diagrams.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Architecture Documentation Template Generator
Generate comprehensive architecture documentation for PHP projects.
## Document Structure
```markdown
# Architecture
## Overview
{high-level description}
## Directory Structure
{annotated project tree}
## System Context
{C4 context diagram}
## Architecture Layers
{layer descriptions}
## Components
{component descriptions}
## Data Flow
{sequence diagrams}
## Technology Stack
{technology decisions}
## Architecture Decisions
{link to ADRs}
## Deployment
{deployment diagram}
```
## Section Templates
### Directory Structure Section
```markdown
## Directory Structure
```
project/
├── src/ # Source code
│ ├── Domain/ # Domain Layer (DDD)
│ │ ├── Entity/ # Domain entities
│ │ ├── ValueObject/ # Value objects
│ │ ├── Repository/ # Repository interfaces
│ │ ├── Service/ # Domain services
│ │ └── Event/ # Domain events
│ ├── Application/ # Application Layer
│ │ ├── UseCase/ # Use cases / Commands / Queries
│ │ ├── DTO/ # Data Transfer Objects
│ │ └── Service/ # Application services
│ ├── Infrastructure/ # Infrastructure Layer
│ │ ├── Persistence/ # Repository implementations
│ │ ├── Http/ # HTTP clients
│ │ ├── Messaging/ # Queue adapters
│ │ └── Cache/ # Cache adapters
│ └── Presentation/ # Presentation Layer
│ ├── Api/ # REST API (Actions, Requests, Responses)
│ ├── Web/ # Web controllers
│ └── Console/ # CLI commands
├── tests/ # Test suite
│ ├── Unit/ # Unit tests (mirrors src/)
│ ├── Integration/ # Integration tests
│ └── Functional/ # E2E / Functional tests
├── config/ # Configuration files
├── public/ # Web root
├── docker/ # Docker configuration
└── docs/ # Documentation
├── architecture/ # Architecture docs
├── adr/ # Architecture Decision Records
└── api/ # API documentation
```
### Generation Command
```bash
tree -L 3 -I 'vendor|node_modules|.git|var|cache' --dirsfirst
```
### Annotation Rules
| Rule | Description |
|------|-------------|
| Layer name | Add DDD layer in comment |
| Purpose | Describe directory purpose |
| Depth | Max 3 levels in main docs |
| Details | Link to subdirectory READMEs |
```
### Overview Section
```markdown
## Overview
{Project Name} follows {Architecture Style} (e.g., Clean Architecture, DDD, Hexagonal).
### Key Principles
- **Separation of Concerns** — Each layer has distinct responsibility
- **Dependency Rule** — Dependencies point inward (Domain is center)
- **Testability** — Business logic isolated from infrastructure
- **Framework Independence** — Core logic doesn't depend on frameworks
### High-Level Structure
```
┌─────────────────────────────────────────┐
│ Presentation Layer │
│ (Actions, Responders) │
├─────────────────────────────────────────┤
│ Application Layer │
│ (UseCases, Services) │
├─────────────────────────────────────────┤
│ Domain Layer │
│ (Entities, Value Objects, Events) │
├─────────────────────────────────────────┤
│ Infrastructure Layer │
│ (Repositories, Adapters, DB) │
└─────────────────────────────────────────┘
```
```
### System Context Section
```markdown
## System Context
```mermaid
flowchart TB
subgraph boundary["{System Name}"]
S[("{System}\n{Brief Description}")]
end
U1[("👤 {Actor 1}")]
U2[("👤 {Actor 2}")]
ES1[("📦 {External System 1}")]
ES2[("📦 {External System 2}")]
U1 -->|"{interaction}"| S
U2 -->|"{interaction}"| S
S -->|"{integration}"| ES1
S -->|"{integration}"| ES2
```
### Actors
| Actor | Description |
|-------|-------------|
| {Actor 1} | {Description} |
| {Actor 2} | {Description} |
### External Systems
| System | Purpose | Integration |
|--------|---------|-------------|
| {System 1} | {Purpose} | {Protocol/API} |
| {System 2} | {Purpose} | {Protocol/API} |
```
### Architecture Layers Section
```markdown
## Architecture Layers
### Presentation Layer
**Responsibility:** Handle HTTP requests and responses
**Components:**
- `Api/` — REST API endpoints (Actions + Responders)
- `Web/` — Web interface (Actions + Responders)
- `Console/` — CLI commands
**Rules:**
- No business logic
- Validate input
- Call Application layer
- Format output
### Application Layer
**Responsibility:** Orchestrate business operations
**Components:**
- `UseCase/` — Application-specific business rules
- `Service/` — Cross-cutting application services
- `DTO/` — Data transfer objects
**Rules:**
- Orchestrate Domain objects
- Handle transactions
- No infrastructure concerns
### Domain Layer
**Responsibility:** Core business logic
**Components:**
- `Entity/` — Business objects with identity
- `ValueObject/` — Immutable value concepts
- `Event/` — Domain events
- `Repository/` — Repository interfaces
- `Service/` — Domain services
**Rules:**
- No external dependencies
- Pure business logic
- Self-validating objects
### Infrastructure Layer
**Responsibility:** Technical implementations
**Components:**
- `Persistence/` — Repository implementations
- `Adapter/` — External service adapters
- `Cache/` — Caching implementations
- `Queue/` — Queue implementations
**Rules:**
- Implement Domain interfaces
- Handle technical concerns
- No business logic
```
### Components Section
```markdown
## Components
```mermaid
flowchart TB
subgraph presentation[Presentation Layer]
AC[Action]
RS[Responder]
end
subgraph application[Application Layer]
UC[UseCase]
AS[AppService]
end
subgraph domain[Domain Layer]
EN[Entity]
VO[ValueObject]
DE[DomainEvent]
RI[Repository<br/>Interface]
end
subgraph infrastructure[Infrastructure Layer]
RP[Repository<br/>Impl]
AD[Adapter]
CA[Cache]
end
AC --> UC
UC --> EN
UC --> RI
RP -.-> RI
RP --> CA
```
### Component Descriptions
| Component | Layer | Responsibility |
|-----------|-------|----------------|
| Action | Presentation | HTTP request handling |
| Responder | Presentation | HTTP response building |
| UseCase | Application | Business operation orchestration |
| Entity | Domain | Business object with identity |
| ValueObject | Domain | Immutable value concept |
| Repository | Infrastructure | Data persistence |
```
### Data Flow Section
```markdown
## Data Flow
### {Operation Name} Flow
```mermaid
sequenceDiagram
participant C as Client
participant A as Action
participant U as UseCase
participant E as Entity
participant R as Repository
participant D as Database
C->>A: {Request}
A->>A: Validate & Map to DTO
A->>U: Execute(dto)
U->>R: find(id)
R->>D: SELECT
D-->>R: row
R-->>U: entity
U->>E: {operation}()
E-->>U: result
U->>R: save(entity)
R->>D: UPDATE
D-->>R: ok
U-->>A: Result
A->>A: Build Response
A-->>C: {Response}
```
```
### Technology Stack Section
```markdown
## Technology Stack
| Layer | Technology | Purpose |
|-------|------------|---------|
| Language | PHP 8.4 | Type safety, modern features |
| Framework | Symfony 7.x | HTTP, DI, Console |
| ORM | Doctrine 3.x | Database abstraction |
| Database | PostgreSQL 16 | Primary storage |
| Cache | Redis 7.x | Session, cache |
| Queue | RabbitMQ 3.x | Async processing |
| API | OpenAPI 3.1 | API specification |
### Technology Decisions
| Decision | Rationale |
|----------|-----------|
| PostgreSQL over MySQL | JSONB support, better type system |
| Symfony over Laravel | More explicit, better DI |
| Redis over Memcached | Data structures, persistence |
```
### ADR Link Section
```markdown
## Architecture Decisions
Key decisions are documented as ADRs:
| ADR | Status | Title |
|-----|--------|-------|
| [ADR-001](docs/adr/001-use-ddd.md) | Accepted | Use DDD Architecture |
| [ADR-002](docs/adr/002-cqrs.md) | Accepted | Implement CQRS |
| [ADR-003](docs/adr/003-event-sourcing.md) | Proposed | Consider Event Sourcing |
```
## Complete Example
```markdown
# Architecture
## Overview
Order Management System follows Domain-Driven Design with Clean Architecture principles.
### Key Principles
- **Domain-Centric** — Business logic in Domain layer
- **Dependency Inversion** — Abstractions over implementations
- **Bounded Contexts** — Order, Inventory, Shipping
## Directory Structure
```
order-management/
├── src/
│ ├── Order/ # Order Bounded Context
│ │ ├── Domain/ # Domain Layer
│ │ ├── Application/ # Application Layer
│ │ ├── Infrastructure/ # Infrastructure Layer
│ │ └── Presentation/ # Presentation Layer
│ ├── Inventory/ # Inventory Bounded Context
│ └── Shipping/ # Shipping Bounded Context
├── tests/
├── config/
└── docs/
```
## System Context
```mermaid
flowchart TB
subgraph boundary["Order Management System"]
S[("📦 OMS\nManages orders lifecycle")]
end
Customer[("👤 Customer")]
Admin[("👤 Admin")]
Payment[("💳 Payment Gateway")]
Shipping[("🚚 Shipping Provider")]
Customer -->|"Place orders"| S
Admin -->|"Manage orders"| S
S -->|"Process payments"| Payment
S -->|"Ship orders"| Shipping
```
## Architecture Layers
[... layer descriptions ...]
## Technology Stack
| Layer | Technology | Purpose |
|-------|------------|---------|
| Language | PHP 8.4 | Type safety |
| Framework | Symfony 7.2 | HTTP, DI |
| Database | PostgreSQL 16 | Storage |
| Cache | Redis 7.4 | Performance |
| Queue | RabbitMQ 3.13 | Async |
## Architecture Decisions
| ADR | Status | Title |
|-----|--------|-------|
| [ADR-001](docs/adr/001-ddd.md) | Accepted | Use DDD |
| [ADR-002](docs/adr/002-cqrs.md) | Accepted | Use CQRS |
```
## Generation Instructions
When generating ARCHITECTURE.md:
1. **Analyze** project structure for layer organization
2. **Identify** architectural style (DDD, Clean, Hexagonal)
3. **Map** components to layers
4. **Create** context diagram with actors/systems
5. **Generate** component diagram
6. **List** technology stack from `composer.json`
7. **Link** existing ADRs if presentRelated Skills
troubleshooting-template
Generates troubleshooting guides and FAQ sections for PHP projects. Creates problem-solution documentation.
mermaid-template
Generates Mermaid diagrams for technical documentation. Provides templates for flowcharts, sequence diagrams, class diagrams, ER diagrams, and C4 models.
getting-started-template
Generates Getting Started guides for PHP projects. Creates step-by-step tutorials for first-time users.
explain-output-template
Output format templates for all 5 explanation modes — quick (compact), deep (full analysis with diagrams), onboarding (project guide), business (non-technical), qa (interactive Q&A).
detect-architecture-pattern
Detects architectural patterns (MVC, DDD, Hexagonal, CQRS, Layered, Event Sourcing, Microservice) from namespace structure, interface placement, and dependency direction. Outputs confidence score per pattern.
create-template-method
Generates Template Method pattern for PHP 8.4. Creates abstract algorithm skeleton with customizable steps, allowing subclasses to override specific parts without changing structure. Includes unit tests.
create-docker-env-template
Generates Docker environment templates for PHP projects. Creates .env.docker files with service configurations and documentation.
code-examples-template
Generates code examples for PHP documentation. Creates minimal, copy-paste ready examples with expected output.
changelog-template
Generates CHANGELOG.md files following Keep a Changelog format. Creates version history documentation.
api-doc-template
Generates API documentation for PHP projects. Creates endpoint documentation with parameters, responses, and examples.
adr-template
Generates Architecture Decision Records (ADR) for PHP projects. Creates structured decision documentation with context, decision, and consequences.
yii-knowledge
Yii framework knowledge base. Provides Yii3 modular architecture, DDD integration, PSR-7/PSR-15 compliance, persistence, DI, security (RBAC, auth), event system (PSR-14), queue/jobs, infrastructure components (cache, rate limiter, HTTP client), testing, and antipatterns for Yii PHP projects.