{"id":"4541783e-1c55-402f-a6de-b9794326af42","entityType":"agent","slug":"clawhub-athola-nm-archetypes-architecture-paradigm-layered","name":"architecture-paradigm-layered","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-archetypes-architecture-paradigm-layered","canonicalPath":"/agent/clawhub-athola-nm-archetypes-architecture-paradigm-layered","generatedAt":"2026-10-10T03:55:26.337Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T00:05:23.604Z","emptyReason":null},"description":"Applies layered n-tier architecture with enforced boundaries Skill: architecture-paradigm-layered Owner: athola Summary: Applies layered n-tier architecture with enforced boundaries Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:24.182Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:19.040Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:06.693Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:13.757Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21:20:20.","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.9K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-layered","sourceUrl":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-layered","homepage":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-layered","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":40,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Applies layered n-tier architecture with enforced boundaries Skill: architecture-paradigm-layered Owner: athola Summary: Applies layered n-tier architecture wit"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:05:23.604Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:05:23.604Z","emptyReason":null},"stars":null,"forks":null,"downloads":1854,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.9K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T00:05:23.603Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T00:05:23.604Z","lastCrawledAt":"2026-10-10T00:05:23.603Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T00:05:23.603Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:05:24.182Z","changelog":"Release v1.9.19","fileCount":3,"zipByteSize":4010},{"version":"1.9.18","createdAt":"2026-08-15T21:29:19.040Z","changelog":"Release v1.9.18","fileCount":3,"zipByteSize":4240},{"version":"1.9.17","createdAt":"2026-07-30T05:29:06.693Z","changelog":"Release v1.9.17","fileCount":3,"zipByteSize":4348},{"version":"1.9.16","createdAt":"2026-07-14T19:46:13.757Z","changelog":"Release v1.9.16","fileCount":3,"zipByteSize":4345},{"version":"1.9.15","createdAt":"2026-07-04T21:20:20.653Z","changelog":"Release v1.9.15","fileCount":3,"zipByteSize":4271},{"version":"1.9.14","createdAt":"2026-06-30T17:50:56.936Z","changelog":"Release v1.9.14","fileCount":3,"zipByteSize":4223},{"version":"1.9.13","createdAt":"2026-06-27T16:15:26.218Z","changelog":"Release v1.9.13","fileCount":3,"zipByteSize":4369},{"version":"1.9.12","createdAt":"2026-06-19T03:08:46.618Z","changelog":"Release v1.9.12","fileCount":3,"zipByteSize":4350}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-layered","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-10T03:55:26.335Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-layered/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-10T00:05:23.604Z","emptyReason":null},"readme":"Skill: architecture-paradigm-layered\n\nOwner: athola\n\nSummary: Applies layered n-tier architecture with enforced boundaries\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:05:24.182Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:29:19.040Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:29:06.693Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:46:13.757Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:20:20.653Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:50:56.936Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:15:26.218Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:08:46.618Z | user\n\nRelease v1.9.12\n\nv1.8.6 | 2026-06-07T21:22:44.414Z | user\n\nRelease v1.9.11\n\nv1.8.5 | 2026-05-09T02:15:24.878Z | user\n\nRelease v1.9.5\n\nv1.8.4 | 2026-05-06T14:15:10.267Z | user\n\nRelease v1.9.4\n\nv1.8.3 | 2026-04-10T05:45:39.507Z | user\n\nRelease v1.8.3\n\nv1.8.2 | 2026-04-06T22:07:36.541Z | user\n\nRelease v1.8.2\n\nArchive index:\n\nArchive v1.9.19: 3 files, 4010 bytes\n\nFiles: skill-card.md (1625b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749524182\n}\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nApplies layered n-tier architecture with enforced boundaries.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to decide when layered n-tier architecture fits a system and to plan boundaries, dependencies, deliverables, enforcement tools, and mitigations.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad trigger words may activate the skill in more architecture-related conversations than intended.\n\nMitigation: Confirm that layered architecture guidance is relevant before applying its recommendations.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered)\n- [Publisher profile](https://clawhub.ai/user/athola)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, configuration]\n\n**Output Format:** [Markdown guidance with architecture checklists and implementation recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No code execution; output is advisory architecture guidance.]\n\n## Skill Version(s):\n\n1.9.19 (source: release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.18: 3 files, 4240 bytes\n\nFiles: skill-card.md (2130b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829359040\n}\n\nFile v1.9.18:skill-card.md\n\n## Description:\n\nApplies layered n-tier architecture with enforced boundaries.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to structure moderate systems with clear presentation, application, domain, and persistence boundaries. It helps teams define layer responsibilities, dependency direction, architecture checks, and appropriate cases where layered architecture should or should not be used.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can activate on broad architecture terms and provide general layered-architecture advice in contexts where another architecture pattern may fit better.\n\nMitigation: Review the advice against the system's scalability, deployment, latency, and team-boundary needs before adopting the pattern.\n\nRisk: The skill references a separate Claude Code plugin that is not included in this artifact.\n\nMitigation: Review that separate plugin before installing it if plugin-specific agents, hooks, or commands are needed.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered)\n- [Publisher profile](https://clawhub.ai/user/athola)\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, code, configuration]\n\n**Output Format:** [Markdown guidance with architecture examples, tool recommendations, and implementation checklists]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Documentation-only; produces advisory architecture content and does not execute tools or commands.]\n\n## Skill Version(s):\n\n1.9.18 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.9.17: 3 files, 4348 bytes\n\nFiles: skill-card.md (2425b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389346693\n}\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nApplies layered n-tier architecture with enforced boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architects use this skill when evaluating or adopting layered n-tier architecture for moderate systems that need clear presentation, domain, and persistence boundaries. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate during general architecture or domain-design conversations where layered architecture is not the best fit. <br>\nMitigation: Confirm that the task specifically benefits from layered n-tier guidance before applying the recommendations. <br>\nRisk: Layered architecture guidance can introduce rigidity, pass-through code, or latency if applied to systems that need independent scaling or frequent cross-layer interaction. <br>\nMitigation: Review the proposed layering against project scalability, deployment, and business-logic constraints before adoption. <br>\nRisk: Architecture recommendations may be incomplete or misleading if used without project-specific review. <br>\nMitigation: Have developers or architects review dependency rules, ADRs, diagrams, and enforcement checks before implementation. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered) <br>\n- [Claude Night Market archetypes homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Markdown guidance with architecture steps, deliverables, tool suggestions, and risk notes] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No code execution, data access, persistence, or hidden behavior identified in server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: server release metadata; artifact frontmatter lists 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.16: 3 files, 4345 bytes\n\nFiles: skill-card.md (2439b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784058373757\n}\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nApplies layered n-tier architecture with enforced boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architects use this skill to decide when layered or n-tier architecture fits moderate systems and to plan layer responsibilities, dependency rules, ADRs, diagrams, and architecture checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Generic architecture and domain triggers may activate this guidance in broad design conversations where layered architecture is not the right fit. <br>\nMitigation: Confirm the system context matches the skill's stated layered or n-tier use cases before following recommendations. <br>\nRisk: Strict layering can create pass-through code or latency for features that naturally cross layers. <br>\nMitigation: Use the documented facade or exception guidance and review tradeoffs before enforcing strict layer boundaries. <br>\nRisk: Layer boundary recommendations may be applied without project-specific validation. <br>\nMitigation: Have developers or architects review proposed ADRs, dependency diagrams, and automated checks before adopting them. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered) <br>\n- [Publisher Profile](https://clawhub.ai/user/athola) <br>\n- [Project Homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Code, Configuration, Guidance] <br>\n**Output Format:** [Markdown guidance with architecture recommendations, deliverable outlines, and example tooling suggestions.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No executable behavior; outputs are advisory and should be reviewed before applying to architecture decisions.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (source: server release evidence; artifact frontmatter lists 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.15: 3 files, 4271 bytes\n\nFiles: skill-card.md (2217b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.15:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.15:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.15\",\n  \"publishedAt\": 1783200020653\n}\n\nFile v1.9.15:skill-card.md\n\n## Description: <br>\nApplies layered n-tier architecture with enforced boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architects use this skill to evaluate and apply layered n-tier architecture patterns for moderate systems that need clear presentation, domain, and persistence boundaries. It helps define layer responsibilities, dependency direction, ADRs, diagrams, and architecture checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad activation triggers may surface layered-architecture recommendations in general architecture or domain-modeling conversations. <br>\nMitigation: Treat the recommendations as optional guidance and confirm that layered architecture fits the project before applying it. <br>\nRisk: Strict layering can add pass-through code or latency when features need frequent cross-layer communication. <br>\nMitigation: Use the skill's stated not-use conditions and allow reviewed exceptions, such as a facade, when strict layering does not fit. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered) <br>\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance] <br>\n**Output Format:** [Markdown guidance with lists, architecture recommendations, and example implementation patterns] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only guidance; no executable behavior or credential use was identified by server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.15 (source: server release metadata; artifact frontmatter says 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.14: 3 files, 4223 bytes\n\nFiles: skill-card.md (2127b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782841856936\n}\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nApplies layered n-tier architecture with enforced boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architecture teams use this skill to evaluate when layered n-tier architecture fits a system and to plan boundaries, dependency direction, deliverables, and enforcement checks. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The trigger language is broad and may cause the skill to steer architecture discussions more often than intended. <br>\nMitigation: Use the skill as advisory guidance and disable or narrow it if it starts affecting unrelated design work. <br>\nRisk: Strict layered architecture can create excess pass-through code or latency for features that span multiple layers. <br>\nMitigation: Allow documented exceptions such as facade interfaces where they preserve clarity without bypassing core boundaries. <br>\nRisk: Layer boundaries may erode if developers bypass dependency rules for expediency. <br>\nMitigation: Use architecture tests, dependency validators, or code review gates to block upward imports and undocumented shortcuts. <br>\n\n\n## Reference(s): <br>\n- [Claude Night Market archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Markdown guidance with architecture recommendations and implementation checklists] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Non-executable advisory output for architecture discussions.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.13: 3 files, 4369 bytes\n\nFiles: skill-card.md (2517b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782576926218\n}\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nApplies layered n-tier architecture with enforced boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and architecture reviewers use this skill to decide when layered n-tier architecture fits a moderate system and to produce guidance for layer boundaries, dependency direction, enforcement, and ADR or diagram deliverables. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger wording may activate the skill during general architecture or domain-design discussions. <br>\nMitigation: Confirm that the user wants layered architecture guidance before applying the paradigm, or tighten trigger wording for narrower activation. <br>\nRisk: Layered architecture can be a poor fit for systems needing independent component scaling, independent team deployments, frequent cross-layer business flows, or low-latency real-time processing. <br>\nMitigation: Check those constraints before recommending the paradigm and consider another architecture when they dominate the system requirements. <br>\nRisk: Strict layers can become rigid or leaky when teams bypass dependency rules for expedience. <br>\nMitigation: Document allowed dependencies in an ADR, maintain dependency diagrams, and enforce layer rules with automated architecture checks. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered) <br>\n- [OpenClaw homepage metadata](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Markdown guidance for architecture decisions, layer definitions, dependency rules, enforcement checks, and risk mitigations.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Prompt-only skill; security evidence reports no code execution or data access behavior.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (source: server release metadata; artifact frontmatter reports 1.9.8) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.9.12: 3 files, 4350 bytes\n\nFiles: skill-card.md (2455b), SKILL.md (5923b), _meta.json (163b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781838526618\n}\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nProvides layered n-tier architecture guidance for agents designing systems with clear presentation, application, domain, and persistence boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nUse when an agent needs to recommend or document a layered architecture, define layer responsibilities, set dependency rules, choose enforcement checks, or prepare architecture deliverables such as ADRs and dependency diagrams. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The security review notes broad activation wording, so the skill may appear in general architecture discussions where layered architecture is not the intended pattern. <br>\nMitigation: Use it for layered architecture, monolith separation, or related design tasks, and confirm that its recommendations fit the user's requested architecture style. <br>\nRisk: Layered architecture guidance can become overly rigid or encourage pass-through code when applied without context. <br>\nMitigation: Review generated guidance against performance, scalability, and team workflow requirements before adopting layer boundaries or enforcement rules. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-layered) <br>\n- [Metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown, configuration] <br>\n**Output Format:** [Concise architecture guidance, ADR-ready notes, dependency-rule descriptions, tool recommendations, and review checklists.] <br>\n**Output Parameters:** [System scope, target stack, desired layers, dependency constraints, compliance needs, and existing monolith or service boundaries.] <br>\n**Other Properties Related to Output:** [The skill has no required runtime tools; it may recommend static analysis or architecture-test configuration for enforcing layer rules.] <br>\n\n## Skill Version(s): <br>\n1.9.12 <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.8.6: 3 files, 4327 bytes\n\nFiles: skill-card.md (2441b), SKILL.md (5923b), _meta.json (162b)\n\nFile v1.8.6:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n\n## Concrete Components\n\nThese vocabulary items name the concrete tools and abstractions\nthat show up when the paradigm is implemented. They are not\nrequired dependencies and they are not part of the skill's\n``tools:`` frontmatter (which is reserved for Claude Code tool\nrestrictions). Use this list to disambiguate during architecture\ndiscussions.\n\n- ``dependency-validator`` -- fails the build when a layer imports above its allowed depth\n- ``layer-enforcer`` -- static-analysis gate that checks namespaces match layer rules\n- ``architecture-compliance-checker`` -- diffs the implemented layer graph against the documented one\n\nFile v1.8.6:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.8.6\",\n  \"publishedAt\": 1780867364414\n}\n\nFile v1.8.6:skill-card.md\n\n## Description: <br>\nApplies layered n-tier architecture with enforced boundaries. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architects use this skill to evaluate when layered n-tier architecture is appropriate and to plan layer boundaries, dependency rules, testing strategy, and architecture enforcement. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad architecture triggers may cause the skill to appear in general architecture or domain-design discussions where a narrower skill may be more relevant. <br>\nMitigation: Review whether the requested architecture task specifically involves layered n-tier boundaries before applying the guidance. <br>\nRisk: Layered architecture guidance can introduce excessive rigidity, pass-through code, or latency when features frequently span layers. <br>\nMitigation: Use the skill's exception guidance and consider facade-style interfaces when strict layering would make the system harder to operate or evolve. <br>\nRisk: Layer bypasses can degrade the intended architecture over time. <br>\nMitigation: Add automated architecture checks and review dependency diagrams before adopting the proposed layer rules. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-layered) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Guidance, Markdown, Configuration] <br>\n**Output Format:** [Markdown guidance with architecture steps, deliverables, technology options, risks, and mitigations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only skill; no code execution, credential access, persistence, or data movement reported by security evidence.] <br>\n\n## Skill Version(s): <br>\n1.8.6 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.8.5: 3 files, 4155 bytes\n\nFiles: skill-card.md (2411b), SKILL.md (5530b), _meta.json (162b)\n\nFile v1.8.5:SKILL.md\n\n---\nname: architecture-paradigm-layered\ndescription: |\n  Layered (n-tier) architecture with enforced layer boundaries and separation of concerns\nversion: 1.9.5\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n- [Troubleshooting](#troubleshooting)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A formal dependency diagram stored with the project documentation.\n- Automated architectural checks (e.g., using ArchUnit, dep-cruise, or custom scripts) to prevent rule violations from being merged.\n\n## Technology Guidance\n\n**Layer Implementation Patterns**:\n- **Presentation Layer**: React/Vue/Angular (Frontend), MVC Controllers (Backend)\n- **Application Layer**: Service classes, Application services, Use case orchestrators\n- **Domain Layer**: Business entities, Domain services, Business rules validation\n- **Data Access Layer**: Repository pattern, ORM mappers, Data access objects (DAO)\n\n**Architecture Enforcement Tools**:\n- **Java**: ArchUnit for dependency rule testing\n- **JavaScript/TypeScript**: ESLint rules with dependency tracking\n- **C#**: NDepend for architectural analysis\n- **Python**: Custom decorators and import analysis tools\n\n**Common Layer Stacks**:\n- **3-Layer**: Presentation → Business Logic → Data Access\n- **4-Layer**: Presentation → Application → Domain → Infrastructure\n- **5-Layer**: UI → Controller → Service → Domain → Persistence\n\n## Real-World Examples\n\n**Enterprise ERP Systems**: SAP and Oracle ERP use layered architecture to separate user interfaces from business logic and database operations, enabling different frontend applications to share the same business rules.\n\n**Banking Applications**: Financial institutions employ layered architecture to maintain strict separation between customer-facing interfaces, transaction processing, and secure data storage for regulatory compliance.\n\n**E-commerce Platforms**: Traditional e-commerce sites use layered architecture to separate product catalogs, shopping cart logic, order processing, and payment handling into distinct layers.\n\n## Risks & Mitigations\n- **Excessive Rigidity and Latency**:\n  - **Mitigation**: For features that span multiple layers, strict adherence can lead to excessive \"pass-through\" code and increased latency. In such cases, consider using a Façade pattern to provide a more direct interface where appropriate.\n- **\"Leaky\" Layers**:\n  - **Mitigation**: Developers may be tempted to bypass architectural rules for expediency, which degrades the architecture. Treat all architectural violations as build-breaking failures or critical issues in code review.\n## Troubleshooting\n\n### Common Issues\n\n**Command not found**\nEnsure all dependencies are installed and in PATH\n\n**Permission errors**\nCheck file permissions and run with appropriate privileges\n\n**Unexpected behavior**\nEnable verbose logging with `--verbose` flag\n\nFile v1.8.5:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.8.5\",\n  \"publishedAt\": 1778292924878\n}\n\nFile v1.8.5:skill-card.md\n\n## Description: <br>\nLayered (n-tier) architecture guidance with enforced layer boundaries and separation of concerns. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[athola](https://clawhub.ai/user/athola) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and software architects use this skill to decide when layered architecture is appropriate and to plan layer boundaries, dependency rules, deliverables, enforcement tooling, and mitigations. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger terms may surface layered-architecture guidance in contexts where the pattern is not appropriate. <br>\nMitigation: Review the system's scaling, deployment, cross-layer communication, and real-time requirements before applying the recommendations. <br>\nRisk: The linked external Claude Code plugin may include agents, hooks, or commands that were not evaluated by this release scan. <br>\nMitigation: Review and scan the external plugin separately before installing or running it. <br>\nRisk: Strict layering can introduce pass-through code, latency, or leaky abstractions when applied too rigidly. <br>\nMitigation: Use documented exceptions, architecture tests, code review, and patterns such as a facade where the artifact's guidance supports them. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-layered) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [Clawdis homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance, configuration] <br>\n**Output Format:** [Markdown guidance with architecture recommendations and checklist-style deliverables] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only skill; no executable code or automatic access to user data.] <br>\n\n## Skill Version(s): <br>\n1.8.5 (source: server release metadata; artifact frontmatter says 1.9.5) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: architecture-paradigm-layered Owner: athola Summary: Applies layered n-tier architecture with enforced boundaries Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:24.182Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:19.040Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:06.693Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:13.757Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21:20:20.","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: architecture-paradigm-layered\ndescription: Applies layered n-tier architecture with enforced boundaries\nversion: 1.9.8\ntriggers:\n  - architecture\n  - layered\n  - n-tier\n  - separation-of-concerns\n  - monolith\n  - designing moderate systems needing clear presentation\n  - domain\n  - and persistence layers\nmetadata: {\"openclaw\": {\"homepage\": \"https://github.com/athola/claude-night-market/tree/master/plugins/archetypes\", \"emoji\": \"\\ud83c\\udfd7\\ufe0f\"}}\nsource: claude-night-market\nsource_plugin: archetypes\n---\n\n> **Night Market Skill** — ported from [claude-night-market/archetypes](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes). For the full experience with agents, hooks, and commands, install the Claude Code plugin.\n\n\n## Table of Contents\n\n- [When to Employ This Paradigm](#when-to-employ-this-paradigm)\n- [When NOT to Use This Paradigm](#when-not-to-use-this-paradigm)\n- [Adoption Steps](#adoption-steps)\n- [Key Deliverables](#key-deliverables)\n- [Technology Guidance](#technology-guidance)\n- [Risks & Mitigations](#risks-mitigations)\n\n# The Layered (N-Tier) Architecture Paradigm\n\n## When to Employ This Paradigm\n- When teams need clear architectural boundaries and a familiar structure for moderate-sized systems.\n- When compliance or operations teams require clear separation of concerns (e.g., UI vs. domain logic vs. persistence).\n- When the deployment artifact remains a monolith, but code clarity and separation are degrading.\n\n## When NOT To Use This Paradigm\n- When high scalability demands require independent scaling of components\n- When multiple teams need independent deployment cycles\n- When complex business logic requires frequent cross-layer communication\n- When microservices architecture is already planned or in place\n- When real-time processing requirements make layered communication too slow\n\n## Adoption Steps\n1. **Define the Layers**: Establish a clear set of layers. A common stack includes: Presentation -> Application/Service -> Domain -> Data Access.\n2. **Enforce Dependency Direction**: Code in a given layer may only depend on the layer immediately below it. Forbid any \"upward\" dependencies or imports.\n3. **Centralize Cross-Cutting Concerns**: Implement concerns like logging, authentication, and validation as centralized middleware or policies, rather than duplicating this logic in each layer.\n4. **Test Each Layer Appropriately**: Apply testing strategies suitable for each layer, such as unit tests for the domain layer, service-layer tests for orchestration logic, and integration tests for persistence adapters.\n5. **Document and Enforce Interactions**: Maintain up-to-date dependency diagrams and use automated architecture tests to prevent developers from creating \"shortcut\" dependencies that violate the layering rules.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) that captures the responsibilities of each layer, the allowed dependencies between them, and the policy for any exceptions.\n- A"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-layered\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749524182\n}"},{"path":"skill-card.md","content":"## Description:\n\nApplies layered n-tier architecture with enforced boundaries.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[athola](https://clawhub.ai/user/athola)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to decide when layered n-tier architecture fits a system and to plan boundaries, dependencies, deliverables, enforcement tools, and mitigations.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Broad trigger words may activate the skill in more architecture-related conversations than intended.\n\nMitigation: Confirm that layered architecture guidance is relevant before applying its recommendations.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-layered)\n- [Publisher profile](https://clawhub.ai/user/athola)\n- [OpenClaw homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, markdown, configuration]\n\n**Output Format:** [Markdown guidance with architecture checklists and implementation recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No code execution; output is advisory architecture guidance.]\n\n## Skill Version(s):\n\n1.9.19 (source: release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Applies layered n-tier architecture with enforced boundaries Skill: architecture-paradigm-layered Owner: athola Summary: Applies layered n-tier architecture with enforced boundaries Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:24.182Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:19.040Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:29:06.693Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:13.757Z | user Release v1.9.16 v1.9.15 | 2026-07-04T21:20:20.","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":966,"uniquenessScore":56,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T00:05:23.604Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-10T00:05:23.604Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-10T03:55:26.337Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}