[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C325C0CDMY3MMWDH5CXJAY":3,"skill-same:01M6C325C0CDMY3MMWDH5CXJAY":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M6C325C0CDMY3MMWDH5CXJAY","architect",null,"Design scalable system architectures and make technology decisions. Covers microservices vs monolith analysis, event-driven architecture, CQRS, domain-driven design, system design methodology, scalability planning, technology selection frameworks, architecture decision records, C4 diagrams, and infrastructure patterns. Use when designing systems, making architectural decisions, or planning for scale.","RaheesAhmed\u002FSajiCode","RaheesAhmed","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F48914925?v=4","01M6C31VY6EJ4N8QS30J585H9H","Rahees Ahmed","01M6C31W21ET706B6XTWHS52VC",68,"MIT","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Farchitect\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36],"design","architecture","infrastructure","planning","microservices","methodology","architecture decision records","analysis","c4 diagrams","system","decision","decisions","use","2026-11-10 10:12:30",false,"---\nname: architect\ndescription: Design scalable system architectures and make technology decisions. Covers microservices vs monolith analysis, event-driven architecture, CQRS, domain-driven design, system design methodology, scalability planning, technology selection frameworks, architecture decision records, C4 diagrams, and infrastructure patterns. Use when designing systems, making architectural decisions, or planning for scale.\n---\n\n# System Architecture & Design\n\n## Architecture Decision Process\n\n### Step 1: Understand Requirements\n```\nFunctional: What does it DO?\nNon-Functional:\n  - Expected users (100? 10K? 1M+?)\n  - Latency requirements (\u003C 100ms? \u003C 1s?)\n  - Availability target (99.9%? 99.99%?)\n  - Data sensitivity (PII? Financial? Public?)\n  - Compliance (GDPR, SOC2, HIPAA?)\n  - Budget constraints\n```\n\n### Step 2: Architecture Selection\n| Pattern | Best When | Avoid When |\n|---------|-----------|------------|\n| Monolith | Team \u003C 10, MVP, simple domain | > 50 developers, complex domain |\n| Modular Monolith | Growing team, separation needed | Need independent deployment |\n| Microservices | Large teams, independent scaling | Small team, simple domain |\n| Serverless | Event-driven, variable load | Consistent high-throughput |\n| Event-Driven | Async workflows, loose coupling | Strong consistency needed |\n\n### Step 3: Document Decision (ADR)\n```markdown\n# ADR-001: Choose Modular Monolith Architecture\n\n## Status: Accepted\n\n## Context\nWe have a team of 5 engineers building a SaaS dashboard.\nExpected users: 10K in year 1, 100K in year 3.\n\n## Decision\nStart with a modular monolith with clear domain boundaries.\n\n## Consequences\n- Faster development velocity initially\n- Can extract services later if needed\n- Must maintain module boundaries with linting rules\n- Single deployment simplifies DevOps\n```\n\n## Architecture Patterns\n\n### Modular Monolith\n```\nsrc\u002F\n├── modules\u002F\n│   ├── auth\u002F                # Auth domain\n│   │   ├── routes.ts\n│   │   ├── service.ts\n│   │   ├── repository.ts\n│   │   └── types.ts\n│   ├── billing\u002F             # Billing domain\n│   │   ├── routes.ts\n│   │   ├── service.ts\n│   │   └── events.ts        # Publishes billing events\n│   └── notifications\u002F       # Notifications domain\n│       ├── service.ts\n│       └── listeners.ts     # Subscribes to billing events\n├── shared\u002F                  # Shared kernel\n│   ├── database.ts\n│   ├── event-bus.ts\n│   └── types.ts\n└── index.ts\n```\n\n**Rule**: Modules communicate through events or shared interfaces — NEVER direct imports of another module's internals.\n\n### Event-Driven Architecture\n```ts\n\u002F\u002F Event bus (in-process for monolith)\ntype EventHandler = (data: unknown) => Promise\u003Cvoid>;\n\nclass EventBus {\n  private handlers = new Map\u003Cstring, EventHandler[]>();\n\n  on(event: string, handler: EventHandler) {\n    const existing = this.handlers.get(event) || [];\n    this.handlers.set(event, [...existing, handler]);\n  }\n\n  async emit(event: string, data: unknown) {\n    const handlers = this.handlers.get(event) || [];\n    await Promise.allSettled(handlers.map((h) => h(data)));\n  }\n}\n\n\u002F\u002F Usage\neventBus.on(\"user.created\", async (data) => {\n  await sendWelcomeEmail(data.email);\n  await createDefaultWorkspace(data.userId);\n  await trackAnalytics(\"signup\", data);\n});\n\nawait eventBus.emit(\"user.created\", { userId: user.id, email: user.email });\n```\n\n### CQRS (Command Query Responsibility Segregation)\n```ts\n\u002F\u002F Commands (writes) — go through domain logic\nclass CreateOrderCommand {\n  constructor(public userId: string, public items: OrderItem[]) {}\n}\n\nasync function handleCreateOrder(cmd: CreateOrderCommand) {\n  const order = OrderAggregate.create(cmd.userId, cmd.items);\n  await orderRepository.save(order);\n  await eventBus.emit(\"order.created\", order.toEvent());\n}\n\n\u002F\u002F Queries (reads) — optimized read models\nasync function getOrderSummary(userId: string) {\n  return db.query(`\n    SELECT o.id, o.total, o.status, COUNT(oi.id) as item_count\n    FROM orders o JOIN order_items oi ON oi.order_id = o.id\n    WHERE o.user_id = $1 GROUP BY o.id ORDER BY o.created_at DESC\n  `, [userId]);\n}\n```\n\n## Scalability Patterns\n\n### Horizontal Scaling Checklist\n```\n- [ ] Stateless application servers (no in-memory session state)\n- [ ] Database connection pooling\n- [ ] Centralized session store (Redis)\n- [ ] Shared file storage (S3, not local disk)\n- [ ] Load balancer with health checks\n- [ ] Background job queue (BullMQ, Celery)\n- [ ] CDN for static assets\n- [ ] Database read replicas for read-heavy workloads\n```\n\n### Caching Layers\n```\nBrowser Cache → CDN → Application Cache (Redis) → Database\n   (hours)      (min)        (seconds)           (source of truth)\n```\n\n### Database Scaling\n```\n1. Optimize queries (indexes, query plans)     → handles 10x load\n2. Read replicas                                → handles 50x reads\n3. Connection pooling (PgBouncer)              → handles 100x connections\n4. Application-level caching                    → handles 100x reads\n5. Sharding (last resort)                       → handles 1000x data\n```\n\n## System Design Template\n\nWhen asked to design a system, follow this structure:\n```\n1. Clarify requirements (functional + non-functional)\n2. Estimate scale (users, requests\u002Fsec, storage)\n3. Define API contract (endpoints, request\u002Fresponse)\n4. Design data model (entities, relationships)\n5. Draw high-level architecture (components, data flow)\n6. Deep dive into critical components\n7. Address bottlenecks and failure points\n8. Discuss trade-offs and alternatives\n```\n\n## C4 Diagram Levels\n```\nLevel 1: System Context — How the system fits in the world\nLevel 2: Container — Major technology choices (web app, API, database)\nLevel 3: Component — Key components within each container\nLevel 4: Code — Class\u002Ffunction level (only for critical parts)\n```\n\n## Rules\n- Start simple, add complexity only when proven necessary\n- Choose boring technology for critical infrastructure\n- Design for the next 10x, not 100x — you'll rewrite by then\n- Every cross-service call is a potential failure point\n- Prefer async communication between services\n- Document ALL architectural decisions in ADRs\n","# System Architecture & Design\n\n## Architecture Decision Process\n\n### Step 1: Understand Requirements\n```\nFunctional: What does it DO?\nNon-Functional:\n  - Expected users (100? 10K? 1M+?)\n  - Latency requirements (\u003C 100ms? \u003C 1s?)\n  - Availability target (99.9%? 99.99%?)\n  - Data sensitivity (PII? Financial? Public?)\n  - Compliance (GDPR, SOC2, HIPAA?)\n  - Budget constraints\n```\n\n### Step 2: Architecture Selection\n| Pattern | Best When | Avoid When |\n|---------|-----------|------------|\n| Monolith | Team \u003C 10, MVP, simple domain | > 50 developers, complex domain |\n| Modular Monolith | Growing team, separation needed | Need independent deployment |\n| Microservices | Large teams, independent scaling | Small team, simple domain |\n| Serverless | Event-driven, variable load | Consistent high-throughput |\n| Event-Driven | Async workflows, loose coupling | Strong consistency needed |\n\n### Step 3: Document Decision (ADR)\n```markdown\n# ADR-001: Choose Modular Monolith Architecture\n\n## Status: Accepted\n\n## Context\nWe have a team of 5 engineers building a SaaS dashboard.\nExpected users: 10K in year 1, 100K in year 3.\n\n## Decision\nStart with a modular monolith with clear domain boundaries.\n\n## Consequences\n- Faster development velocity initially\n- Can extract services later if needed\n- Must maintain module boundaries with linting rules\n- Single deployment simplifies DevOps\n```\n\n## Architecture Patterns\n\n### Modular Monolith\n```\nsrc\u002F\n├── modules\u002F\n│   ├── auth\u002F                # Auth domain\n│   │   ├── routes.ts\n│   │   ├── service.ts\n│   │   ├── repository.ts\n│   │   └── types.ts\n│   ├── billing\u002F             # Billing domain\n│   │   ├── routes.ts\n│   │   ├── service.ts\n│   │   └── events.ts        # Publishes billing events\n│   └── notifications\u002F       # Notifications domain\n│       ├── service.ts\n│       └── listeners.ts     # Subscribes to billing events\n├── shared\u002F                  # Shared kernel\n│   ├── database.ts\n│   ├── event-bus.ts\n│   └── types.ts\n└── index.ts\n```\n\n**Rule**: Modules communicate through events or shared interfaces — NEVER direct imports of another module's internals.\n\n### Event-Driven Architecture\n```ts\n\u002F\u002F Event bus (in-process for monolith)\ntype EventHandler = (data: unknown) => Promise\u003Cvoid>;\n\nclass EventBus {\n  private handlers = new Map\u003Cstring, EventHandler[]>();\n\n  on(event: string, handler: EventHandler) {\n    const existing = this.handlers.get(event) || [];\n    this.handlers.set(event, [...existing, handler]);\n  }\n\n  async emit(event: string, data: unknown) {\n    const handlers = this.handlers.get(event) || [];\n    await Promise.allSettled(handlers.map((h) => h(data)));\n  }\n}\n\n\u002F\u002F Usage\neventBus.on(\"user.created\", async (data) => {\n  await sendWelcomeEmail(data.email);\n  await createDefaultWorkspace(data.userId);\n  await trackAnalytics(\"signup\", data);\n});\n\nawait eventBus.emit(\"user.created\", { userId: user.id, email: user.email });\n```\n\n### CQRS (Command Query Responsibility Segregation)\n```ts\n\u002F\u002F Commands (writes) — go through domain logic\nclass CreateOrderCommand {\n  constructor(public userId: string, public items: OrderItem[]) {}\n}\n\nasync function handleCreateOrder(cmd: CreateOrderCommand) {\n  const order = OrderAggregate.create(cmd.userId, cmd.items);\n  await orderRepository.save(order);\n  await eventBus.emit(\"order.created\", order.toEvent());\n}\n\n\u002F\u002F Queries (reads) — optimized read models\nasync function getOrderSummary(userId: string) {\n  return db.query(`\n    SELECT o.id, o.total, o.status, COUNT(oi.id) as item_count\n    FROM orders o JOIN order_items oi ON oi.order_id = o.id\n    WHERE o.user_id = $1 GROUP BY o.id ORDER BY o.created_at DESC\n  `, [userId]);\n}\n```\n\n## Scalability Patterns\n\n### Horizontal Scaling Checklist\n```\n- [ ] Stateless application servers (no in-memory session state)\n- [ ] Database connection pooling\n- [ ] Centralized session store (Redis)\n- [ ] Shared file storage (S3, not local disk)\n- [ ] Load balancer with health checks\n- [ ] Background job queue (BullMQ, Celery)\n- [ ] CDN for static assets\n- [ ] Database read replicas for read-heavy workloads\n```\n\n### Caching Layers\n```\nBrowser Cache → CDN → Application Cache (Redis) → Database\n   (hours)      (min)        (seconds)           (source of truth)\n```\n\n### Database Scaling\n```\n1. Optimize queries (indexes, query plans)     → handles 10x load\n2. Read replicas                                → handles 50x reads\n3. Connection pooling (PgBouncer)              → handles 100x connections\n4. Application-level caching                    → handles 100x reads\n5. Sharding (last resort)                       → handles 1000x data\n```\n\n## System Design Template\n\nWhen asked to design a system, follow this structure:\n```\n1. Clarify requirements (functional + non-functional)\n2. Estimate scale (users, requests\u002Fsec, storage)\n3. Define API contract (endpoints, request\u002Fresponse)\n4. Design data model (entities, relationships)\n5. Draw high-level architecture (components, data flow)\n6. Deep dive into critical components\n7. Address bottlenecks and failure points\n8. Discuss trade-offs and alternatives\n```\n\n## C4 Diagram Levels\n```\nLevel 1: System Context — How the system fits in the world\nLevel 2: Container — Major technology choices (web app, API, database)\nLevel 3: Component — Key components within each container\nLevel 4: Code — Class\u002Ffunction level (only for critical parts)\n```\n\n## Rules\n- Start simple, add complexity only when proven necessary\n- Choose boring technology for critical infrastructure\n- Design for the next 10x, not 100x — you'll rewrite by then\n- Every cross-service call is a potential failure point\n- Prefer async communication between services\n- Document ALL architectural decisions in ADRs\n",{"name":5,"description":7},"main","791249e54ef4db28bf9af93993479d2e0c6a8a9d","skills\u002Farchitect",15,"https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode","https:\u002F\u002Fgithub.com\u002FRaheesAhmed","https:\u002F\u002Fraheesahmed.vercel.app\u002F","Forward Deployed AI Engineer | AI Agents, MCP Servers & Business Automation","2026-09-14 17:21:11",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add RaheesAhmed\u002FSajiCode --skill architect",{"tool":57,"command":58},"bunx","bunx skills add RaheesAhmed\u002FSajiCode --skill architect",{"tool":60,"command":61},"pnpm","pnpm dlx skills add RaheesAhmed\u002FSajiCode --skill architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Farchitect\u002FSKILL.md",true,[],[66,79,91,114,138,159],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":75,"publishedAt":37},"01M6C33MP48R5GWR13P2VFHWB0","demo-skill","Demo plugin skill for tests.","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fdemo-plugin\u002Fskills\u002Fdemo-skill\u002FSKILL.md",[72],{"categoryNo":73,"categoryName":74,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[76,77,78],"demo skill","demo","plugin",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":86,"publishedAt":37},"01M6C33JV7RMPM5AVS7SCCGDR8","write-a-skill","Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill.","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-a-skill\u002FSKILL.MD",[85],{"categoryNo":73,"categoryName":74,"taxonomyType":21,"taxonomyTypeDesc":22},[87,88,89,90,36],"write","write a skill","create","user",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":100,"publishedAt":37},"01M6C33G0SX1683HER40XB8047","web-research","Deep web research and data extraction skill. Systematically research ANY topic by fetching URLs, reading documentation, crawling API docs, evaluating npm\u002Fpypi packages, comparing technologies, and synthesizing findings into actionable recommendations. Use when researching libraries, frameworks, APIs, solutions, or any topic requiring web investigation.","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Fweb-research\u002FSKILL.md",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[101,102,103,104,105,106,107,108,109,110,111,112,113,36],"research","web","web research","docs","documentation","libraries","packages","npm","extraction","pypi","data","investigation","api",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":123,"publishedAt":37},"01M6C33CRE3D30CHTTV1ZVR1ZM","testing","Design and implement comprehensive test suites. Covers unit testing, integration testing, E2E testing with Playwright, API testing, mocking strategies, test data factories, TDD workflow, snapshot testing, coverage targets, and CI integration. Use when writing tests, designing test architecture, or debugging test failures.","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[116,124,36,125,126,127,113,128,111,129,130,131,25,132,133,134,135,136,24,137],"ci","playwright","snapshot","coverage","e2e","tdd","integration","test","writing tests","debugging","workflow","implement","writing","e2e testing",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":37},"01M6C33AER10BH236SAP89GJP6","superpowers","Core engineering workflow that activates on EVERY task. Enforces systematic plan-before-code methodology, multi-file refactoring safety, dependency-aware changes, pre-flight verification, and zero-placeholder quality standards. Use PROACTIVELY on all coding tasks.","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers\u002FSKILL.md",[],[140,145,146,147,134,148,149,150,36,151,152,153,154,29,155,156,157,158],"core","tasks","placeholder","code","coding","dependency","quality","refactoring","plan","Safety","ZeRO","engineering","file","verification",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":166,"publishedAt":37},"01M6C3380VVQHM6CCC843MH5S3","styling","Implement production styling systems with Tailwind CSS, vanilla CSS, or CSS-in-JS. Covers CSS architecture (BEM, utility-first, modules), design tokens, responsive patterns, animation systems, dark mode, container queries, print styles, and performance optimization. Use when implementing designs or building CSS architectures.","https:\u002F\u002Fgithub.com\u002FRaheesAhmed\u002FSajiCode\u002Fblob\u002Fmain\u002Fskills\u002Fstyling\u002FSKILL.md",[165],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[161,167,168,36,169,170,171,172,173,174,25,135,175,176,24],"Tailwind","container","performance optimization","js","Animation","first","Production","Optimization","performance","css"]