/elegant-architecture
Guides clean architecture design with strict 200-line file limits. Use when starting new features, refactoring large files, or planning module structure. Enforces modular design and real testing.
$ npx -y skills add majiayu000/spellbook --skill elegant-architecture --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/elegant-architecture
Context preview
The summary Claude sees to decide when to auto-load this skill.
Guides clean architecture design with strict 200-line file limits. Use when starting new features, refactoring large files, or planning module structure. Enforces modular design and real testing.
SKILL.md
elegant-architecture.SKILL.mdname: elegant-architecture
description: Guides clean architecture design with strict 200-line file limits. Use when starting new features, refactoring large files, or planning module structure. Enforces modular design and real testing.
Elegant Architecture
Core Principles
- **200-line limit** — No file exceeds 200 lines of code
- **Split when exceeded** — Convert to folder or multiple files
- **Plan first, code later** — Design architecture before implementation
- **Single responsibility** — Each module does one thing well
- **Real tests only** — No mocks, test actual behavior
Execution Flow
1. Analyze Requirements
Before writing any code:
- List all features/functionalities needed
- Estimate code volume for each module
- Identify shared components
- Map dependencies between modules
2. Design File Structure
When estimated lines > 200:
- Convert file to folder with index
- Split by sub-functionality
- Extract shared utilities
Example transformation:
# Before (user.ts - 400+ lines)
user.ts
# After (user/ folder)
user/
├── index.ts # Public exports
├── types.ts # Interfaces, types
├── validation.ts # Input validation
├── repository.ts # Data access
└── service.ts # Business logic
3. Define Interfaces First
// Define contracts before implementation
interface UserService {
create(input: CreateUserInput): Promise<User>;
findById(id: string): Promise<User | null>;
update(id: string, input: UpdateUserInput): Promise<User>;
delete(id: string): Promise<void>;
}
interface UserRepository {
save(user: User): Promise<User>;
findById(id: string): Promise<User | null>;
findByEmail(email: string): Promise<User | null>;
delete(id: string): Promise<void>;
}4. Implement Incrementally
For each module:
1. Create type definitions
2. Implement core logic
3. Add error handling
4. Write tests
5. Verify line count < 200
5. Test Without Mocks
// ❌ Avoid: Mock everything
const mockRepo = jest.fn();
const service = new UserService(mockRepo);
// ✅ Prefer: Real implementations
const testDb = createTestDatabase();
const repo = new UserRepository(testDb);
const service = new UserService(repo);
// Test actual behavior
const user = await service.create({ email: 'test@example.com' });
const found = await service.findById(user.id);
expect(found).toEqual(user);Design Patterns
Modular Design
src/
├── modules/
│ ├── auth/
│ │ ├── index.ts
│ │ ├── types.ts
│ │ ├── service.ts
│ │ └── middleware.ts
│ ├── user/
│ │ ├── index.ts
│ │ ├── types.ts
│ │ ├── service.ts
│ │ └── repository.ts
│ └── order/
│ ├── index.ts
│ ├── types.ts
│ ├── service.ts
│ └── repository.ts
├── shared/
│ ├── database/
│ ├── errors/
│ └── utils/
└── index.ts
Dependency Injection
// Decouple components via constructor injection
class OrderService {
constructor(
private readonly orderRepo: OrderRepository,
private readonly userService: UserService,
private readonly paymentGateway: PaymentGateway
) {}
async createOrder(userId: string, items: OrderItem[]): Promise<Order> {
const user = await this.userService.findById(userId);
if (!user) throw new NotFoundError('User', userId);
const order = Order.create(user, items);
await this.paymentGateway.charge(user, order.total);
return this.orderRepo.save(order);
}
}
// Wire up in composition root
const orderService = new OrderService(
new PostgresOrderRepository(db),
new UserService(userRepo),
new StripePaymentGateway(stripeClient)
);Factory Pattern
// Complex object creation
class NotificationFactory {
create(type: NotificationType, data: NotificationData): Notification {
switch (type) {
case 'email':
return new EmailNotification(data, this.emailClient);
case 'sms':
return new SmsNotification(data, this.smsClient);
case 'push':
return new PushNotification(data, this.pushClient);
default:
throw new Error(`Unknown notification type: ${type}`);
}
}
}Strategy Pattern
// Replaceable algorithms
interface PricingStrategy {
calculate(order: Order): Money;
}
class StandardPricing implements PricingStrategy {
calculate(order: Order): Money {
return order.items.reduce((sum, item) => sum.add(item.price), Money.zero());
}
}
class DiscountPricing implements PricingStrategy {
constructor(private readonly discount: Percentage) {}
calculate(order: Order): Money {
const standard = new StandardPricing().calculate(order);
return standard.subtract(standard.multiply(this.discount));
}
}
class OrderProcessor {
constructor(private pricing: PricingStrategy) {}
setPricing(strategy: PricingStrategy) {
this.pricing = strategy;
}
process(order: Order): ProcessedOrder {
const total = this.pricing.calculate(order);
return { ...order, total };
}
}File Splitting Guidelines
When to Split
| Indicator | Action | |-----------|--------| | File > 200 lines | Split immediately | | File > 150 lines | Plan split | | 3+ distinct responsibilities | Split by responsibility | | Shared types growing | Extract to types.ts | | Utility functions accumulating | Extract to utils.ts |
How to Split
1. Identify logical boundaries
2. Create folder with same name as file
3. Move related code to separate files
4. Create index.ts for public exports
5. Update imports in dependent files
Naming Conventions
module/
├── index.ts # Public API exports
├── types.ts # Interfaces, types, enums
├── constants.ts # Configuration, magic values
├── utils.ts # Helper functions
├── service.ts # Business logic
├── repository.ts # Data access
├── validation.ts # Input validation
└── errors.ts #
Read more
name: elegant-architecture description: Guides clean architecture design with strict 200-line file limits. Use when starting new features, refactoring large files, or planning module structure. Enforces modular design and real testing.
Elegant Architecture
Core Principles
- **200-line limit** — No file exceeds 200 lines of code
- **Split when exceeded** — Convert to folder or multiple files
- **Plan first, code later** — Design architecture before implementation
- **Single responsibility** — Each module does one thing well
- **Real tests only** — No mocks, test actual behavior
Execution Flow
1. Analyze Requirements
Before writing any code: - List all features/functionalities needed - Estimate code volume for each module - Identify shared components - Map dependencies between modules
2. Design File Structure
When estimated lines > 200: - Convert file to folder with index - Split by sub-functionality - Extract shared utilities Example transformation:
# Before (user.ts - 400+ lines) user.ts # After (user/ folder) user/ ├── index.ts # Public exports ├── types.ts # Interfaces, types ├── validation.ts # Input validation ├── repository.ts # Data access └── service.ts # Business logic
3. Define Interfaces First
// Define contracts before implementation
interface UserService {
create(input: CreateUserInput): Promise<User>;
findById(id: string): Promise<User | null>;
update(id: string, input: UpdateUserInput): Promise<User>;
delete(id: string): Promise<void>;
}
interface UserRepository {
save(user: User): Promise<User>;
findById(id: string): Promise<User | null>;
findByEmail(email: string): Promise<User | null>;
delete(id: string): Promise<void>;
}4. Implement Incrementally
For each module: 1. Create type definitions 2. Implement core logic 3. Add error handling 4. Write tests 5. Verify line count < 200
5. Test Without Mocks
// ❌ Avoid: Mock everything
const mockRepo = jest.fn();
const service = new UserService(mockRepo);
// ✅ Prefer: Real implementations
const testDb = createTestDatabase();
const repo = new UserRepository(testDb);
const service = new UserService(repo);
// Test actual behavior
const user = await service.create({ email: 'test@example.com' });
const found = await service.findById(user.id);
expect(found).toEqual(user);Design Patterns
Modular Design
src/ ├── modules/ │ ├── auth/ │ │ ├── index.ts │ │ ├── types.ts │ │ ├── service.ts │ │ └── middleware.ts │ ├── user/ │ │ ├── index.ts │ │ ├── types.ts │ │ ├── service.ts │ │ └── repository.ts │ └── order/ │ ├── index.ts │ ├── types.ts │ ├── service.ts │ └── repository.ts ├── shared/ │ ├── database/ │ ├── errors/ │ └── utils/ └── index.ts
Dependency Injection
// Decouple components via constructor injection
class OrderService {
constructor(
private readonly orderRepo: OrderRepository,
private readonly userService: UserService,
private readonly paymentGateway: PaymentGateway
) {}
async createOrder(userId: string, items: OrderItem[]): Promise<Order> {
const user = await this.userService.findById(userId);
if (!user) throw new NotFoundError('User', userId);
const order = Order.create(user, items);
await this.paymentGateway.charge(user, order.total);
return this.orderRepo.save(order);
}
}
// Wire up in composition root
const orderService = new OrderService(
new PostgresOrderRepository(db),
new UserService(userRepo),
new StripePaymentGateway(stripeClient)
);Factory Pattern
// Complex object creation
class NotificationFactory {
create(type: NotificationType, data: NotificationData): Notification {
switch (type) {
case 'email':
return new EmailNotification(data, this.emailClient);
case 'sms':
return new SmsNotification(data, this.smsClient);
case 'push':
return new PushNotification(data, this.pushClient);
default:
throw new Error(`Unknown notification type: ${type}`);
}
}
}Strategy Pattern
// Replaceable algorithms
interface PricingStrategy {
calculate(order: Order): Money;
}
class StandardPricing implements PricingStrategy {
calculate(order: Order): Money {
return order.items.reduce((sum, item) => sum.add(item.price), Money.zero());
}
}
class DiscountPricing implements PricingStrategy {
constructor(private readonly discount: Percentage) {}
calculate(order: Order): Money {
const standard = new StandardPricing().calculate(order);
return standard.subtract(standard.multiply(this.discount));
}
}
class OrderProcessor {
constructor(private pricing: PricingStrategy) {}
setPricing(strategy: PricingStrategy) {
this.pricing = strategy;
}
process(order: Order): ProcessedOrder {
const total = this.pricing.calculate(order);
return { ...order, total };
}
}File Splitting Guidelines
When to Split
| Indicator | Action | |-----------|--------| | File > 200 lines | Split immediately | | File > 150 lines | Plan split | | 3+ distinct responsibilities | Split by responsibility | | Shared types growing | Extract to types.ts | | Utility functions accumulating | Extract to utils.ts |
How to Split
1. Identify logical boundaries 2. Create folder with same name as file 3. Move related code to separate files 4. Create index.ts for public exports 5. Update imports in dependent files
Naming Conventions
module/ ├── index.ts # Public API exports ├── types.ts # Interfaces, types, enums ├── constants.ts # Configuration, magic values ├── utils.ts # Helper functions ├── service.ts # Business logic ├── repository.ts # Data access ├── validation.ts # Input validation └── errors.ts #
Cross-runtime skills for Claude Code, Codex, and multi-agent workflows.
Repo: majiayu000/spellbook
Other skills on spellbook.
- /agentsmd-optimize
Audit AND optimize a CLAUDE.md / AGENTS.md instruction file — score it against the five high-leverage patterns, flag anti-patterns, then apply approved fixes in place. Use when the user says 优化 CLAUDE.md / 优化 AGENTS.md / optimize my agent doc / 帮我改 claudemd, or after an audit
Open skill - /agentsmd-scaffold
Generate or update repository-specific AGENTS.md instruction files from real repo evidence. Use when asked to create, design, scaffold, split, or improve root or scoped AGENTS.md files for Codex/Claude/agent workflows, especially when a repo needs directory-specific rules,
Open skill - /api-design
REST/GraphQL/gRPC API design best practices. Use when designing APIs, defining contracts, handling versioning. Covers OpenAPI 3.2, GraphQL Federation, gRPC streaming.
Open skill - /app-ui-design
Mobile app UI design expert for iOS and Android. Use when designing app interfaces, creating design systems, ensuring accessibility, or following platform guidelines. Covers Material Design 3, Human Interface Guidelines, color theory, typography, and 2025 trends.
Open skill - /app-user-story-qa
End-to-end app feature inventory and user-story testing workflow with a canonical tracker. Use when the user asks to audit every feature, derive expected behavior from code, test user journeys, or explicitly fix and retest documented UX or logistical defects.
Open skill - /architecture-foundation
Design architecture foundations before implementation. Use when asked to design or refactor architecture, choose Rust/Go crate, package, module, runtime, workflow, or service boundaries, compare mature project architecture, prevent stacked one-off PRs, audit migration debt in
Open skill

