agentleFS
andr-caandr-ca/agentharness/.claude/skills/clean-architecture/SKILL.md

clean-architecture

Skill1 starsChanged 2 months agoMITView on GitHub

Use when business logic is entangled with frameworks or databases. Covers hexagonal architecture (ports and adapters), layer diagram, dependency direction rules, and violation symptoms.

We split this skill into the rules it gives an agent

1 rule. 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 23 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use cases / handlers: orchestrate domain objects

    line 46

“Common” is measured: kept by at least 6 in 10 of the 23 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Clean Architecture (Hexagonal / Ports & Adapters)

Core rule: business logic must not depend on infrastructure. Infrastructure depends on business logic.

     ┌─────────────────────────────────────────┐
     │           Infrastructure                │
     │  (HTTP, DB, Queue, Email, S3, ...)      │
     │                                         │
     │     ┌───────────────────────────┐       │
     │     │     Application Layer     │       │
     │     │  (Use cases, Commands)    │       │
     │     │                           │       │
     │     │   ┌─────────────────┐    │       │
     │     │   │  Domain Layer   │    │       │
     │     │   │  (Entities,     │    │       │
     │     │   │  Value Objects, │    │       │
     │     │   │  Domain Events) │    │       │
     │     │   └─────────────────┘    │       │
     │     └───────────────────────────┘       │
     └─────────────────────────────────────────┘
         Dependencies only point INWARD →

Layers

Domain (innermost)

  • Entities: objects with identity and lifecycle (Order, User)
  • Value Objects: immutable, defined by value (Money, Email)
  • Domain Events: things that happened (OrderPlaced, PaymentFailed)
  • Domain Services: stateless logic that spans entities
  • Zero infrastructure imports — no SQLAlchemy, FastAPI, Stripe, etc.

Application

  • Use cases / handlers: orchestrate domain objects
  • Input/output ports (interfaces): what the use case needs from outside
  • No infrastructure imports — depends only on domain + port interfaces

Infrastructure (outermost)

  • Adapters that implement ports: SqlUserRepository, StripePaymentGateway
  • Framework glue: FastAPI routes, Django views, Express controllers
  • Depends on application layer — adapters implement domain/application interfaces

Ports & Adapters

A port is an interface defined in the domain/application layer. An adapter is an infrastructure class that implements a port.

# Port (in application/domain layer)
class UserRepository(Protocol):
    def find_by_id(self, id: UserId) -> User | None: ...
    def save(self, user: User) -> None: ...

# Adapter (in infrastructure layer)
class SqlUserRepository:
    def __init__(self, session: Session) -> None:
        self._session = session

    def find_by_id(self, id: UserId) -> User | None:
        return self._session.get(UserModel, id.value)

    def save(self, user: User) -> None:
        self._session.merge(UserModel.from_domain(user))

Directory Layout

src/
  domain/
    order.py            # Order entity
    order_repository.py # port (Protocol)
    events.py           # OrderPlaced, OrderCancelled
  application/
    place_order.py      # PlaceOrderUseCase
    cancel_order.py     # CancelOrderUseCase
  infrastructure/
    sql_order_repository.py  # implements port
    stripe_payment.py        # implements PaymentGateway port
  interfaces/
    http/
      order_routes.py   # FastAPI/Express routes
    cli/
      commands.py       # CLI entry points

Dependency Direction Rules

  1. Imports only point inward: infrastructure → application → domain
  2. Domain never imports from infrastructure or application
  3. Use cases depend on ports (interfaces), never on adapters (concretions)
  4. Test domain/application layers without infrastructure — use fakes for ports

When You're Violating This

SymptomFix
from sqlalchemy import ... in a domain entityMove persistence to an adapter; domain holds plain objects
Can't unit-test a use case without a databaseThe use case depends on a concrete repository; inject a port instead
HTTP status codes or request objects in business logicBusiness logic returns domain results; the controller translates to HTTP
Feature requires changing 5 different layersLayers may be too granular; check if use case logic leaked into infrastructure

See Also

  • patterns/clean-architecture/README.md — pattern directory entry
  • .claude/skills/design-patterns/SKILL.md — Repository, Facade, Strategy used in clean arch
  • .claude/skills/dependency-injection/SKILL.md — how DI wires the layers together

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.