acc-architecture-doc-template
Generates ARCHITECTURE.md files for PHP projects. Creates layer documentation, component descriptions, and architectural diagrams.
Best use case
acc-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 acc-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/acc-architecture-doc-template/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How acc-architecture-doc-template Compares
| Feature / Agent | acc-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.5 | 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.5 | 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
acc-api-doc-template
Generates API documentation for PHP projects. Creates endpoint documentation with parameters, responses, and examples.
acc-adr-template
Generates Architecture Decision Records (ADR) for PHP projects. Creates structured decision documentation with context, decision, and consequences.
1k-architecture
OneKey monorepo architecture and code organization. Use when understanding project structure, package relationships, import rules, or component organization. Triggers on architecture, structure, packages, imports, hierarchy, dependencies, monorepo, organization.
notion-template-business
Expert in building and selling Notion templates as a business - not just making templates, but building a sustainable digital product business. Covers template design, pricing, marketplaces, market...
microservices-architecture
Microservices architecture patterns and best practices. Use when designing distributed systems, breaking down monoliths, or implementing service communication.
architecture-patterns
Padrões de arquitetura de software - Decisões OBJETIVAS sobre design de sistemas
rails-architecture
Guides modern Rails 8 code architecture decisions and patterns. Use when deciding where to put code, choosing between patterns (service objects vs concerns vs query objects), designing feature architecture, refactoring for better organization, or when user mentions architecture, code organization, design patterns, or layered design.
mvvm-architecture
Expert MVVM decisions for iOS/tvOS: choosing between ViewModel patterns (state enum vs published properties vs Combine), service layer boundaries, dependency injection strategies, and testing approaches. Use when designing ViewModel architecture, debugging data flow issues, or deciding where business logic belongs. Trigger keywords: MVVM, ViewModel, ObservableObject, @StateObject, service layer, dependency injection, unit test, mock, architecture
MCP Architecture Expert
Design and implement Model Context Protocol servers for standardized AI-to-data integration with resources, tools, prompts, and security best practices
architecture-paradigm-pipeline
Consult this skill when designing data pipelines or transformation workflows. Use when data flows through fixed sequence of transformations, stages can be independently developed and tested, parallel processing of stages is beneficial. Do not use when selecting from multiple paradigms - use architecture-paradigms first. DO NOT use when: data flow is not sequential or predictable. DO NOT use when: complex branching/merging logic dominates.
architecture-advisor
Helps solo developers with AI agents choose optimal architecture (monolithic/microservices/hybrid)
aidf-task-templates
Task template definitions for AIDF. Provides structured templates for component, refactor, test, docs, architecture, and bugfix task types.