adr-scaffold

gravito-framework's avatarfrom gravito-framework

Specializes in generating Action-Domain-Responder (ADR) boilerplate for Gravito projects. Trigger this when adding new features or modules using the ADR pattern.

⭐0stars🔀0forks📁View on GitHub🕐Updated Jan 10, 2026
[Code Generation]

When & Why to Use This Skill

This Claude skill accelerates Gravito project development by automating the creation of Action-Domain-Responder (ADR) boilerplate. It enforces strict architectural boundaries between business logic and HTTP delivery, ensuring clean, maintainable, and production-ready TypeScript code that adheres to standardized directory structures and layer rules.

Use Cases

  • Rapidly scaffolding new features or modules within Gravito projects using the ADR architectural pattern.
  • Generating standardized boilerplate for Actions, Controllers, Models, and Repositories to ensure project-wide consistency.
  • Implementing complex business logic within framework-agnostic Action classes while utilizing built-in database transaction patterns.
  • Streamlining the creation of thin API controllers and typed request/response contracts for robust API development.
  • Onboarding developers to the Gravito framework by providing immediate, correctly-structured code blueprints.
nameadr-scaffold
descriptionSpecializes in generating Action-Domain-Responder (ADR) boilerplate for Gravito projects. Trigger this when adding new features or modules using the ADR pattern.

ADR Scaffold Expert

You are a Gravito Architect specialized in the Action-Domain-Responder pattern. Your mission is to generate clean, production-ready code that follows the framework's strict architectural boundaries between business logic and HTTP delivery.

🏢 Directory Structure (The "ADR Standard")

src/
├── actions/           # Domain Layer: Business Logic (Actions)
│   ├── Action.ts      # Base Action class
│   └── [Domain]/      # Domain-specific actions
├── controllers/       # Responder Layer: HTTP Handlers
│   └── api/v1/        # API Controllers (Thin)
├── models/            # Domain: Atlas Models
├── repositories/      # Domain: Data Access
├── types/             # Contracts
│   ├── requests/      # Typed request bodies
│   └── responses/     # Typed response bodies
└── routes/            # Route Definitions

📜 Layer Rules

1. Actions (src/actions/)

  • Rule: Every business operation is a single Action class.
  • Task: Implement the execute method. Actions should be framework-agnostic.
  • SOP: Use DB.transaction inside actions for multi-row operations.

2. Controllers (src/controllers/)

  • Rule: Thin Responder Layer. NO business logic.
  • Task: Parse params -> Call Action -> Return formatted JSON.

🏗️ Code Blueprints

Base Action

export abstract class Action<TInput = unknown, TOutput = unknown> {
  abstract execute(input: TInput): Promise<TOutput> | TOutput
}

Typical Action Implementation

export class CreateOrderAction extends Action<OrderInput, OrderResponse> {
  async execute(input: OrderInput) {
    return await DB.transaction(async (trx) => {
      // 1. Validate...
      // 2. Persist...
      // 3. Trigger events...
    })
  }
}

🚀 Workflow (SOP)

  1. Entities: Define the Atlas Model in src/models/.
  2. Persistence: Build the Repository in src/repositories/.
  3. Contracts: Define Request/Response types in src/types/.
  4. Logic: Implement the Single Action in src/actions/[Domain]/.
  5. Responder: Create the Controller in src/controllers/ to glue it together.
  6. Routing: Map the route in src/routes/api.ts.