{"id":"2220b9dd-5252-4746-b91b-6776a0a849f1","entityType":"agent","slug":"clawhub-athola-nm-archetypes-architecture-paradigm-functional-c","name":"architecture-paradigm-functional-core","canonicalUrl":"https://www.xpersona.co/agent/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c","canonicalPath":"/agent/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c","generatedAt":"2026-10-10T03:53:22.764Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-10T02:09:59.688Z","emptyReason":null},"description":"Applies Functional Core, Imperative Shell to isolate logic from side effects Skill: architecture-paradigm-functional-core Owner: athola Summary: Applies Functional Core, Imperative Shell to isolate logic from side effects Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:13.365Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:09.472Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:28:58.035Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:06.054Z | user Release v1.9.16 v1.9.1","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.8K downloads reported by the source. Last updated 10/10/2026.","installCommand":"clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-archetypes-architecture-paradigm-functional-core","sourceUrl":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-functional-core","homepage":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-functional-core","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":40,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Applies Functional Core, Imperative Shell to isolate logic from side effects Skill: architecture-paradigm-functional-core Owner: athola Summary: Applies Functio"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:09:59.688Z","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-10T02:09:59.688Z","emptyReason":null},"stars":null,"forks":null,"downloads":1784,"packageName":null,"latestVersion":"1.9.19","tractionLabel":"1.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-10T02:09:59.688Z","emptyReason":null},"lastUpdatedAt":"2026-10-10T02:09:59.688Z","lastCrawledAt":"2026-10-10T02:09:59.688Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-11T02:09:59.688Z","lastVerifiedAt":null,"highlights":[{"version":"1.9.19","createdAt":"2026-08-26T13:05:13.365Z","changelog":"Release v1.9.19","fileCount":3,"zipByteSize":3730},{"version":"1.9.18","createdAt":"2026-08-15T21:29:09.472Z","changelog":"Release v1.9.18","fileCount":3,"zipByteSize":3882},{"version":"1.9.17","createdAt":"2026-07-30T05:28:58.035Z","changelog":"Release v1.9.17","fileCount":3,"zipByteSize":3580},{"version":"1.9.16","createdAt":"2026-07-14T19:46:06.054Z","changelog":"Release v1.9.16","fileCount":3,"zipByteSize":3766},{"version":"1.9.15","createdAt":"2026-07-04T21:20:14.638Z","changelog":"Release v1.9.15","fileCount":3,"zipByteSize":3851},{"version":"1.9.14","createdAt":"2026-06-30T17:50:50.926Z","changelog":"Release v1.9.14","fileCount":3,"zipByteSize":3750},{"version":"1.9.13","createdAt":"2026-06-27T16:15:21.058Z","changelog":"Release v1.9.13","fileCount":3,"zipByteSize":3691},{"version":"1.9.12","createdAt":"2026-06-19T03:08:39.882Z","changelog":"Release v1.9.12","fileCount":3,"zipByteSize":3690}]},"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-functional-core","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-functional-c/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/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:53:22.763Z"}},"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-functional-c/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-archetypes-architecture-paradigm-functional-c/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-10T02:09:59.688Z","emptyReason":null},"readme":"Skill: architecture-paradigm-functional-core\n\nOwner: athola\n\nSummary: Applies Functional Core, Imperative Shell to isolate logic from side effects\n\nTags: latest:1.9.19\n\nVersion history:\n\nv1.9.19 | 2026-08-26T13:05:13.365Z | user\n\nRelease v1.9.19\n\nv1.9.18 | 2026-08-15T21:29:09.472Z | user\n\nRelease v1.9.18\n\nv1.9.17 | 2026-07-30T05:28:58.035Z | user\n\nRelease v1.9.17\n\nv1.9.16 | 2026-07-14T19:46:06.054Z | user\n\nRelease v1.9.16\n\nv1.9.15 | 2026-07-04T21:20:14.638Z | user\n\nRelease v1.9.15\n\nv1.9.14 | 2026-06-30T17:50:50.926Z | user\n\nRelease v1.9.14\n\nv1.9.13 | 2026-06-27T16:15:21.058Z | user\n\nRelease v1.9.13\n\nv1.9.12 | 2026-06-19T03:08:39.882Z | user\n\nRelease v1.9.12\n\nv1.8.6 | 2026-06-07T21:22:39.376Z | user\n\nRelease v1.9.11\n\nv1.8.5 | 2026-05-09T02:15:21.804Z | user\n\nRelease v1.9.5\n\nv1.8.4 | 2026-05-06T14:15:05.712Z | user\n\nRelease v1.9.4\n\nv1.8.3 | 2026-04-10T05:45:34.241Z | user\n\nRelease v1.8.3\n\nv1.8.2 | 2026-04-06T22:07:29.246Z | user\n\nRelease v1.8.2\n\nArchive index:\n\nArchive v1.9.19: 3 files, 3730 bytes\n\nFiles: skill-card.md (1974b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.19:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.19:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749513365\n}\n\nFile v1.9.19:skill-card.md\n\n## Description:\n\nApplies Functional Core, Imperative Shell to isolate logic from side effects.\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 separate pure business logic from side effects, improving testability and making architecture changes easier to reason about.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate during general architecture, testability, or business-logic discussions and influence design decisions too broadly.\n\nMitigation: Treat its recommendations as optional architecture input and review them against the specific codebase before applying changes.\n\nRisk: Functional Core, Imperative Shell may be a poor fit for performance-critical hot paths, framework-heavy lifecycle code, or teams unfamiliar with the pattern.\n\nMitigation: Pilot the pattern on bounded modules, validate framework adapters early, and review tradeoffs before expanding adoption.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core)\n- [ClawHub metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown guidance with architecture checklists and implementation considerations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No code execution, credentials, persistence, or privileged access requested.]\n\n## Skill Version(s):\n\n1.9.19 (source: ClawHub 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, 3882 bytes\n\nFiles: skill-card.md (2389b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.18:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.18:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.18\",\n  \"publishedAt\": 1786829349472\n}\n\nFile v1.9.18:skill-card.md\n\n## Description:\n\nApplies Functional Core, Imperative Shell to isolate logic from side effects.\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 software architects use this skill to decide when and how to isolate pure business logic from I/O and framework code using Functional Core, Imperative Shell. It guides adoption steps, deliverables, and pattern-specific risks for improving testability and managing side effects.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may appear during broad architecture or testability discussions where this pattern is not the right fit.\n\nMitigation: Confirm that business logic is materially entangled with I/O, framework calls, or brittle tests before applying the guidance.\n\nRisk: Teams may duplicate decisions in the imperative shell instead of keeping business logic in the functional core.\n\nMitigation: Use code reviews and architecture tests to enforce that the core owns decisions while the shell handles orchestration and side effects.\n\nRisk: The pattern can be a poor fit for performance-critical hot paths or framework lifecycles that resist a thin shell boundary.\n\nMitigation: Exclude hot paths when immutability overhead matters and validate framework integration with small adapters before broader refactoring.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core)\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]\n\n**Output Format:** [Markdown prose with architecture adoption steps, deliverables, and risk mitigations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No executable code, credential use, persistence, or environment modification is identified in the release security evidence.]\n\n## Skill Version(s):\n\n1.9.18 (source: server release evidence; artifact frontmatter says 1.9.8)\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, 3580 bytes\n\nFiles: skill-card.md (1748b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.17:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.17:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.17\",\n  \"publishedAt\": 1785389338035\n}\n\nFile v1.9.17:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 engineers use this skill to separate pure business logic from I/O-heavy orchestration, improving testability and maintainability when applying the Functional Core, Imperative Shell pattern. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad trigger terms may surface this skill in general architecture or testability discussions where another skill is more specific. <br>\nMitigation: Confirm the user's task involves Functional Core, Imperative Shell or side-effect isolation before applying the guidance. <br>\n\n\n## Reference(s): <br>\n- [Project homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes) <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, markdown] <br>\n**Output Format:** [Markdown guidance with structured architecture recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [None] <br>\n\n## Skill Version(s): <br>\n1.9.17 (source: ClawHub 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.16: 3 files, 3766 bytes\n\nFiles: skill-card.md (2175b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.16:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.16:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.16\",\n  \"publishedAt\": 1784058366054\n}\n\nFile v1.9.16:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 engineering teams use this skill to apply the Functional Core, Imperative Shell pattern when separating business logic from I/O, designing command schemas, and improving testability. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate on common engineering terms when users only need general architecture help. <br>\nMitigation: Review and narrow trigger wording before deployment if tighter activation is required. <br>\nRisk: Teams may move decisions into the imperative shell or duplicate business logic outside the functional core. <br>\nMitigation: Use code review checklists and architecture tests to keep decisions in the core and side effects in the shell. <br>\nRisk: Framework lifecycle constraints can make shell adapters more complex than expected. <br>\nMitigation: Validate adapter designs with small proofs of concept before broad refactoring. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core) <br>\n- [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] <br>\n**Output Format:** [Markdown guidance with architecture steps, deliverables, risks, and mitigations.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include ADR, testing, adapter, and rollout metric recommendations.] <br>\n\n## Skill Version(s): <br>\n1.9.16 (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.9.15: 3 files, 3851 bytes\n\nFiles: skill-card.md (2412b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.15:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.15:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.15\",\n  \"publishedAt\": 1783200014638\n}\n\nFile v1.9.15:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 separate pure business logic from I/O-heavy orchestration, improve testability, and plan incremental adoption of the Functional Core, Imperative Shell pattern. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Business logic can drift between the pure core and imperative shell, weakening the intended architecture boundary. <br>\nMitigation: Use code reviews and architecture tests to enforce that the core owns business decisions while the shell handles orchestration and side effects. <br>\nRisk: The pattern can conflict with framework lifecycle hooks or add unnecessary immutability overhead in unsuitable hot paths. <br>\nMitigation: Pilot small adapters before broad rewrites and avoid applying the pattern to performance-critical paths without measurement. <br>\nRisk: Generated architecture guidance may be incorrect or too broad for a specific production environment. <br>\nMitigation: Review recommendations before implementation and apply the organization's safety, security, and compliance requirements before deployment. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core) <br>\n- [Project homepage from 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 with structured architecture steps, deliverables, risks, and component names] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No API keys, MCP tools, or executable scripts were detected in the artifact.] <br>\n\n## Skill Version(s): <br>\n1.9.15 (source: server evidence release.version) <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, 3750 bytes\n\nFiles: skill-card.md (2103b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.14:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.14:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.14\",\n  \"publishedAt\": 1782841850926\n}\n\nFile v1.9.14:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 separate pure business logic from side-effecting I/O, improve testability, and plan incremental adoption of the Functional Core, Imperative Shell pattern. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad architecture and testability triggers may activate the skill in conversations where Functional Core, Imperative Shell is not the best fit. <br>\nMitigation: Review the guidance for relevance before applying it to a specific codebase or design decision. <br>\nRisk: The pattern can be a poor fit for performance-critical hot paths or codebases that are not ready to adopt functional boundaries. <br>\nMitigation: Use the skill's stated when-not-to-use criteria before planning a migration. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core) <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 with architecture steps, deliverables, risks, and component vocabulary] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only guidance; no code execution, tools, API keys, or data access were identified in the security evidence.] <br>\n\n## Skill Version(s): <br>\n1.9.14 (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.9.13: 3 files, 3691 bytes\n\nFiles: skill-card.md (2034b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.13:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.13:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.13\",\n  \"publishedAt\": 1782576921058\n}\n\nFile v1.9.13:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 engineers use this skill to separate pure business logic from side effects, improve testability with immutable domain models, and plan incremental adoption of a thin imperative shell. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may guide an agent to reorganize business logic, tests, adapters, or shell orchestration in a codebase. <br>\nMitigation: Review proposed refactors, run the relevant test suite, and scan changes before deployment. <br>\nRisk: Functional-core boundaries can drift if business decisions are duplicated in the imperative shell. <br>\nMitigation: Use code review and architecture tests to keep decisions in the pure core and side effects in the shell. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core) <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, code, configuration, guidance] <br>\n**Output Format:** [Markdown guidance with optional code, test, configuration, and shell command suggestions] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Non-executable architecture guidance; proposed refactors should be reviewed before application.] <br>\n\n## Skill Version(s): <br>\n1.9.13 (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.9.12: 3 files, 3690 bytes\n\nFiles: skill-card.md (1958b), SKILL.md (4615b), _meta.json (171b)\n\nFile v1.9.12:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.9.12:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.12\",\n  \"publishedAt\": 1781838519882\n}\n\nFile v1.9.12:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 whether Functional Core, Imperative Shell fits a codebase and to plan refactoring that separates pure business logic from I/O and framework side effects. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may activate during broad architecture or testability discussions where Functional Core, Imperative Shell is not relevant. <br>\nMitigation: Confirm the codebase actually has business logic entangled with I/O or slow brittle tests before applying its recommendations. <br>\nRisk: Refactoring toward immutable functional-core boundaries can add overhead in performance-critical paths. <br>\nMitigation: Avoid applying the pattern to hot paths unless profiling and a small proof of concept show acceptable cost. <br>\n\n\n## Reference(s): <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, Code] <br>\n**Output Format:** [Markdown guidance with optional code examples and refactoring steps] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No tool execution or generated files are required by the skill.] <br>\n\n## Skill Version(s): <br>\n1.9.12 (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.8.6: 3 files, 3747 bytes\n\nFiles: skill-card.md (2103b), SKILL.md (4615b), _meta.json (170b)\n\nFile v1.8.6:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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- ``boundary-validator`` -- guards inputs to the pure core so the core can stay total\n- ``core-test-generator`` -- generates property-based tests against the deterministic core\n- ``shell-adapter-generator`` -- scaffolds the imperative shell that wires the core into I/O\n\nFile v1.8.6:_meta.json\n\n{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.8.6\",\n  \"publishedAt\": 1780867359376\n}\n\nFile v1.8.6:skill-card.md\n\n## Description: <br>\nApplies Functional Core, Imperative Shell to isolate logic from side effects. <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 separate pure business logic from side-effecting shells, improve testability, and plan incremental refactors. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Broad architecture and testability triggers may activate the skill during general design discussions where the Functional Core, Imperative Shell pattern is not the best fit. <br>\nMitigation: Confirm the codebase has side-effect-heavy business logic or slow brittle tests before applying refactoring advice. <br>\nRisk: Architecture guidance could lead to unnecessary rewrites or framework mismatch if applied without local validation. <br>\nMitigation: Use incremental extraction and small proof-of-concept adapters before broad adoption. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-functional-core) <br>\n- [Publisher profile](https://clawhub.ai/user/athola) <br>\n- [Project homepage from metadata](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 steps, review checklists, and example component names] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only; no code execution or external tool access.] <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, 3523 bytes\n\nFiles: skill-card.md (1899b), SKILL.md (4206b), _meta.json (170b)\n\nFile v1.8.5:SKILL.md\n\n---\nname: architecture-paradigm-functional-core\ndescription: |\n  Functional Core, Imperative Shell: isolate deterministic logic from side effects for testability\nversion: 1.9.5\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for the shell that verify correct command interpretation, retry logic, and telemetry.\n- A set of rollout metrics (e.g., deployment lead time, incident rate in the shell layer) to demonstrate the value of the architectural change.\n\n## Risks & Mitigations\n- **Logic Drifting Between Core and Shell**:\n  - **Mitigation**: It's common for business logic to accidentally be duplicated or placed in the shell. Enforce a \"core owns all decisions\" checklist during code reviews to prevent this.\n- **Mismatch with Frameworks**:\n  - **Mitigation**: The imperative shell may still need to interact with framework-specific lifecycle hooks. Before committing to a large rewrite, build small proof-of-concept adapters to validate the integration strategy.\n- **Team Unfamiliarity with the Pattern**:\n  - **Mitigation**: Introduce the pattern using pair programming and internal \"brown-bag\" learning sessions. Document common anti-patterns that are discovered during the pilot phase to guide future development.\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-functional-core\",\n  \"version\": \"1.8.5\",\n  \"publishedAt\": 1778292921804\n}\n\nFile v1.8.5:skill-card.md\n\n## Description: <br>\nFunctional Core, Imperative Shell: isolate deterministic logic from side effects for testability <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 separate deterministic business logic from side effects and plan an incremental Functional Core, Imperative Shell refactor. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Architecture guidance may be applied as broad refactors without validating fit for the target codebase. <br>\nMitigation: Review suggested changes with maintainers, start with a small pilot module, and verify behavior through unit, contract, and integration tests before wider rollout. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/athola/nm-archetypes-architecture-paradigm-functional-core) <br>\n- [OpenClaw 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] <br>\n**Output Format:** [Markdown architecture guidance with adoption steps, deliverables, risks, mitigations, and troubleshooting notes] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Markdown-only guidance; no executable behavior or sensitive access was identified in server security evidence.] <br>\n\n## Skill Version(s): <br>\n1.8.5 (source: server release metadata; artifact frontmatter states 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-functional-core Owner: athola Summary: Applies Functional Core, Imperative Shell to isolate logic from side effects Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:13.365Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:09.472Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:28:58.035Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:06.054Z | user Release v1.9.16 v1.9.1","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: architecture-paradigm-functional-core\ndescription: Applies Functional Core, Imperative Shell to isolate logic from side effects\nversion: 1.9.8\ntriggers:\n  - architecture\n  - functional-core\n  - imperative-shell\n  - testability\n  - business-logic\n  - side-effects\n  - business logic is entangled with I/O or unit tests are slow and brittle\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# The Functional Core, Imperative Shell Paradigm\n\n\n## When To Use\n\n- Separating pure business logic from side effects\n- Improving testability through immutable domain models\n\n## When NOT To Use\n\n- Performance-critical hot paths where immutability overhead matters\n- Purely imperative codebases with no plans to adopt functional patterns\n\n## When to Employ This Paradigm\n- When business logic is entangled with I/O operations (e.g., database calls, HTTP requests), making tests brittle and slow.\n- When significant development time is spent rewriting adapters or dealing with framework churn.\n- When you require a suite of fast, deterministic unit tests that operate on plain data, complemented by a thin integration testing layer.\n\n## Adoption Steps\n1. **Inventory Side Effects**: Create a map of all side effects in the system, such as database writes, external API calls, UI events, and filesystem access. Explicitly assign these responsibilities to the \"shell.\"\n2. **Model the Core Logic**: Represent business rules and policies as pure functions. These functions should take domain data as input and return decisions or commands as output, avoiding shared mutable state.\n3. **Design the Command Schema**: Define a small, explicit set of command objects that the core can return and the shell can interpret (e.g., `PersistOrder`, `PublishEvent`, `NotifyUser`).\n4. **Refactor Incrementally**: Begin with high-churn or critical modules. Wrap legacy imperative code behind adapters while progressively extracting pure calculations into the functional core.\n5. **Enforce Boundaries**: Use code reviews and automated architecture tests to validate a strict separation. The shell should only handle orchestration, sequencing, and retries, while the core should never call directly into frameworks or I/O libraries.\n\n## Key Deliverables\n- An Architecture Decision Record (ADR) detailing why this pattern was chosen, which modules are affected, and the scope of the migration.\n- A suite of unit tests for the core with high (>90%) and deterministic code coverage. Where applicable, use property-based or fixture-based testing to cover a wide range of inputs.\n- A suite of contract and integration tests for"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7d107jg9jv602h9ytsegydq184a42s\",\n  \"slug\": \"nm-archetypes-architecture-paradigm-functional-core\",\n  \"version\": \"1.9.19\",\n  \"publishedAt\": 1787749513365\n}"},{"path":"skill-card.md","content":"## Description:\n\nApplies Functional Core, Imperative Shell to isolate logic from side effects.\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 separate pure business logic from side effects, improving testability and making architecture changes easier to reason about.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may activate during general architecture, testability, or business-logic discussions and influence design decisions too broadly.\n\nMitigation: Treat its recommendations as optional architecture input and review them against the specific codebase before applying changes.\n\nRisk: Functional Core, Imperative Shell may be a poor fit for performance-critical hot paths, framework-heavy lifecycle code, or teams unfamiliar with the pattern.\n\nMitigation: Pilot the pattern on bounded modules, validate framework adapters early, and review tradeoffs before expanding adoption.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/athola/skills/nm-archetypes-architecture-paradigm-functional-core)\n- [ClawHub metadata homepage](https://github.com/athola/claude-night-market/tree/master/plugins/archetypes)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown guidance with architecture checklists and implementation considerations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [No code execution, credentials, persistence, or privileged access requested.]\n\n## Skill Version(s):\n\n1.9.19 (source: ClawHub 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 Functional Core, Imperative Shell to isolate logic from side effects Skill: architecture-paradigm-functional-core Owner: athola Summary: Applies Functional Core, Imperative Shell to isolate logic from side effects Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:05:13.365Z | user Release v1.9.19 v1.9.18 | 2026-08-15T21:29:09.472Z | user Release v1.9.18 v1.9.17 | 2026-07-30T05:28:58.035Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:46:06.054Z | user Release v1.9.16 v1.9.1","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1077,"uniquenessScore":54,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-10T02:09:59.688Z","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-10T02:09:59.688Z","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:53:22.764Z","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"}]}}}