[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71JT00KC13S2KF3VYV5A34D":3,"skill-same:01M71JT00KC13S2KF3VYV5A34D":98},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M71JT00KC13S2KF3VYV5A34D","c4-architecture",null,"Generate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, or generate context\u002Fcontainer\u002Fcomponent\u002Fdeployment diagrams.","coco-research\u002Fcoco","coco-research","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F68911604?v=4","01M71JRE9C4NM4NSZM4JD0BJTB","Coco Research","01M71JREA0ZMR0PMH3CKA99SN1",631,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fc4-architecture\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"architecture","c4 architecture","code","create architecture","when","generic","software","structure","diagrams","context","model","system","visualize","generate","create","deployment","architecture diagrams","mermaid","documentation","component","2026-11-10 10:12:30",false,"---\nname: c4-architecture\ndescription: \"Generate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, or generate context\u002Fcontainer\u002Fcomponent\u002Fdeployment diagrams.\"\ndomain: engineering\nsupports: [claude-code, cursor, codex, generic]\nversion: 0.1.0\n---\n\n# C4 Architecture Documentation\n\nGenerate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, create C4 diagrams, or generate context\u002Fcontainer\u002Fcomponent\u002Fdeployment diagrams. Triggers include \"architecture diagram\", \"C4 diagram\", \"system context\", \"container diagram\", \"component diagram\", \"deployment diagram\", \"document architecture\", \"visualize architecture\".\n\n## Workflow\n\n1. **Understand scope** — Determine which C4 level(s) are needed based on audience\n2. **Analyze codebase** — Explore the system to identify components, containers, and relationships\n3. **Generate diagrams** — Create Mermaid C4 diagrams at appropriate abstraction levels\n4. **Document** — Write diagrams to markdown files with explanatory context\n\n## C4 Diagram Levels\n\nSelect the appropriate level based on the documentation need:\n\n| Level | Diagram Type | Audience | Shows | When to Create |\n|-------|-------------|----------|-------|----------------|\n| 1 | **C4Context** | Everyone | System + external actors | Always (required) |\n| 2 | **C4Container** | Technical | Apps, databases, services | Always (required) |\n| 3 | **C4Component** | Developers | Internal components | Only if adds value |\n| 4 | **C4Deployment** | DevOps | Infrastructure nodes | For production systems |\n| - | **C4Dynamic** | Technical | Request flows (numbered) | For complex workflows |\n\n**Key Insight:** \"Context + Container diagrams are sufficient for most software development teams.\" Only create Component\u002FCode diagrams when they genuinely add value.\n\n## Quick Start Examples\n\n### System Context (Level 1)\n```mermaid\nC4Context\n  title System Context - Workout Tracker\n\n  Person(user, \"User\", \"Tracks workouts and exercises\")\n  System(app, \"Workout Tracker\", \"Vue PWA for tracking strength and CrossFit workouts\")\n  System_Ext(browser, \"Web Browser\", \"Stores data in IndexedDB\")\n\n  Rel(user, app, \"Uses\")\n  Rel(app, browser, \"Persists data to\", \"IndexedDB\")\n```\n\n### Container Diagram (Level 2)\n\nWhen the request names apps, services, workers, databases, or queues, draw each name as exactly one element: `Container` for an app, service, or worker; `ContainerDb` for a database or store; `ContainerQueue` for a queue or topic. Put that name in the label. Do not make it a `Container_Boundary` and do not invent inner containers or components. Pass only element aliases to `Rel`, never a boundary alias. Keep the request's direction: `A calls B`, `A writes to B`, `A reads B`, `A pulls from B`, `A drains B`, and `from A to B` are all `Rel(a, b, ...)`.\n\n```mermaid\nC4Container\n  title Container Diagram - Checkout\n\n  Container(shop, \"Basket App\", \"React\", \"Places orders\")\n  Container(api, \"Catalog API\", \"Java\", \"Accepts orders\")\n  ContainerDb(db, \"Catalog DB\", \"PostgreSQL\", \"Product rows\")\n  ContainerQueue(bus, \"Price Queue\", \"Kafka\", \"Price events\")\n  Container(worker, \"Index Worker\", \"Java\", \"Updates search\")\n\n  Rel(shop, api, \"Sends orders to\", \"JSON\u002FHTTPS\")\n  Rel(api, db, \"Writes to\", \"JDBC\")\n  Rel(api, bus, \"Publishes to\")\n  Rel(bus, worker, \"Delivers events to\")\n```\n\nThe workout diagram below breaks one app into internal containers. For a list of named containers, use the flat form above.\n\n```mermaid\nC4Container\n  title Container Diagram - Workout Tracker\n\n  Person(user, \"User\", \"Tracks workouts\")\n\n  Container_Boundary(app, \"Workout Tracker PWA\") {\n    Container(spa, \"SPA\", \"Vue 3, TypeScript\", \"Single-page application\")\n    Container(pinia, \"State Management\", \"Pinia\", \"Manages application state\")\n    ContainerDb(indexeddb, \"IndexedDB\", \"Dexie\", \"Local workout storage\")\n  }\n\n  Rel(user, spa, \"Uses\")\n  Rel(spa, pinia, \"Reads\u002Fwrites state\")\n  Rel(pinia, indexeddb, \"Persists\", \"Dexie ORM\")\n```\n\n**Named parts are elements, not boundaries.** On `C4Container`, each app, service, worker, portal, console, screen, database, store, and queue the user names is one element. Put that exact name in the label:\n\n- app, service, worker, portal, console, or screen → `Container(alias, \"Name\", \"tech\", \"description\")`\n- database or store → `ContainerDb(alias, \"Name\", \"tech\", \"description\")`\n- queue or topic → `ContainerQueue(alias, \"Name\", \"tech\", \"description\")`\n\nDo not declare that name as `Container_Boundary` and do not nest `Component`s under it. A boundary cannot be a `Rel` endpoint. Aim the arrow with the sentence: \"A calls B\" \u002F \"A writes to B\" → `Rel(a, b, \"...\")`; \"events flow from the queue to the worker\" → `Rel(queue, worker, \"...\")`; \"the worker pulls or drains the queue\" → `Rel(worker, queue, \"...\")`.\n\n```mermaid\nC4Container\n  title Container Diagram - Parcel Desk\n  Container(desk, \"Desk App\", \"React\", \"Creates bookings\")\n  Container(api, \"Booking API\", \"Go\", \"Reads and writes bookings\")\n  ContainerDb(db, \"Booking DB\", \"PostgreSQL\", \"Booking records\")\n  ContainerQueue(q, \"Job Queue\", \"SQS\", \"Booking events\")\n  Container(worker, \"Ticket Worker\", \"Go\", \"Issues tickets\")\n  Rel(desk, api, \"Calls\", \"JSON\u002FHTTPS\")\n  Rel(api, db, \"Reads and writes\", \"SQL\")\n  Rel(api, q, \"Publishes events to\")\n  Rel(q, worker, \"Delivers events to\")\n```\n\nA container diagram declares each named app, service, worker, database, queue, or external system once: `Container`, `ContainerDb`, `ContainerQueue`, or `Container_Ext`, with that name as the label. `Rel` may use only those aliases, or `Person` for a human. Never pass a `Container_Boundary`, `System_Boundary`, or `Deployment_Node` alias — above, arrows go to `spa`, not `app`. Do not replace a named container with a boundary that holds some other element.\n\nInvalid: `Container_Boundary(api, \"Checkout API\") { Container(handler, \"Handler\", \"Node\", \"Handles calls\") }` then `Rel(shop, api, \"Calls\")`.\nValid: `Container(shop, \"Storefront\", \"React\", \"Takes orders\")`, `Container(api, \"Checkout API\", \"Node.js\", \"Validates orders\")`, `ContainerDb(db, \"Catalog DB\", \"PostgreSQL\", \"Product rows\")`, `Rel(shop, api, \"Submits orders\", \"JSON\u002FHTTPS\")`, `Rel(api, db, \"Reads\", \"SQL\")`.\n\n### Component Diagram (Level 3)\n```mermaid\nC4Component\n  title Component Diagram - Workout Feature\n\n  Container(views, \"Views\", \"Vue Router pages\")\n\n  Container_Boundary(workout, \"Workout Feature\") {\n    Component(useWorkout, \"useWorkout\", \"Composable\", \"Workout execution state\")\n    Component(useTimer, \"useTimer\", \"Composable\", \"Timer state machine\")\n    Component(workoutRepo, \"WorkoutRepository\", \"Dexie\", \"Workout persistence\")\n  }\n\n  Rel(views, useWorkout, \"Uses\")\n  Rel(useWorkout, useTimer, \"Controls\")\n  Rel(useWorkout, workoutRepo, \"Saves to\")\n```\n\n### Dynamic Diagram (Request Flow)\n```mermaid\nC4Dynamic\n  title Dynamic Diagram - User Sign In Flow\n\n  ContainerDb(db, \"Database\", \"PostgreSQL\", \"User credentials\")\n  Container(spa, \"Single-Page App\", \"React\", \"Banking UI\")\n\n  Container_Boundary(api, \"API Application\") {\n    Component(signIn, \"Sign In Controller\", \"Express\", \"Auth endpoint\")\n    Component(security, \"Security Service\", \"JWT\", \"Validates credentials\")\n  }\n\n  Rel(spa, signIn, \"1. Submit credentials\", \"JSON\u002FHTTPS\")\n  Rel(signIn, security, \"2. Validate\")\n  Rel(security, db, \"3. Query user\", \"SQL\")\n\n  UpdateRelStyle(spa, signIn, $textColor=\"blue\", $offsetY=\"-30\")\n```\n\n### Deployment Diagram\n```mermaid\nC4Deployment\n  title Deployment Diagram - Production\n\n  Deployment_Node(browser, \"Customer Browser\", \"Chrome\u002FFirefox\") {\n    Container(spa, \"SPA\", \"React\", \"Web application\")\n  }\n\n  Deployment_Node(aws, \"AWS Cloud\", \"us-east-1\") {\n    Deployment_Node(ecs, \"ECS Cluster\", \"Fargate\") {\n      Container(api, \"API Service\", \"Node.js\", \"REST API\")\n    }\n    Deployment_Node(rds, \"RDS\", \"db.r5.large\") {\n      ContainerDb(db, \"Database\", \"PostgreSQL\", \"Application data\")\n    }\n  }\n\n  Rel(spa, api, \"API calls\", \"HTTPS\")\n  Rel(api, db, \"Reads\u002Fwrites\", \"JDBC\")\n```\n\n## Element Syntax\n\n### People and Systems\n```\nPerson(alias, \"Label\", \"Description\")\nPerson_Ext(alias, \"Label\", \"Description\")       # External person\nSystem(alias, \"Label\", \"Description\")\nSystem_Ext(alias, \"Label\", \"Description\")       # External system\nSystemDb(alias, \"Label\", \"Description\")         # Database system\nSystemQueue(alias, \"Label\", \"Description\")      # Queue system\n```\n\n### Containers\n```\nContainer(alias, \"Label\", \"Technology\", \"Description\")\nContainer_Ext(alias, \"Label\", \"Technology\", \"Description\")\nContainerDb(alias, \"Label\", \"Technology\", \"Description\")\nContainerQueue(alias, \"Label\", \"Technology\", \"Description\")\n```\n\n### Components\n```\nComponent(alias, \"Label\", \"Technology\", \"Description\")\nComponent_Ext(alias, \"Label\", \"Technology\", \"Description\")\nComponentDb(alias, \"Label\", \"Technology\", \"Description\")\n```\n\n### Boundaries\n```\nEnterprise_Boundary(alias, \"Label\") { ... }\nSystem_Boundary(alias, \"Label\") { ... }\nContainer_Boundary(alias, \"Label\") { ... }\nBoundary(alias, \"Label\", \"type\") { ... }\n```\n\n### Relationships\n```\nRel(from, to, \"Label\")\nRel(from, to, \"Label\", \"Technology\")\nBiRel(from, to, \"Label\")                        # Bidirectional\nRel_U(from, to, \"Label\")                        # Upward\nRel_D(from, to, \"Label\")                        # Downward\nRel_L(from, to, \"Label\")                        # Leftward\nRel_R(from, to, \"Label\")                        # Rightward\n```\n\n### Deployment Nodes\n```\nDeployment_Node(alias, \"Label\", \"Type\", \"Description\") { ... }\nNode(alias, \"Label\", \"Type\", \"Description\") { ... }  # Shorthand\n```\n\n## Styling and Layout\n\n### Layout Configuration\n```\nUpdateLayoutConfig($c4ShapeInRow=\"3\", $c4BoundaryInRow=\"1\")\n```\n- `$c4ShapeInRow` — Number of shapes per row (default: 4)\n- `$c4BoundaryInRow` — Number of boundaries per row (default: 2)\n\n### Element Styling\n```\nUpdateElementStyle(alias, $fontColor=\"red\", $bgColor=\"grey\", $borderColor=\"red\")\n```\n\n### Relationship Styling\n```\nUpdateRelStyle(from, to, $textColor=\"blue\", $lineColor=\"blue\", $offsetX=\"5\", $offsetY=\"-10\")\n```\nUse `$offsetX` and `$offsetY` to fix overlapping relationship labels.\n\n## Best Practices\n\n### Essential Rules\n\n1. **Every element must have**: Name, Type, Technology (where applicable), and Description\n2. **Use unidirectional arrows only** — Bidirectional arrows create ambiguity\n3. **Label arrows with action verbs** — \"Sends email using\", \"Reads from\", not just \"uses\"\n4. **Include technology labels** — \"JSON\u002FHTTPS\", \"JDBC\", \"gRPC\"\n5. **Stay under 20 elements per diagram** — Split complex systems into multiple diagrams\n\n### Clarity Guidelines\n\n1. **Start at Level 1** — Context diagrams help frame the system scope\n2. **One diagram per file** — Keep diagrams focused on a single abstraction level\n3. **Meaningful aliases** — Use descriptive aliases (e.g., `orderService` not `s1`)\n4. **Concise descriptions** — Keep descriptions under 50 characters when possible\n5. **Always include a title** — \"System Context diagram for [System Name]\"\n\n### What to Avoid\n\nSee [references\u002Fcommon-mistakes.md](references\u002Fcommon-mistakes.md) for detailed anti-patterns:\n- Confusing containers (deployable) vs components (non-deployable)\n- Modeling shared libraries as containers\n- Showing message brokers as single containers instead of individual topics\n- Adding undefined abstraction levels like \"subcomponents\"\n- Removing type labels to \"simplify\" diagrams\n\n## Microservices Guidelines\n\n### Single Team Ownership\nModel each microservice as a **container** (or container group):\n```mermaid\nC4Container\n  title Microservices - Single Team\n\n  System_Boundary(platform, \"E-commerce Platform\") {\n    Container(orderApi, \"Order Service\", \"Spring Boot\", \"Order processing\")\n    ContainerDb(orderDb, \"Order DB\", \"PostgreSQL\", \"Order data\")\n    Container(inventoryApi, \"Inventory Service\", \"Node.js\", \"Stock management\")\n    ContainerDb(inventoryDb, \"Inventory DB\", \"MongoDB\", \"Stock data\")\n  }\n```\n\n### Multi-Team Ownership\nPromote microservices to **software systems** when owned by separate teams:\n```mermaid\nC4Context\n  title Microservices - Multi-Team\n\n  Person(customer, \"Customer\", \"Places orders\")\n  System(orderSystem, \"Order System\", \"Team Alpha\")\n  System(inventorySystem, \"Inventory System\", \"Team Beta\")\n  System(paymentSystem, \"Payment System\", \"Team Gamma\")\n\n  Rel(customer, orderSystem, \"Places orders\")\n  Rel(orderSystem, inventorySystem, \"Checks stock\")\n  Rel(orderSystem, paymentSystem, \"Processes payment\")\n```\n\n### Event-Driven Architecture\nShow individual topics\u002Fqueues as containers, NOT a single \"Kafka\" box:\n```mermaid\nC4Container\n  title Event-Driven Architecture\n\n  Container(orderService, \"Order Service\", \"Java\", \"Creates orders\")\n  Container(stockService, \"Stock Service\", \"Java\", \"Manages inventory\")\n  ContainerQueue(orderTopic, \"order.created\", \"Kafka\", \"Order events\")\n  ContainerQueue(stockTopic, \"stock.reserved\", \"Kafka\", \"Stock events\")\n\n  Rel(orderService, orderTopic, \"Publishes to\")\n  Rel(stockService, orderTopic, \"Subscribes to\")\n  Rel(stockService, stockTopic, \"Publishes to\")\n  Rel(orderService, stockTopic, \"Subscribes to\")\n```\n\n## Output Location\n\nWrite architecture documentation to `docs\u002Farchitecture\u002F` with naming convention:\n- `c4-context.md` — System context diagram\n- `c4-containers.md` — Container diagram\n- `c4-components-{feature}.md` — Component diagrams per feature\n- `c4-deployment.md` — Deployment diagram\n- `c4-dynamic-{flow}.md` — Dynamic diagrams for specific flows\n\n## Audience-Appropriate Detail\n\n| Audience | Recommended Diagrams |\n|----------|---------------------|\n| Executives | System Context only |\n| Product Managers | Context + Container |\n| Architects | Context + Container + key Components |\n| Developers | All levels as needed |\n| DevOps | Container + Deployment |\n\n## References\n\n- [references\u002Fc4-syntax.md](references\u002Fc4-syntax.md) — Complete Mermaid C4 syntax\n- [references\u002Fcommon-mistakes.md](references\u002Fcommon-mistakes.md) — Anti-patterns to avoid\n- [references\u002Fadvanced-patterns.md](references\u002Fadvanced-patterns.md) — Microservices, event-driven, deployment\n","# C4 Architecture Documentation\n\nGenerate architecture documentation using C4 model Mermaid diagrams. Use when asked to create architecture diagrams, document system architecture, visualize software structure, create C4 diagrams, or generate context\u002Fcontainer\u002Fcomponent\u002Fdeployment diagrams. Triggers include \"architecture diagram\", \"C4 diagram\", \"system context\", \"container diagram\", \"component diagram\", \"deployment diagram\", \"document architecture\", \"visualize architecture\".\n\n## Workflow\n\n1. **Understand scope** — Determine which C4 level(s) are needed based on audience\n2. **Analyze codebase** — Explore the system to identify components, containers, and relationships\n3. **Generate diagrams** — Create Mermaid C4 diagrams at appropriate abstraction levels\n4. **Document** — Write diagrams to markdown files with explanatory context\n\n## C4 Diagram Levels\n\nSelect the appropriate level based on the documentation need:\n\n| Level | Diagram Type | Audience | Shows | When to Create |\n|-------|-------------|----------|-------|----------------|\n| 1 | **C4Context** | Everyone | System + external actors | Always (required) |\n| 2 | **C4Container** | Technical | Apps, databases, services | Always (required) |\n| 3 | **C4Component** | Developers | Internal components | Only if adds value |\n| 4 | **C4Deployment** | DevOps | Infrastructure nodes | For production systems |\n| - | **C4Dynamic** | Technical | Request flows (numbered) | For complex workflows |\n\n**Key Insight:** \"Context + Container diagrams are sufficient for most software development teams.\" Only create Component\u002FCode diagrams when they genuinely add value.\n\n## Quick Start Examples\n\n### System Context (Level 1)\n```mermaid\nC4Context\n  title System Context - Workout Tracker\n\n  Person(user, \"User\", \"Tracks workouts and exercises\")\n  System(app, \"Workout Tracker\", \"Vue PWA for tracking strength and CrossFit workouts\")\n  System_Ext(browser, \"Web Browser\", \"Stores data in IndexedDB\")\n\n  Rel(user, app, \"Uses\")\n  Rel(app, browser, \"Persists data to\", \"IndexedDB\")\n```\n\n### Container Diagram (Level 2)\n\nWhen the request names apps, services, workers, databases, or queues, draw each name as exactly one element: `Container` for an app, service, or worker; `ContainerDb` for a database or store; `ContainerQueue` for a queue or topic. Put that name in the label. Do not make it a `Container_Boundary` and do not invent inner containers or components. Pass only element aliases to `Rel`, never a boundary alias. Keep the request's direction: `A calls B`, `A writes to B`, `A reads B`, `A pulls from B`, `A drains B`, and `from A to B` are all `Rel(a, b, ...)`.\n\n```mermaid\nC4Container\n  title Container Diagram - Checkout\n\n  Container(shop, \"Basket App\", \"React\", \"Places orders\")\n  Container(api, \"Catalog API\", \"Java\", \"Accepts orders\")\n  ContainerDb(db, \"Catalog DB\", \"PostgreSQL\", \"Product rows\")\n  ContainerQueue(bus, \"Price Queue\", \"Kafka\", \"Price events\")\n  Container(worker, \"Index Worker\", \"Java\", \"Updates search\")\n\n  Rel(shop, api, \"Sends orders to\", \"JSON\u002FHTTPS\")\n  Rel(api, db, \"Writes to\", \"JDBC\")\n  Rel(api, bus, \"Publishes to\")\n  Rel(bus, worker, \"Delivers events to\")\n```\n\nThe workout diagram below breaks one app into internal containers. For a list of named containers, use the flat form above.\n\n```mermaid\nC4Container\n  title Container Diagram - Workout Tracker\n\n  Person(user, \"User\", \"Tracks workouts\")\n\n  Container_Boundary(app, \"Workout Tracker PWA\") {\n    Container(spa, \"SPA\", \"Vue 3, TypeScript\", \"Single-page application\")\n    Container(pinia, \"State Management\", \"Pinia\", \"Manages application state\")\n    ContainerDb(indexeddb, \"IndexedDB\", \"Dexie\", \"Local workout storage\")\n  }\n\n  Rel(user, spa, \"Uses\")\n  Rel(spa, pinia, \"Reads\u002Fwrites state\")\n  Rel(pinia, indexeddb, \"Persists\", \"Dexie ORM\")\n```\n\n**Named parts are elements, not boundaries.** On `C4Container`, each app, service, worker, portal, console, screen, database, store, and queue the user names is one element. Put that exact name in the label:\n\n- app, service, worker, portal, console, or screen → `Container(alias, \"Name\", \"tech\", \"description\")`\n- database or store → `ContainerDb(alias, \"Name\", \"tech\", \"description\")`\n- queue or topic → `ContainerQueue(alias, \"Name\", \"tech\", \"description\")`\n\nDo not declare that name as `Container_Boundary` and do not nest `Component`s under it. A boundary cannot be a `Rel` endpoint. Aim the arrow with the sentence: \"A calls B\" \u002F \"A writes to B\" → `Rel(a, b, \"...\")`; \"events flow from the queue to the worker\" → `Rel(queue, worker, \"...\")`; \"the worker pulls or drains the queue\" → `Rel(worker, queue, \"...\")`.\n\n```mermaid\nC4Container\n  title Container Diagram - Parcel Desk\n  Container(desk, \"Desk App\", \"React\", \"Creates bookings\")\n  Container(api, \"Booking API\", \"Go\", \"Reads and writes bookings\")\n  ContainerDb(db, \"Booking DB\", \"PostgreSQL\", \"Booking records\")\n  ContainerQueue(q, \"Job Queue\", \"SQS\", \"Booking events\")\n  Container(worker, \"Ticket Worker\", \"Go\", \"Issues tickets\")\n  Rel(desk, api, \"Calls\", \"JSON\u002FHTTPS\")\n  Rel(api, db, \"Reads and writes\", \"SQL\")\n  Rel(api, q, \"Publishes events to\")\n  Rel(q, worker, \"Delivers events to\")\n```\n\nA container diagram declares each named app, service, worker, database, queue, or external system once: `Container`, `ContainerDb`, `ContainerQueue`, or `Container_Ext`, with that name as the label. `Rel` may use only those aliases, or `Person` for a human. Never pass a `Container_Boundary`, `System_Boundary`, or `Deployment_Node` alias — above, arrows go to `spa`, not `app`. Do not replace a named container with a boundary that holds some other element.\n\nInvalid: `Container_Boundary(api, \"Checkout API\") { Container(handler, \"Handler\", \"Node\", \"Handles calls\") }` then `Rel(shop, api, \"Calls\")`.\nValid: `Container(shop, \"Storefront\", \"React\", \"Takes orders\")`, `Container(api, \"Checkout API\", \"Node.js\", \"Validates orders\")`, `ContainerDb(db, \"Catalog DB\", \"PostgreSQL\", \"Product rows\")`, `Rel(shop, api, \"Submits orders\", \"JSON\u002FHTTPS\")`, `Rel(api, db, \"Reads\", \"SQL\")`.\n\n### Component Diagram (Level 3)\n```mermaid\nC4Component\n  title Component Diagram - Workout Feature\n\n  Container(views, \"Views\", \"Vue Router pages\")\n\n  Container_Boundary(workout, \"Workout Feature\") {\n    Component(useWorkout, \"useWorkout\", \"Composable\", \"Workout execution state\")\n    Component(useTimer, \"useTimer\", \"Composable\", \"Timer state machine\")\n    Component(workoutRepo, \"WorkoutRepository\", \"Dexie\", \"Workout persistence\")\n  }\n\n  Rel(views, useWorkout, \"Uses\")\n  Rel(useWorkout, useTimer, \"Controls\")\n  Rel(useWorkout, workoutRepo, \"Saves to\")\n```\n\n### Dynamic Diagram (Request Flow)\n```mermaid\nC4Dynamic\n  title Dynamic Diagram - User Sign In Flow\n\n  ContainerDb(db, \"Database\", \"PostgreSQL\", \"User credentials\")\n  Container(spa, \"Single-Page App\", \"React\", \"Banking UI\")\n\n  Container_Boundary(api, \"API Application\") {\n    Component(signIn, \"Sign In Controller\", \"Express\", \"Auth endpoint\")\n    Component(security, \"Security Service\", \"JWT\", \"Validates credentials\")\n  }\n\n  Rel(spa, signIn, \"1. Submit credentials\", \"JSON\u002FHTTPS\")\n  Rel(signIn, security, \"2. Validate\")\n  Rel(security, db, \"3. Query user\", \"SQL\")\n\n  UpdateRelStyle(spa, signIn, $textColor=\"blue\", $offsetY=\"-30\")\n```\n\n### Deployment Diagram\n```mermaid\nC4Deployment\n  title Deployment Diagram - Production\n\n  Deployment_Node(browser, \"Customer Browser\", \"Chrome\u002FFirefox\") {\n    Container(spa, \"SPA\", \"React\", \"Web application\")\n  }\n\n  Deployment_Node(aws, \"AWS Cloud\", \"us-east-1\") {\n    Deployment_Node(ecs, \"ECS Cluster\", \"Fargate\") {\n      Container(api, \"API Service\", \"Node.js\", \"REST API\")\n    }\n    Deployment_Node(rds, \"RDS\", \"db.r5.large\") {\n      ContainerDb(db, \"Database\", \"PostgreSQL\", \"Application data\")\n    }\n  }\n\n  Rel(spa, api, \"API calls\", \"HTTPS\")\n  Rel(api, db, \"Reads\u002Fwrites\", \"JDBC\")\n```\n\n## Element Syntax\n\n### People and Systems\n```\nPerson(alias, \"Label\", \"Description\")\nPerson_Ext(alias, \"Label\", \"Description\")       # External person\nSystem(alias, \"Label\", \"Description\")\nSystem_Ext(alias, \"Label\", \"Description\")       # External system\nSystemDb(alias, \"Label\", \"Description\")         # Database system\nSystemQueue(alias, \"Label\", \"Description\")      # Queue system\n```\n\n### Containers\n```\nContainer(alias, \"Label\", \"Technology\", \"Description\")\nContainer_Ext(alias, \"Label\", \"Technology\", \"Description\")\nContainerDb(alias, \"Label\", \"Technology\", \"Description\")\nContainerQueue(alias, \"Label\", \"Technology\", \"Description\")\n```\n\n### Components\n```\nComponent(alias, \"Label\", \"Technology\", \"Description\")\nComponent_Ext(alias, \"Label\", \"Technology\", \"Description\")\nComponentDb(alias, \"Label\", \"Technology\", \"Description\")\n```\n\n### Boundaries\n```\nEnterprise_Boundary(alias, \"Label\") { ... }\nSystem_Boundary(alias, \"Label\") { ... }\nContainer_Boundary(alias, \"Label\") { ... }\nBoundary(alias, \"Label\", \"type\") { ... }\n```\n\n### Relationships\n```\nRel(from, to, \"Label\")\nRel(from, to, \"Label\", \"Technology\")\nBiRel(from, to, \"Label\")                        # Bidirectional\nRel_U(from, to, \"Label\")                        # Upward\nRel_D(from, to, \"Label\")                        # Downward\nRel_L(from, to, \"Label\")                        # Leftward\nRel_R(from, to, \"Label\")                        # Rightward\n```\n\n### Deployment Nodes\n```\nDeployment_Node(alias, \"Label\", \"Type\", \"Description\") { ... }\nNode(alias, \"Label\", \"Type\", \"Description\") { ... }  # Shorthand\n```\n\n## Styling and Layout\n\n### Layout Configuration\n```\nUpdateLayoutConfig($c4ShapeInRow=\"3\", $c4BoundaryInRow=\"1\")\n```\n- `$c4ShapeInRow` — Number of shapes per row (default: 4)\n- `$c4BoundaryInRow` — Number of boundaries per row (default: 2)\n\n### Element Styling\n```\nUpdateElementStyle(alias, $fontColor=\"red\", $bgColor=\"grey\", $borderColor=\"red\")\n```\n\n### Relationship Styling\n```\nUpdateRelStyle(from, to, $textColor=\"blue\", $lineColor=\"blue\", $offsetX=\"5\", $offsetY=\"-10\")\n```\nUse `$offsetX` and `$offsetY` to fix overlapping relationship labels.\n\n## Best Practices\n\n### Essential Rules\n\n1. **Every element must have**: Name, Type, Technology (where applicable), and Description\n2. **Use unidirectional arrows only** — Bidirectional arrows create ambiguity\n3. **Label arrows with action verbs** — \"Sends email using\", \"Reads from\", not just \"uses\"\n4. **Include technology labels** — \"JSON\u002FHTTPS\", \"JDBC\", \"gRPC\"\n5. **Stay under 20 elements per diagram** — Split complex systems into multiple diagrams\n\n### Clarity Guidelines\n\n1. **Start at Level 1** — Context diagrams help frame the system scope\n2. **One diagram per file** — Keep diagrams focused on a single abstraction level\n3. **Meaningful aliases** — Use descriptive aliases (e.g., `orderService` not `s1`)\n4. **Concise descriptions** — Keep descriptions under 50 characters when possible\n5. **Always include a title** — \"System Context diagram for [System Name]\"\n\n### What to Avoid\n\nSee [references\u002Fcommon-mistakes.md](references\u002Fcommon-mistakes.md) for detailed anti-patterns:\n- Confusing containers (deployable) vs components (non-deployable)\n- Modeling shared libraries as containers\n- Showing message brokers as single containers instead of individual topics\n- Adding undefined abstraction levels like \"subcomponents\"\n- Removing type labels to \"simplify\" diagrams\n\n## Microservices Guidelines\n\n### Single Team Ownership\nModel each microservice as a **container** (or container group):\n```mermaid\nC4Container\n  title Microservices - Single Team\n\n  System_Boundary(platform, \"E-commerce Platform\") {\n    Container(orderApi, \"Order Service\", \"Spring Boot\", \"Order processing\")\n    ContainerDb(orderDb, \"Order DB\", \"PostgreSQL\", \"Order data\")\n    Container(inventoryApi, \"Inventory Service\", \"Node.js\", \"Stock management\")\n    ContainerDb(inventoryDb, \"Inventory DB\", \"MongoDB\", \"Stock data\")\n  }\n```\n\n### Multi-Team Ownership\nPromote microservices to **software systems** when owned by separate teams:\n```mermaid\nC4Context\n  title Microservices - Multi-Team\n\n  Person(customer, \"Customer\", \"Places orders\")\n  System(orderSystem, \"Order System\", \"Team Alpha\")\n  System(inventorySystem, \"Inventory System\", \"Team Beta\")\n  System(paymentSystem, \"Payment System\", \"Team Gamma\")\n\n  Rel(customer, orderSystem, \"Places orders\")\n  Rel(orderSystem, inventorySystem, \"Checks stock\")\n  Rel(orderSystem, paymentSystem, \"Processes payment\")\n```\n\n### Event-Driven Architecture\nShow individual topics\u002Fqueues as containers, NOT a single \"Kafka\" box:\n```mermaid\nC4Container\n  title Event-Driven Architecture\n\n  Container(orderService, \"Order Service\", \"Java\", \"Creates orders\")\n  Container(stockService, \"Stock Service\", \"Java\", \"Manages inventory\")\n  ContainerQueue(orderTopic, \"order.created\", \"Kafka\", \"Order events\")\n  ContainerQueue(stockTopic, \"stock.reserved\", \"Kafka\", \"Stock events\")\n\n  Rel(orderService, orderTopic, \"Publishes to\")\n  Rel(stockService, orderTopic, \"Subscribes to\")\n  Rel(stockService, stockTopic, \"Publishes to\")\n  Rel(orderService, stockTopic, \"Subscribes to\")\n```\n\n## Output Location\n\nWrite architecture documentation to `docs\u002Farchitecture\u002F` with naming convention:\n- `c4-context.md` — System context diagram\n- `c4-containers.md` — Container diagram\n- `c4-components-{feature}.md` — Component diagrams per feature\n- `c4-deployment.md` — Deployment diagram\n- `c4-dynamic-{flow}.md` — Dynamic diagrams for specific flows\n\n## Audience-Appropriate Detail\n\n| Audience | Recommended Diagrams |\n|----------|---------------------|\n| Executives | System Context only |\n| Product Managers | Context + Container |\n| Architects | Context + Container + key Components |\n| Developers | All levels as needed |\n| DevOps | Container + Deployment |\n\n## References\n\n- [references\u002Fc4-syntax.md](references\u002Fc4-syntax.md) — Complete Mermaid C4 syntax\n- [references\u002Fcommon-mistakes.md](references\u002Fcommon-mistakes.md) — Anti-patterns to avoid\n- [references\u002Fadvanced-patterns.md](references\u002Fadvanced-patterns.md) — Microservices, event-driven, deployment\n",{"name":5,"domain":54,"version":55,"supports":56,"description":7},"engineering","0.1.0",[57,58,59,34],"claude-code","cursor","codex","main","cd89f013b617f7eea982a9bbc60e992974fda2aa","skills\u002Fc4-architecture",15,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco","https:\u002F\u002Fcocoresearch.org\u002Fcoco\u002F","https:\u002F\u002Fgithub.com\u002Fcoco-research","https:\u002F\u002Fcocoresearch.org","Local-first, open-source tools for people who work with AI agents: governed memory, agents that check their own work, and data that stays on your machine.","2026-11-11 12:18:13",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add coco-research\u002Fcoco --skill c4-architecture",{"tool":76,"command":77},"bunx","bunx skills add coco-research\u002Fcoco --skill c4-architecture",{"tool":79,"command":80},"pnpm","pnpm dlx skills add coco-research\u002Fcoco --skill c4-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fc4-architecture\u002FSKILL.md",true,[84,90,94],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fadvanced-patterns.md","REFERENCE","参考文档",18346,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fc4-architecture\u002Freferences\u002Fadvanced-patterns.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fc4-syntax.md",14564,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fc4-architecture\u002Freferences\u002Fc4-syntax.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fcommon-mistakes.md",12441,"https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fskills\u002Fc4-architecture\u002Freferences\u002Fcommon-mistakes.md",[99,124,134,150,185,204],{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":49},"01M71KEJXF9KMT0BWCMRSRFA4M","trading-super-intelligence","Trading Super Intelligence Team. Named real-world personas across 8 cells. Built local-first (LM Studio) and validator-gated. Illustrative composites; see DISCLAIMER.md.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Ftrading\u002FSKILL.md",[105],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123],"super","trading super intelligence","intelligence","trading","validator","personas","local","composites","studio","team","across","world","first","gated","2026","lm studio","local-first",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":49},"01M71KEFWS3CMAP7DF1P0FWTDE","strategy-super-intelligence","Strategy Super Intelligence Team. Named real-world personas across 7 cells. Built local-first (LM Studio) and validator-gated. Illustrative composites; see DISCLAIMER.md.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Fstrategy\u002FSKILL.md",[130],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[132,107,133,109,111,112,113,114,115,116,117,118,119,120,121,122,123],"strategy","strategy super intelligence",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":144,"publishedAt":49},"01M71KED56ZEPK2QE84QSQPMT0","risk-compliance-super-intelligence","Risk & Compliance (GRC) Super Intelligence Team. Named real-world personas across 7 cells. Built local-first (LM Studio) and validator-gated. Illustrative composites; see DISCLAIMER.md.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Frisk-compliance\u002FSKILL.md",[140,141],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":142,"categoryName":143,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[145,107,146,147,148,109,111,112,113,114,149,115,116,117,118,119,120,121,122,123],"risk","risk compliance super intelligence","compliance","risk compliance","grc",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":169,"publishedAt":49},"01M71KE9A2FWSC74VA96W1EZSN","product-design-super-intelligence","Your product + design brain trust and decision partner. Named personas across 8 cells spanning product strategy, discovery\u002Fresearch, growth\u002Fmetrics, design foundations\u002Fusability, design leadership\u002Fcraft, UX\u002Fcontent, design systems, and a…","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Fproduct-design\u002FSKILL.md",[156,159,162,163,166],{"categoryNo":157,"categoryName":158,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":160,"categoryName":161,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":164,"categoryName":165,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理",{"categoryNo":167,"categoryName":168,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[170,171,109,172,107,173,174,175,176,177,178,116,117,179,180,121,181,182,183,184],"design","product","product design","product design super intelligence","foundations","product-design","decision","design systems","usability","leadership","ux","brain","craft","metrics","trust",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":193,"publishedAt":49},"01M71KE6H9FPSD9TECYFBPXZ8Y","legal-ip-super-intelligence","Your legal, IP, and regulatory brain trust. 31 named personas across 7 cells covering patent strategy, tech licensing, regulatory litigation, AI governance, open-source compliance, privacy law, and antitrust.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Flegal-ip\u002FSKILL.md",[191,192],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":142,"categoryName":143,"taxonomyType":26,"taxonomyTypeDesc":27},[194,107,195,109,196,197,184,198,112,199,200,201,132,116,117,202,147,203,121,181],"ip","legal ip super intelligence","legal","sep","tech","litigation","ai governance","open","open-source","governance",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":49},"01M71KE36QRY610V6YVB9JWRND","healthcare-life-sciences-super-intelligence","Your healthcare and life sciences brain trust. 25 named personas across 7 cells covering drug discovery, medtech, biotech strategy, health policy, genomics, clinical trials, and healthcare economics.","https:\u002F\u002Fgithub.com\u002Fcoco-research\u002Fcoco\u002Fblob\u002Fmain\u002Fsystems\u002Fsuperintelligence\u002Fhealthcare-life-sciences\u002FSKILL.md",[210],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[212,107,213,214,109,197,184,215,216,112,217,218,132,116,117,219,220,221,222,121],"healthcare","healthcare life sciences super intelligence","life","economics","discovery","policy","clinical","clinical trials","health","trials","genomics"]