DO NOT invoke directly - loaded by workflow agents via cc10x-router. Always loaded by: planner, integration-verifier. Conditionally loaded by: code-reviewer (API code), component-builder (API endpoint), bug-investigator (integration issue). Provides architecture patterns: system design, API design, integrations, data models. Iron Law: DESIGN ARCHITECTURE FROM FUNCTIONALITY.
/plugin marketplace add romiluz13/cc10x/plugin install cc10x@cc10xThis skill is limited to using the following tools:
Architecture exists to support functionality. Every architectural decision should trace back to a functionality requirement.
Core principle: Design architecture FROM functionality, not TO functionality.
Violating the letter of this process is violating the spirit of architecture.
NO ARCHITECTURE DESIGN BEFORE FUNCTIONALITY FLOWS ARE MAPPED
If you haven't documented user flows, admin flows, and system flows, you cannot design architecture.
First, determine what kind of architectural work is needed:
| Request Type | Route To |
|---|---|
| "Design API endpoints" | API Design section |
| "Plan system architecture" | Full Architecture Design |
| "Design data models" | Data Model section |
| "Plan integrations" | Integration Patterns section |
| "Make decisions" | Decision Framework section |
ALWAYS answer before designing:
Before any architecture:
User Flow (example):
1. User opens upload page
2. User selects file
3. System validates file type/size
4. System uploads to storage
5. System shows success message
Admin Flow (example):
1. Admin opens dashboard
2. Admin views all uploads
3. Admin can delete uploads
4. System logs admin action
System Flow (example):
1. Request received at API
2. Auth middleware validates token
3. Service processes request
4. Database stores data
5. Response returned
Each flow maps to components:
| Flow Step | Architecture Component |
|---|---|
| User opens page | Frontend route + component |
| User submits data | API endpoint |
| System validates | Validation service |
| System processes | Business logic service |
| System stores | Database + repository |
| System integrates | External client/adapter |
For each component, define:
┌─────────────────────────────────────────────┐
│ SYSTEM │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Web │ │ API │ │Database │ │
│ │ App │──│ Service │──│ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────┘
│ │ │
┌──┴──┐ ┌──┴──┐ ┌──┴──┐
│User │ │Admin│ │ Ext │
└─────┘ └─────┘ └─────┘
Map user flows to endpoints:
User Flow: Upload file
→ POST /api/files
Request: { file: binary, metadata: {...} }
Response: { id: string, url: string }
Errors: 400 (invalid), 413 (too large), 500 (storage failed)
User Flow: View file
→ GET /api/files/:id
Response: { id, url, metadata, createdAt }
Errors: 404 (not found), 403 (not authorized)
Admin Flow: Delete file
→ DELETE /api/files/:id
Response: { success: true }
Errors: 404, 403
API Design Checklist:
Map integration requirements to patterns:
| Requirement | Pattern |
|---|---|
| Flaky external service | Retry with exponential backoff |
| Slow external service | Circuit breaker + timeout |
| Async processing needed | Message queue |
| Real-time updates needed | WebSocket/SSE |
| Data sync needed | Event sourcing |
For each integration:
### [Integration Name]
**Functionality**: What user flow depends on this?
**Pattern**: [Retry/Circuit breaker/Queue/etc]
**Error handling**: What happens when it fails?
**Fallback**: What's the degraded experience?
For each architectural decision:
### Decision: [Title]
**Context**: What functionality requirement drives this?
**Options**:
1. [Option A] - [Brief description]
2. [Option B] - [Brief description]
3. [Option C] - [Brief description]
**Trade-offs**:
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
| Performance | Good | Better | Best |
| Complexity | Low | Medium | High |
| Cost | Low | Medium | High |
**Decision**: [Option chosen]
**Rationale**: [Why this option best supports functionality]
If you find yourself:
STOP. Go back to functionality flows.
| Excuse | Reality |
|---|---|
| "This pattern is industry standard" | Does it support THIS functionality? |
| "We might need it later" | YAGNI. Design for now. |
| "Microservices are better" | For this functionality? Justify it. |
| "Everyone uses this" | That's not a trade-off analysis. |
| "It's more flexible" | Flexibility without need = complexity. |
# Architecture Design: [Feature/System Name]
## Functionality Summary
[What this architecture supports - trace to user value]
## Flows Mapped
### User Flows
1. [Flow 1 steps]
2. [Flow 2 steps]
### System Flows
1. [Flow 1 steps]
2. [Flow 2 steps]
## Architecture
### System Context
[Diagram or description of actors and system boundaries]
### Components
| Component | Purpose (Functionality) | Dependencies |
|-----------|------------------------|--------------|
| [Name] | [What flow it supports] | [What it needs] |
### API Endpoints
| Endpoint | Flow | Request | Response |
|----------|------|---------|----------|
| POST /api/x | User uploads | {...} | {...} |
## Key Decisions
### Decision 1: [Title]
- Context: [Functionality driver]
- Options: [List]
- Trade-offs: [Table]
- Decision: [Choice]
- Rationale: [Why]
## Implementation Roadmap
### Critical (Must have for core flow)
1. [Component/feature]
### Important (Completes flows)
1. [Component/feature]
### Enhancement (Improves experience)
1. [Component/feature]
Before completing architecture design:
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.