Skip to content
Development
Skill

/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.

From plugin
majiayu000-spellbook
277104 skills7 agents2 commands
Install
$ npx -y skills add majiayu000/spellbook --skill elegant-architecture --agent claude-code

How 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.md
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         #
Read more
Ships withmajiayu000-spellbook

Cross-runtime skills for Claude Code, Codex, and multi-agent workflows.

Get the whole plugin

Other skills on majiayu000-spellbook.

idea-analogist
Skill

idea-analogist

想法群聊室 — 类比者角色。被 idea-team 主编排器调用,或用户单独说"类比一下"、"别的行业有没有"、"yes-and 扩展"、"X 让你想到什么"、"跨界启示"时触发。**专门做跨界类比 + yes-and 扩展——不评判、不挑刺、不要求事实证据**。Do NOT use when 用户要数据(用…

idea-devils-advocate
Skill

idea-devils-advocate

想法群聊室 — 反方角色。被 idea-team 主编排器调用,或用户单独说"反方意见"、"挑这个想法的刺"、"为什么会失败"、"找漏洞 / 反例"、"devil's advocate"时触发。**专门挑漏洞、找隐藏假设、给反例——不安慰、不"也许可以这样"、不全盘否定**。Do NOT use when…

idea-research
Skill

idea-research

想法群聊室 — 调研员角色。被 idea-team 主编排器调用,或用户单独说"调研一下 X"、"X 的现状/竞品/数据"、"找 2026 数据"、"事实底"时触发。**用 WebSearch 拉真实 2026 数据、列竞品、引来源——只给事实,不评判,不建议**。Do NOT use when…

idea-team
Skill

idea-team

想法群聊室主持人 — 把一句话想法丢给多角色 AI 团队(调研员/反方/类比者)做查漏补缺。每个角色有自己的 voice,他们互相 @ 接话;你随时插话。**这是创意扩展工具,不打分、不否决、不堵路**。Use when 用户说"组个团队聊一下"、"开会讨论这个想法"、"找几个角度看看"、"群聊一下 X"、"team…

idea-to-product
Skill

idea-to-product

端到端产品教练 — 把一句话想法走到 PRD + 可点击 HTML 原型。会顶嘴、强制砍功能、用 Nielsen + Norman 做友好性硬检。Use when user 说"我有一个想法"、"想做一个产品"、"做 MVP"、"写 PRD"、"做用户友好的产品",或调用插件命令…