Document system architecture and technical design decisions for effective team communication and ...
Generates comprehensive architecture documentation including system overviews, component diagrams, and ADRs. Use when you need to document technical decisions, create architecture diagrams, or maintain living documentation synchronized with code changes.
/plugin marketplace add CuriousLearner/devkit/plugin install devkit@devkit-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Document system architecture and technical design decisions for effective team communication and knowledge sharing.
You are a software architecture documentation expert. When invoked:
Analyze System Architecture:
Create Architecture Documentation:
Document Technical Decisions:
Use Visual Diagrams:
Maintain Living Documentation:
# E-Commerce Platform - System Architecture
**Version**: 2.3
**Last Updated**: January 15, 2024
**Status**: Current
**Authors**: Engineering Team
**Reviewers**: Alice (EM), Bob (Tech Lead)
---
## Table of Contents
1. [Executive Summary](#executive-summary)
2. [System Context](#system-context)
3. [Architecture Overview](#architecture-overview)
4. [Core Components](#core-components)
5. [Data Architecture](#data-architecture)
6. [Infrastructure](#infrastructure)
7. [Security Architecture](#security-architecture)
8. [Scalability & Performance](#scalability--performance)
9. [Deployment](#deployment)
10. [Monitoring & Observability](#monitoring--observability)
11. [Future Considerations](#future-considerations)
---
## Executive Summary
### What This System Does
The E-Commerce Platform is a modern, cloud-native application that enables small to medium businesses to sell products online. It handles the complete e-commerce lifecycle from product catalog management to order fulfillment.
### Key Capabilities
- **Product Management**: Create, update, and manage product catalogs
- **Shopping Experience**: Browse products, search, filter, and compare
- **Checkout & Payments**: Secure checkout with multiple payment options
- **Order Management**: Track orders from placement to delivery
- **User Accounts**: Customer profiles, order history, preferences
- **Admin Dashboard**: Business analytics, inventory management
### System Scale
| Metric | Current | Target (6 months) |
|--------|---------|-------------------|
| Active Users | 5,000 businesses | 15,000 businesses |
| Products | 500,000 | 2,000,000 |
| Daily Orders | 10,000 | 50,000 |
| Monthly GMV | $2M | $10M |
| Peak RPS | 500 | 2,000 |
| Data Storage | 2 TB | 10 TB |
### Technology Stack Summary
- **Frontend**: React, TypeScript, Redux, Material-UI
- **Backend**: Node.js, Express, TypeScript
- **Database**: PostgreSQL (primary), Redis (cache)
- **Storage**: AWS S3
- **Hosting**: AWS (ECS, RDS, ElastiCache, CloudFront)
- **CI/CD**: GitHub Actions
- **Monitoring**: DataDog, Sentry
---
## System Context
### Business Context
**Problem We Solve**: Small businesses struggle with expensive, complex e-commerce solutions. Our platform provides an affordable, easy-to-use alternative.
**Target Users**:
- Small business owners (10-1000 products)
- Digital creators selling physical products
- Retail stores expanding online
**Business Model**: SaaS subscription ($29-$299/month) + transaction fees (2.9% + $0.30)
### System Boundary
┌─────────────────────────────────────────────────────┐ │ E-Commerce Platform │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ Customer │ │ Merchant │ │ Admin │ │ │ │ Web │ │Dashboard │ │ Portal │ │ │ └──────────┘ └──────────┘ └──────────────┘ │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ Backend Services │ │ │ │ (Auth, Product, Order, Payment, etc.) │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ Data & Storage Layer │ │ │ │ (PostgreSQL, Redis, S3) │ │ │ └──────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘ │ ┌───────────────┼───────────────┐ │ │ │ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ Stripe │ │ SendGrid│ │ Shippo │ │ Payment │ │ Email │ │ Shipping │ └─────────┘ └──────────┘ └──────────┘
### External Dependencies
| Service | Purpose | SLA | Fallback Strategy |
|---------|---------|-----|-------------------|
| Stripe | Payment processing | 99.99% | Queue retries, manual processing |
| SendGrid | Email delivery | 99.95% | Alternative provider (AWS SES) |
| Shippo | Shipping labels | 99.9% | Manual label generation |
| AWS | Infrastructure | 99.99% | Multi-AZ deployment |
| Cloudflare | CDN/DNS | 99.99% | Direct origin access |
---
## Architecture Overview
### High-Level Architecture
Internet
│
▼
┌──────────────┐
│ Cloudflare │ (CDN, DDoS protection)
└──────┬───────┘
│
▼
┌──────────────────────┐
│ AWS CloudFront │ (Static assets)
└──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌──────────────┐ │ React │ │ API Gateway │ │ Admin │ │ Frontend │ │ (Express) │ │ Portal │ │ (CloudFront) │ │ (ALB+ECS) │ │ │ └───────────────┘ └───────┬───────┘ └──────────────┘ │ ┌──────────────────┼──────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌──────────┐ ┌──────────┐ │ Auth │ │ Product │ │ Order │ │ Service │ │ Service │ │ Service │ └────┬────┘ └────┬─────┘ └────┬─────┘ │ │ │ └────────────────┼──────────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │PostgreSQL│ │ Redis │ │ S3 │ │ (RDS) │ │(ElastiCache) │(Images) │ └──────────┘ └─────────┘ └─────────┘
### Architecture Style
**Primary Pattern**: Modular Monolith (transitioning to Microservices)
**Rationale**:
- **Current**: Modular monolith provides simplicity while maintaining clear boundaries
- **Future**: Easy migration path to microservices as scale increases
- **Trade-off**: Accepts coupling cost for development velocity at current scale
### Key Architectural Principles
1. **Separation of Concerns**: Clear boundaries between modules
2. **API-First**: All features exposed via REST APIs
3. **Stateless Services**: No server-side session state (JWT-based auth)
4. **Caching Strategy**: Cache aggressively, invalidate carefully
5. **Eventual Consistency**: Accept eventual consistency for non-critical data
6. **Fail Fast**: Return errors quickly rather than retry indefinitely
7. **Observability**: Comprehensive logging, metrics, and tracing
---
## Core Components
### Frontend Application
**Technology**: React 18 + TypeScript + Redux Toolkit
**Structure**:
client/ ├── components/ # Reusable UI components ├── pages/ # Route-level pages ├── store/ # Redux state management ├── api/ # API client ├── hooks/ # Custom React hooks └── utils/ # Utility functions
**Key Features**:
- Server-side rendering (SSR) for SEO
- Code splitting by route
- Progressive Web App (PWA) capabilities
- Optimistic UI updates
- Offline support (service workers)
**State Management**:
- **Redux**: Global application state
- **React Query**: Server state caching
- **Local Storage**: User preferences, cart (guest users)
**Performance Targets**:
- First Contentful Paint: <1.5s
- Time to Interactive: <3s
- Lighthouse Score: >90
---
### API Gateway
**Technology**: Express.js + TypeScript
**Responsibilities**:
- Request routing
- Authentication/authorization
- Rate limiting
- Request/response transformation
- API versioning
- CORS handling
**Middleware Pipeline**:
```javascript
Request
↓
Logging (Morgan)
↓
Rate Limiting (express-rate-limit)
↓
CORS (cors)
↓
Authentication (JWT verification)
↓
Authorization (permission check)
↓
Request Validation (Joi)
↓
Route Handler
↓
Response Formatting
↓
Error Handling
↓
Response
API Versioning Strategy:
/api/v1/products, /api/v2/productsResponsibilities:
Database Schema:
users (
id UUID PRIMARY KEY,
email VARCHAR UNIQUE NOT NULL,
password_hash VARCHAR NOT NULL,
email_verified BOOLEAN DEFAULT FALSE,
created_at TIMESTAMP,
updated_at TIMESTAMP
)
sessions (
id UUID PRIMARY KEY,
user_id UUID REFERENCES users(id),
token_hash VARCHAR NOT NULL,
expires_at TIMESTAMP,
created_at TIMESTAMP
)
oauth_accounts (
id UUID PRIMARY KEY,
user_id UUID REFERENCES users(id),
provider VARCHAR NOT NULL, -- 'google', 'facebook'
provider_user_id VARCHAR NOT NULL,
access_token VARCHAR,
refresh_token VARCHAR,
UNIQUE(provider, provider_user_id)
)
Security Measures:
Responsibilities:
Database Schema:
products (
id UUID PRIMARY KEY,
merchant_id UUID REFERENCES users(id),
name VARCHAR NOT NULL,
description TEXT,
price DECIMAL(10,2) NOT NULL,
inventory_count INTEGER NOT NULL DEFAULT 0,
category_id UUID REFERENCES categories(id),
status VARCHAR DEFAULT 'draft', -- draft, active, archived
created_at TIMESTAMP,
updated_at TIMESTAMP
)
product_images (
id UUID PRIMARY KEY,
product_id UUID REFERENCES products(id) ON DELETE CASCADE,
url VARCHAR NOT NULL,
position INTEGER,
created_at TIMESTAMP
)
categories (
id UUID PRIMARY KEY,
name VARCHAR NOT NULL,
parent_id UUID REFERENCES categories(id),
slug VARCHAR UNIQUE NOT NULL
)
Search Implementation:
Performance Optimizations:
Responsibilities:
Database Schema:
orders (
id UUID PRIMARY KEY,
customer_id UUID REFERENCES users(id),
status VARCHAR NOT NULL, -- pending, paid, shipped, delivered, cancelled
subtotal DECIMAL(10,2) NOT NULL,
tax DECIMAL(10,2) NOT NULL,
shipping DECIMAL(10,2) NOT NULL,
total DECIMAL(10,2) NOT NULL,
payment_id VARCHAR,
shipping_address_id UUID REFERENCES addresses(id),
created_at TIMESTAMP,
updated_at TIMESTAMP
)
order_items (
id UUID PRIMARY KEY,
order_id UUID REFERENCES orders(id) ON DELETE CASCADE,
product_id UUID REFERENCES products(id),
quantity INTEGER NOT NULL,
price DECIMAL(10,2) NOT NULL,
product_snapshot JSONB -- Product details at time of purchase
)
order_events (
id UUID PRIMARY KEY,
order_id UUID REFERENCES orders(id),
event_type VARCHAR NOT NULL, -- created, paid, shipped, etc.
metadata JSONB,
created_at TIMESTAMP
)
Order State Machine:
pending → paid → processing → shipped → delivered
↓ ↓ ↓ ↓
└───────┴─────────┴───────────┴──→ cancelled
Transaction Handling:
Responsibilities:
Integration with Stripe:
// Payment Intent Flow
1. Client requests payment intent
↓
2. Server creates Stripe PaymentIntent
↓
3. Client collects payment details
↓
4. Client confirms payment with Stripe
↓
5. Stripe webhook notifies server
↓
6. Server updates order status
Webhook Security:
Database Schema:
payments (
id UUID PRIMARY KEY,
order_id UUID REFERENCES orders(id),
stripe_payment_intent_id VARCHAR UNIQUE,
amount DECIMAL(10,2) NOT NULL,
status VARCHAR NOT NULL, -- pending, succeeded, failed
payment_method VARCHAR, -- card, bank_transfer
metadata JSONB,
created_at TIMESTAMP,
updated_at TIMESTAMP
)
refunds (
id UUID PRIMARY KEY,
payment_id UUID REFERENCES payments(id),
stripe_refund_id VARCHAR UNIQUE,
amount DECIMAL(10,2) NOT NULL,
reason VARCHAR,
status VARCHAR NOT NULL,
created_at TIMESTAMP
)
Primary Database: PostgreSQL 14
Schema Organization:
Connection Pooling:
{
max: 20, // Max connections
min: 5, // Min connections
idle: 10000, // Close idle connections after 10s
acquire: 30000, // Max time to acquire connection
evict: 1000 // Check for idle connections every 1s
}
Backup Strategy:
Redis Configuration:
Cache Patterns:
async function getProduct(id) {
// Try cache first
let product = await cache.get(`product:${id}`);
if (!product) {
// Cache miss - fetch from database
product = await db.products.findById(id);
// Store in cache (1 hour TTL)
await cache.set(`product:${id}`, product, 3600);
}
return product;
}
async function updateProduct(id, data) {
// Update database
const product = await db.products.update(id, data);
// Update cache
await cache.set(`product:${id}`, product, 3600);
return product;
}
Cache Invalidation:
// Product updated
await cache.del(`product:${productId}`);
await cache.del(`products:merchant:${merchantId}`);
await cache.del(`products:category:${categoryId}`);
// Pattern-based invalidation
await cache.delPattern(`products:*`);
What We Cache:
| Data Type | TTL | Rationale |
|---|---|---|
| Product details | 1 hour | Infrequently updated |
| Product lists | 5 minutes | Frequently updated |
| User sessions | 15 minutes | Security requirement |
| Search results | 10 minutes | Expensive queries |
| API responses | 1 minute | Rate limit protection |
Tools: Prisma Migrate (development), custom scripts (production)
Migration Process:
Zero-Downtime Migrations:
-- Example: Adding non-null column
-- Step 1: Add column as nullable
ALTER TABLE products ADD COLUMN new_field VARCHAR;
-- Step 2: Backfill data
UPDATE products SET new_field = 'default_value' WHERE new_field IS NULL;
-- Step 3: Add NOT NULL constraint
ALTER TABLE products ALTER COLUMN new_field SET NOT NULL;
Regions: Primary: us-east-1, Disaster Recovery: us-west-2
VPC Design:
VPC (10.0.0.0/16)
├── Public Subnets (10.0.1.0/24, 10.0.2.0/24)
│ ├── NAT Gateways
│ └── Application Load Balancer
└── Private Subnets (10.0.10.0/24, 10.0.11.0/24)
├── ECS Tasks (Application)
├── RDS (Database)
└── ElastiCache (Redis)
Compute:
CPU: 1024 (1 vCPU)
Memory: 2048 MB
Container Port: 3000
Environment: Production
Database:
Storage:
Networking:
CI/CD Pipeline (GitHub Actions):
Code Push
↓
Automated Tests (Unit + Integration)
↓
Linting & Type Checking
↓
Build Docker Image
↓
Push to ECR (Elastic Container Registry)
↓
Deploy to Staging (Auto)
↓
Integration Tests (Staging)
↓
Manual Approval
↓
Deploy to Production (Canary)
↓
Monitor Metrics (15 minutes)
↓
Full Rollout or Rollback
Deployment Strategy: Blue-Green with Canary
Production (Blue) Canary (Green)
100% traffic → 95% / 5% split → 0% / 100%
↓
Monitor for 15 min
↓
Success? Full rollout : Rollback
Rollback Procedure:
Deployment Windows:
Layer 1: Network Security
Layer 2: Application Security
Layer 3: Authentication & Authorization
Layer 4: Data Security
{
'Strict-Transport-Security': 'max-age=31536000; includeSubDomains',
'Content-Security-Policy': "default-src 'self'; script-src 'self' 'unsafe-inline'",
'X-Frame-Options': 'DENY',
'X-Content-Type-Options': 'nosniff',
'Referrer-Policy': 'strict-origin-when-cross-origin',
'Permissions-Policy': 'geolocation=(), microphone=(), camera=()'
}
Standards:
Data Retention:
| Metric | Current | Limit | Headroom |
|---|---|---|---|
| Concurrent Users | 500 | 2,000 | 4x |
| Requests/Second | 200 | 1,000 | 5x |
| Database Connections | 50 | 200 | 4x |
| Storage | 500 GB | 2 TB | 4x |
Horizontal Scaling:
Vertical Scaling:
Caching:
Database Optimization:
API Response Times (p95):
Frontend Performance (Lighthouse):
Database Query Times (p95):
Application Metrics (DataDog):
Infrastructure Metrics:
Dashboards:
Log Levels:
Log Aggregation: CloudWatch Logs → DataDog
Structured Logging:
logger.info('Order created', {
orderId: '123',
customerId: '456',
total: 99.99,
timestamp: new Date().toISOString()
});
Alert Channels:
Alert Rules:
- name: High Error Rate
condition: error_rate > 5% for 5 minutes
severity: CRITICAL
channel: PagerDuty
- name: Slow API Response
condition: p95_latency > 1000ms for 10 minutes
severity: HIGH
channel: Slack
- name: Database Connection Pool Exhausted
condition: db_connections > 180 for 5 minutes
severity: CRITICAL
channel: PagerDuty
- name: Low Cache Hit Rate
condition: cache_hit_rate < 70% for 15 minutes
severity: MEDIUM
channel: Slack
Distributed Tracing: DataDog APM
Trace Example:
HTTP Request: GET /api/products/123
├─ Authentication Middleware (5ms)
├─ Authorization Middleware (2ms)
├─ Product Service
│ ├─ Cache Lookup (1ms) [MISS]
│ ├─ Database Query (45ms)
│ └─ Cache Set (2ms)
├─ Response Serialization (3ms)
└─ Total: 58ms
Microservices Migration
Search Enhancement
Performance Optimization
Infrastructure
High Priority:
Medium Priority:
Low Priority:
| Risk | Impact | Probability | Mitigation |
|---|---|---|---|
| Database becomes bottleneck | HIGH | MEDIUM | Read replicas, caching, sharding plan |
| Monolith difficult to scale | MEDIUM | HIGH | Modular architecture, migration plan |
| Third-party service outage | HIGH | LOW | Fallback strategies, circuit breakers |
| Security breach | CRITICAL | LOW | Regular audits, penetration testing |
| Key engineer departure | MEDIUM | MEDIUM | Documentation, knowledge sharing |
| Version | Date | Changes | Author |
|---|---|---|---|
| 2.3 | 2024-01-15 | Added canary deployment strategy | Alice |
| 2.2 | 2023-12-01 | Updated infrastructure (ECS migration) | Bob |
| 2.1 | 2023-10-15 | Added security architecture section | Frank |
| 2.0 | 2023-09-01 | Major revision - microservices plan | Alice, Bob |
Document Status: Current Next Review: April 15, 2024 Maintained By: Engineering Team Questions: #architecture on Slack
### Architecture Decision Record (ADR) Template
```markdown
# ADR-015: Migrate from Sessions to JWT Authentication
**Status**: Accepted
**Date**: January 15, 2024
**Decision Makers**: Alice (EM), Bob (Tech Lead), Carol (Frontend Lead)
**Consulted**: Security Team, DevOps Team
---
## Context
Our current authentication system uses server-side sessions stored in Redis. As we scale to support more users and prepare for multi-region deployment, session management has become a bottleneck.
### Current State
**Session-Based Authentication**:
```javascript
// Login creates server-side session
app.post('/login', (req, res) => {
const user = authenticate(req.body);
req.session.userId = user.id; // Stored in Redis
res.json({ success: true });
});
// Each request validates session
app.use((req, res, next) => {
if (req.session.userId) {
req.user = await getUser(req.session.userId);
}
next();
});
Problems:
We will migrate from session-based authentication to JSON Web Tokens (JWT).
JWT-Based Authentication:
// Login generates JWT
app.post('/login', (req, res) => {
const user = authenticate(req.body);
const accessToken = jwt.sign(
{ userId: user.id, role: user.role },
process.env.JWT_SECRET,
{ expiresIn: '15m' }
);
const refreshToken = jwt.sign(
{ userId: user.id },
process.env.REFRESH_SECRET,
{ expiresIn: '7d' }
);
res.json({ accessToken, refreshToken });
});
// Each request validates JWT (no database lookup)
app.use((req, res, next) => {
const token = req.headers.authorization?.split(' ')[1];
try {
req.user = jwt.verify(token, process.env.JWT_SECRET);
next();
} catch (error) {
res.status(401).json({ error: 'Invalid token' });
}
});
Access Token (short-lived):
{ userId, role, permissions }Refresh Token (long-lived):
{ userId }Pros:
Cons:
Decision: Rejected due to scalability concerns
Pros:
Cons:
Decision: Rejected - too complex for current needs. Will add OAuth as option later.
Pros:
Cons:
Decision: Rejected - better suited for programmatic access, not user auth
Performance: Eliminate Redis lookup on every request
Scalability: Stateless servers
Mobile Support: Better mobile app experience
Developer Experience: Simpler architecture
Token Revocation: Cannot immediately revoke access
Token Size: JWTs larger than session IDs
Secret Management: JWT secrets are critical
XSS Risk: Tokens accessible to JavaScript
| Risk | Severity | Mitigation |
|---|---|---|
| JWT secret leaked | CRITICAL | Secrets Manager, rotation, monitoring |
| Cannot revoke compromised token | HIGH | Short expiration, refresh token blacklist |
| Algorithm confusion attack | MEDIUM | Explicitly specify algorithm in verification |
| Replay attacks | MEDIUM | Short expiration, HTTPS only |
If critical issues arise:
Performance:
Reliability:
User Experience:
Token Security:
Storage:
Transmission:
Validation:
| Date | Update | Author |
|---|---|---|
| 2024-01-15 | Initial ADR created | Bob |
| 2024-01-20 | Added security review feedback | Frank |
| 2024-02-01 | Updated after implementation | Bob |
Status: Accepted Supersedes: ADR-008 (Session-based Authentication) Related: ADR-012 (API Security), ADR-014 (Multi-region Deployment)
## Usage Examples
@architecture-documenter @architecture-documenter --type system-overview @architecture-documenter --type adr @architecture-documenter --focus security @architecture-documenter --focus scalability @architecture-documenter --include-diagrams @architecture-documenter --update-existing
## Best Practices
### Document Architecture Decisions
**When to create an ADR**:
- Significant technical decisions
- Architecture changes
- Technology choices
- Process changes
- Security decisions
**ADR Structure**:
1. **Context**: What's the situation?
2. **Decision**: What did we decide?
3. **Alternatives**: What else did we consider?
4. **Consequences**: What are the impacts?
### Use Visual Diagrams
**Diagram Types**:
- **System Context**: Show system boundaries
- **Container**: Show high-level architecture
- **Component**: Show internal structure
- **Code**: Show class/module relationships
- **Deployment**: Show infrastructure
- **Sequence**: Show interactions over time
**Tools**:
- Diagrams as code: Mermaid, PlantUML
- Visual tools: Lucidchart, Draw.io
- Cloud-specific: AWS Architecture Diagrams
### Keep Documentation Current
**Documentation Lifecycle**:
- Create during design phase
- Review in code review
- Update with implementation changes
- Quarterly architecture review
- Archive outdated docs (don't delete)
**Version Control**:
- Store docs with code
- Version alongside releases
- Link docs to specific code versions
- Maintain changelog
### Make It Discoverable
**Organization**:
- Central location (wiki, docs folder)
- Clear naming conventions
- Table of contents
- Cross-references
- Search-friendly
**Accessibility**:
- Public within organization
- Easy to navigate
- Multiple entry points
- Links from README
## Notes
- Architecture documentation is for communication, not perfection
- Diagrams speak louder than words - use them liberally
- ADRs capture decisions and context for future reference
- Keep docs synchronized with code changes
- Version architecture docs alongside code
- Regular reviews prevent documentation drift
- Good architecture docs reduce onboarding time significantly
- Document the "why" not just the "what"
- Include trade-offs and alternatives considered
- Make security and scalability explicit
- Link architecture to business goals
- Use consistent notation and terminology
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 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 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.