.cursor/skills/hexagonal-architecture/SKILL.md
Describes the hexagonal architecture (ports and adapters) used across the Packmind monorepo. This skill should be used when creating new domain packages, use cases, services, repositories, or any architectural component to follow established patterns.
npx skillsauth add PackmindHub/packmind hexagonal-architectureInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Every domain package follows a three-layer hexagonal (ports & adapters) architecture. Dependencies flow inward only: Infrastructure -> Application -> Domain.
packages/{domain}/src/
├── domain/ # Pure business logic, zero dependencies
│ ├── entities/ # Domain entities and value objects
│ ├── repositories/ # Repository interfaces (ports)
│ ├── jobs/ # Delayed job definitions
│ ├── errors/ # Domain-specific error classes
│ ├── utils/ # Domain-specific utility functions
│ └── types/ # Domain-specific type definitions
│
├── application/ # Orchestration & coordination
│ ├── useCases/{name}/ # One folder per use case
│ │ └── {name}.usecase.ts
│ ├── services/ # Domain services + service aggregator
│ ├── adapter/ # Outbound adapter (implements port)
│ ├── listeners/ # Domain event listeners
│ └── jobs/ # Delayed job implementations
│
├── infra/ # Concrete implementations
│ ├── repositories/ # Repository implementations (TypeORM)
│ ├── schemas/ # TypeORM EntitySchema definitions
│ └── jobs/ # Job factories
│
└── index.ts # Package exports + {Domain}Hexa facade
| Layer | Depends On | Purpose | Details |
|-------|-----------|---------|---------|
| Domain | Nothing (pure TS + @packmind/types) | Business rules, entity definitions, port interfaces | domain-layer.md |
| Application | Domain | Use case orchestration, services, adapters, events | application-layer.md |
| Infrastructure | Domain + Application | Persistence, schemas, job queues | infrastructure-layer.md |
Each component type has its own detailed guide with templates and examples:
| Component | Layer | File Pattern | Guide |
|-----------|-------|-------------|-------|
| Use Case | Application | application/useCases/{name}/{name}.usecase.ts | usecase.md |
| Service | Application | application/services/{Name}Service.ts | service.md |
| Adapter | Application | application/adapter/{Domain}Adapter.ts | adapter.md |
| Port | Types package | packages/types/src/{domain}/ports/I{Domain}Port.ts | port.md |
| Contract | Types package | packages/types/src/{domain}/contracts/{UseCaseName}.ts | contract.md |
| Repository (interface) | Domain | domain/repositories/I{Entity}Repository.ts | repository.md |
| Repository (impl) | Infrastructure | infra/repositories/{Entity}Repository.ts | repository.md |
| Schema | Infrastructure | infra/schemas/{Entity}Schema.ts | schema.md |
| Listener | Application | application/listeners/{Domain}Listener.ts | listener.md |
| Event | Types package | packages/types/src/events/{EventName}.ts | event.md |
| Hexa Facade | Root | {Domain}Hexa.ts + index.ts | hexa-facade.md |
API (NestJS controllers)
│
▼
┌─────────────┐
│ HexaRegistry │ ── Central DI container
└──────┬──────┘
│ getAdapter<IXxxPort>(portName)
▼
┌─────────────┐
│ {Domain}Hexa │ ── Facade: wires repos, services, adapter
└──────┬──────┘
│
┌────┴────┐
▼ ▼
Adapter Services ── Application layer
│ │
▼ ▼
Use Cases ──► Domain entities + Repository interfaces
│
▼
Infra Repositories ── Concrete persistence (TypeORM)
Domains talk to each other through two mechanisms:
Synchronous - Via ports injected through the HexaRegistry during initialize().
Example: StandardsAdapter calls IGitPort.commitToGit().
Asynchronous - Via domain events emitted through PackmindEventEmitterService.
Example: StandardCreatedEvent triggers DeploymentsListener.handleStandardCreated().
See event.md and adapter.md for patterns.
@packmind/node-utils)| Class | Purpose |
|-------|---------|
| BaseHexa<TOpts, TPort> | Hexagon lifecycle (construct -> initialize -> destroy) |
| HexaRegistry | Central dependency injection container |
| AbstractMemberUseCase<C, R> | Use case with org member authorization |
| AbstractSpaceMemberUseCase<C, R> | Use case with org + space member authorization |
| AbstractAdminUseCase<C, R> | Use case with admin authorization |
| AbstractRepository<T> | Base TypeORM repository with soft delete support |
| PackmindListener<TAdapter> | Event subscription base class |
| PackmindEventEmitterService | Event bus for domain events |
tools
Record polished UI demo videos and screenshots of a running web app using Playwright MCP — for client deliverables, release notes, feature walkthroughs, or bug repros. Produces an HD WebM video with chapter markers, a mandatory animated cursor overlay, and a mandatory subtitle bar that narrates each step (positioned deliberately so it never masks the UI being demonstrated), plus full-page screenshots at each step. Use this whenever the user asks to "record a demo", "create a screencast", "make a UI walkthrough video", "document this feature with video", "show the client how X works", "capture screenshots of the app", or anything similar — even when the user only says "make a video" or "take screenshots" in the context of a running frontend. Also use it when the user wants to demonstrate a workflow, generate marketing-quality footage of an app, or produce repeatable visual documentation.
tools
The canonical recipe for starting, checking, and stopping the Packmind local dev stack with Docker Compose — the single source of truth other skills and the Michel agent defer to. Covers bringing the full stack (PostgreSQL, Redis, NestJS API, React/Vite frontend on :4200, MCP server, nginx) up in the background, the init services (dependency install + TypeORM migrations) you must wait on, the critical host-port trap that the API on container port 3000 is NOT exposed to the host and must be reached via the frontend Vite proxy at localhost:4200/api/v0, confirming the API and frontend are actually serving before you depend on them, the persistent-volume gotcha that leaves stale Postgres schema and node_modules behind between runs, building the CLI, and tearing everything down so no container is left blocking the run. Use this whenever you need Packmind running locally — to verify a change, record a UI or CLI demo, hit the API, seed data, or reproduce a bug — and whenever you are about to start or stop `docker compose`. If you are an autonomous agent (e.g. Michel) that started the stack, you MUST use the teardown half before finishing. Prefer this over running `nx serve` on the host for anything that needs the real, containerized stack.
tools
Best practices for creating GitHub pull requests that include inline images — CLI terminal screenshots (from cli-demo-recorder), UI screenshots/videos (from ui-demo-recorder), or any other visual artifact. Use this skill whenever opening or updating a PR that has visual artifacts to embed, or when images aren't rendering in a PR description. Also use it when asked "how do I add screenshots to a PR", "why isn't my image showing", or "embed a demo in the PR".
tools
--- name: michel-create-packmind-dataset description: Seed a local Packmind instance with a realistic dataset — one organization populated with standards, commands, and skills — so an autonomous agent can exercise its own changes against lifelike data instead of an empty app. Use this whenever you need populated Packmind data to verify a change end-to-end: reproducing a bug that only shows with existing artifacts, recording a UI/CLI demo that needs content on screen, smoke-testing a new endpoint