meaningfy-architecture

Reviews code for quality, security, architecture conformance, and test coverage before a PR. Use proactively after implementation, before opening a PR. Read-only — does not modify code. Thin wrapper — the review criteria live in the meaningfy-code-review skill.

Shapes an EPIC from human seeds and derives its clarity-gated PLAN, driving the OpenSpec /opsx build-tier flow. The EPIC is the OpenSpec proposal.md (Shape-Up work shape); the PLAN is design.md + tasks.md, scored by the clarity gate (≥9/10). Use when starting or refining an epic. Asks many questions, makes no assumptions. Thin wrapper — the procedure lives in the epic-planning skill; the living-spec lifecycle lives in spec-stewardship.

Implements an EPIC task as production code following the documentation-first loop. Use when an EPIC task is ready (EPIC.md exists, clarity gate passed, Gherkin written). Thin wrapper — all engineering knowledge lives in the loaded skills.

System-level solution architecture — C4 levels (Context, Container, Component, Code), ArchiMate and UML notations, ADRs, and contracts (OpenAPI/AsyncAPI/LinkML). Use for system and solution design, architecture documentation, and architectural decision-making. Distinct from code structure inside a service (see the cosmic-python skill).

Write BDD Gherkin feature files and fabricate test data from a specification. Use to project a use case catalogue (Cockburn White/Blue) or turn acceptance criteria or an EPIC into business-language `.feature` scenarios — Scenario Outline with Examples, explicit edge cases, no implementation detail, traced back to use cases. Trigger on "write Gherkin", "write feature files", "BDD scenarios for this acceptance criterion", "derive scenarios from use cases", "fabricate test data".

Standardise the application-repo Continuous Delivery side of Meaningfy systems — the deploy trigger, the reusable deploy mechanism, and the release/image standard. Use to set up a CD/deploy workflow, release and push a versioned Docker image to a registry (recommended GHCR, tagged by semver + git sha), standardise or migrate the deploy trigger, kill the duplicated SSH/bastion/rsync/.env deploy block by consuming the canonical reusable workflow, or understand the three-repo deploy model. CI (build, test, lint, coverage, architecture, docs publish) is NOT here — that is owned by project-setup; this skill owns only CD + release + the delivery contract. Trigger on "set up CD / deploy workflow", "release and push a versioned image", "GHCR image build", "standardise the deploy trigger", "migrate the duplicated deploy block", "how do we deploy this repo".

Pre-ingestion quality gate for specifications and documents before they drive implementation. Use to score a spec/EPIC against a 13-item checklist (6-criterion rubric, must reach ≥9/10), surfacing hidden assumptions and ungrounded claims. Trigger on "score this spec", "is this spec ready", "run the clarity gate", "check this EPIC before implementation". A lightweight variant applies to routine docs.

Build and evolve a living, representation-agnostic conceptual model for a product (programming) project — the domain's entities, attributes, relationships, and meaning — and choose how it is rendered. Use to model the domain, do conceptual data modelling in UML, run ontology-engineering at the concept level (stable-IRI policy, vocabulary reuse), decide the model *source* (LinkML directly vs model2owl-first), set up a conceptual model, or run terminology/definitions/glossary management. Trigger on "model the domain", "conceptual/UML data model", "set up conceptual model", "which model source", "ontology/terminology management", "ubiquitous language glossary". For the LinkML craft itself (authoring, generation, gates) see linkml-engineering; for generic modelling conventions see modelling-conventions. Conditional: applies to product-development repos that build software; a doc-only/non-product repo does not need it.