feat: add clean-code skills category (SOLID, DDD, Hexagonal Architecture) to repository and website showcase

Author: tushar2704

site/src/components/os/apps/ShowcaseApp.tsx

@@ -600,6 +600,30 @@ const FEATURES: Feature[] = [
     install: "npx claudient add agent moe-router",
     steps: ["Classify request complexity and risk levels", "Generate execution blueprint JSON", "Dispatch reasoning-heavy parts to Opus", "Build and write boilerplate using Haiku"],
     related: ["claudient architect-mason", "claudient council"] },
+  { id: "solid-principles", icon: "💎", name: "SOLID Design Principles", tagline: "Clean code OOP standards",
+    desc: "Enforces the five core SOLID rules during code review and refactoring for scalable, modular class design.",
+    how: "Inspects code coupling and splits multi-purpose functions to comply with single responsibility bounds.",
+    example: "Class UserManager -> split into UserRepo + UserAuthenticator",
+    color: "#b62ad9", category: "enterprise",
+    install: "npx claudient add skill solid-principles",
+    steps: ["Verify single responsibility bounds (SRP)", "Refactor switch-cases using polymorphism (OCP)", "Ensure subclass substitution consistency (LSP)", "Split oversized interface parameters (ISP)", "Inject abstract dependencies instead of concretions (DIP)"],
+    related: ["claudient architect", "claudient adr"] },
+  { id: "domain-driven-design", icon: "🏛️", name: "Domain-Driven Design", tagline: "Business-logic separation",
+    desc: "Models complex logic around bounded contexts, defining aggregates, value objects, and repository boundaries.",
+    how: "Filters database entities from leaking into core logic, ensuring boundaries are accessed only via aggregate roots.",
+    example: "Aggregate Root: Order -> Item adds and validates pricing total invariants",
+    color: "#b62ad9", category: "enterprise",
+    install: "npx claudient add skill domain-driven-design",
+    steps: ["Define core domain entities and value objects", "Establish aggregate root boundary invariants", "Abstract data access through Domain Repositories", "Decouple frameworks from business domain logic"],
+    related: ["claudient architect", "claudient adr"] },
+  { id: "hexagonal-architecture", icon: "⬡", name: "Hexagonal Architecture", tagline: "Ports & Adapters isolation",
+    desc: "Decouples core business logic (Inner Ring) from infrastructure (Outer Ring) using Inbound and Outbound Ports.",
+    how: "Exposes interfaces (Ports) inside domain, implementing database/web handlers outside (Adapters).",
+    example: "Inbound Port: UserUseCase -> Adapter: ExpressUserController",
+    color: "#b62ad9", category: "enterprise",
+    install: "npx claudient add skill hexagonal-architecture",
+    steps: ["Construct domain logic without outside dependencies", "Create Inbound and Outbound Port interfaces", "Implement primary adapters for delivery hooks (REST/CLI)", "Implement secondary adapters for infrastructure hooks (DB/API)"],
+    related: ["claudient architect", "claudient adr"] },
 ];
 
 export function ShowcaseApp() {

skills/clean-code/domain-driven-design.md

@@ -0,0 +1,63 @@
+---
+name: domain-driven-design
+description: "Implement Domain-Driven Design (DDD) patterns: distinguish between Entities, Value Objects, Aggregates, and Repositories"
+updated: 2026-06-23
+---
+
+# Domain-Driven Design (DDD) Skill
+
+## When to activate
+
+- Modeling complex business logic or enterprise service patterns.
+- Decoupling core business rules from databases, frameworks, or delivery mechanisms.
+- Defining bounded contexts in microservice systems.
+
+## When NOT to use
+
+- Simple CRUD (Create, Read, Update, Delete) apps where data maps 1:1 to database tables.
+- Building stateless helper libraries or data processing scripts.
+
+## Instructions
+
+Structure domain logic around these core tactical patterns:
+
+### 1. Entities
+- **Definition**: Objects defined by a unique identity that persists across state changes, rather than their attributes.
+- **Guideline**: Ensure they hold an ID, and bundle state mutations with business rules validation.
+
+### 2. Value Objects
+- **Definition**: Objects defined strictly by their attributes, with no identity (e.g. Email address, Money value).
+- **Guideline**: Treat them as immutable. Any change should instantiate a new Value Object.
+
+### 3. Aggregates
+- **Definition**: A cluster of associated objects (Entities and Value Objects) treated as a single unit for data changes.
+- **Guideline**: Access children only through the Aggregate Root. Enforce all boundary invariants inside the Root.
+
+### 4. Repositories
+- **Definition**: Abstraction layer providing collection-like access to Aggregates (hiding database details).
+- **Guideline**: Map database entities to domain entities before returning them.
+
+---
+
+## Example
+
+```typescript
+// Value Object (Immutable)
+class Money {
+  constructor(public readonly amount: number, public readonly currency: string) {
+    if (amount < 0) throw new Error("Amount cannot be negative");
+  }
+}
+
+// Aggregate Root
+class Order {
+  private items: OrderItem[] = [];
+  constructor(public readonly orderId: string, private total: Money) {}
+  
+  // Enforce boundary invariants
+  addItem(item: OrderItem) {
+    this.items.push(item);
+    this.total = new Money(this.total.amount + item.price.amount, this.total.currency);
+  }
+}
+```

skills/clean-code/hexagonal-architecture.md

@@ -0,0 +1,50 @@
+---
+name: hexagonal-architecture
+description: "Isolate core domain logic using Hexagonal Architecture (Ports and Adapters) to separate business rules from infrastructure"
+updated: 2026-06-23
+---
+
+# Hexagonal Architecture Skill
+
+## When to activate
+
+- Building enterprise services that must remain decoupled from specific databases (e.g. Postgres vs MongoDB) or web delivery harnesses (Express vs Fastify).
+- Designing easily testable systems (mocking infrastructure via Ports).
+
+## When NOT to use
+
+- Small utilities, serverless functions, or script automations.
+- Projects built strictly around an ORM's active-record pattern.
+
+## Instructions
+
+Maintain clear separation of concerns across three structural rings:
+
+### 1. The Core Domain (Inner Ring)
+- Contains business rules, Entities, and Value Objects.
+- **Rule**: Must have **zero** dependencies on outside frameworks, libraries, databases, or transport layers.
+
+### 2. Ports (Middle Ring)
+- Interfaces defining how the outside world communicates with the Domain (Inbound/Primary) and how the Domain talks to infrastructure (Outbound/Secondary).
+- **Rule**: Defined as abstract classes or interfaces inside the domain layer.
+
+### 3. Adapters (Outer Ring)
+- Concrete implementations of Ports. 
+- *Primary Adapters*: REST controllers, CLI controllers, Event consumers.
+- *Secondary Adapters*: Postgres DB repo, Stripe payment client, SMTP email adapter.
+
+---
+
+## Example Structure
+
+```
+src/
+├── domain/                  # Inner Ring (Domain Entities)
+│   └── User.ts
+├── ports/                   # Middle Ring (Interfaces)
+│   ├── UserUseCase.ts       # Inbound Port
+│   └── UserRepository.ts    # Outbound Port
+└── adapters/                # Outer Ring (Implementations)
+    ├── express-user.ts      # Primary Adapter (REST)
+    └── postgres-user.ts     # Secondary Adapter (DB)
+```

skills/clean-code/solid-principles.md

@@ -0,0 +1,65 @@
+---
+name: solid-principles
+description: "Apply SOLID design principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) during refactoring"
+updated: 2026-06-23
+---
+
+# SOLID Principles Skill
+
+## When to activate
+
+- Designing class hierarchies, modules, or services in object-oriented and functional systems.
+- Reviewing code for tight coupling, oversized classes, or hard-to-test components.
+- Refactoring legacy codebases to improve extensibility.
+
+## When NOT to use
+
+- Writing small utility scripts, configurations, or single-use shell automations.
+- Designing purely relational database schemas (use database-specific skills instead).
+
+## Instructions
+
+Analyze code structures against the five SOLID guidelines:
+
+### 1. Single Responsibility Principle (SRP)
+- **Rule**: A class or module should have one, and only one, reason to change.
+- **Action**: Extract secondary responsibilities (e.g. logging, network calling, formatting) into separate services.
+
+### 2. Open/Closed Principle (OCP)
+- **Rule**: Software entities should be open for extension, but closed for modification.
+- **Action**: Use polymorphism, interfaces, or dependency injection instead of hardcoded switch-cases.
+
+### 3. Liskov Substitution Principle (LSP)
+- **Rule**: Subtypes must be substitutable for their base types without altering correctness.
+- **Action**: Do not throw `NotImplementedException` in subclass overrides. Keep interface contracts consistent.
+
+### 4. Interface Segregation Principle (ISP)
+- **Rule**: Clients should not be forced to depend on methods they do not use.
+- **Action**: Split large, multi-purpose interfaces into smaller, cohesive contracts.
+
+### 5. Dependency Inversion Principle (DIP)
+- **Rule**: Depend on abstractions, not concretions.
+- **Action**: Inject interfaces or abstract classes into components rather than instantiating dependencies directly (`new Class()`).
+
+---
+
+## Example (Refactoring tight coupling)
+
+```typescript
+// BAD: Violates SRP & DIP
+class Invoice {
+  saveToDB() { /* ... */ }
+  printInvoice() { /* ... */ }
+}
+
+// GOOD: Adheres to SRP & DIP
+interface InvoiceRepository {
+  save(invoice: Invoice): void;
+}
+class DatabaseInvoiceRepository implements InvoiceRepository {
+  save(invoice: Invoice) { /* ... */ }
+}
+class InvoicePrinter {
+  print(invoice: Invoice) { /* ... */ }
+}
+```