Developer

Purpose

Orchestrates the development workflow by understanding the domain context, mapping changes to the correct architecture layer, and implementing with consistent patterns. Uses discovered project conventions from /developer configure.

When to Use

• •Implementing new features or functionality
• •Making code changes that span multiple areas
• •Understanding where to place new code
• •Ensuring changes follow project conventions

Quick Reference

• •Setup: /developer configure (run once during framework setup)
• •Usage: /developer or /dev (uses saved config)
• •Update: /developer learn <path> (analyze specific path)

Config Location

Config path depends on how the plugin was installed:

Precedence when reading (first found wins):

1. •.claude/skills/developer.local.yaml
2. •.claude/skills/developer.yaml
3. •Skill defaults

Modes

Configure Mode

Auto-detect project architecture and patterns:

/developer configure

Discovers:

• •Architecture style (layered, modular, flat, monorepo)
• •Layer boundaries and naming conventions
• •Import rules and dependency direction
• •Domain concepts and vocabulary
• •Test file patterns and locations

Outputs: .claude/skills/developer.yaml

# Developer configuration
# Generated by: /developer configure

architecture:
  style: layered  # layered, modular, flat, monorepo
  layers:
    - name: domain
      path: src/domain
      description: "Core business logic"
    - name: infrastructure
      path: src/infrastructure
      description: "External integrations"
    - name: application
      path: src/application
      description: "Services and orchestration"

import_rules:
  - from: domain
    allowed: []  # domain has no dependencies
  - from: infrastructure
    allowed: [domain]
  - from: application
    allowed: [domain, infrastructure]

domain_concepts:
  - term: user
    meaning: "Account holder in the system"
    location: src/domain/user
  - term: order
    meaning: "Purchase transaction"
    location: src/domain/order

patterns:
  naming:
    files: kebab-case  # my-service.ts
    functions: camelCase
    classes: PascalCase
  test_location: adjacent  # adjacent, __tests__, tests/
  test_suffix: .test  # .test.ts, .spec.ts, _test.go

Learn Mode

Analyze specific path and update configuration:

/developer learn src/services/

Updates .claude/skills/developer.yaml with patterns found in the specified path.

Default Mode

Orchestrate development using saved configuration:

/developer

Requires: .claude/skills/developer.yaml exists (run configure first)

Workflow

1. •Understand Request - Map user request to domain concepts
2. •Locate Code - Find relevant files using architecture config
3. •Plan Changes - Determine affected layers and approach
4. •Implement - Follow project patterns and conventions
5. •Validate - Run tests and checks

Pre-Commit Validation

CRITICAL: Before committing any code changes, run validation:

1. IDE Diagnostics (if available)

Check for errors in modified files using IDE MCP:

mcp__ide__getDiagnostics({ uri: "<file-path>" })

2. Framework Pre-Commit

task -t .claude/Taskfile.yaml precommit

This runs configured linting and tests. Do NOT commit if any step fails.

Architecture Patterns

The skill adapts to your project's architecture style:

Layered Architecture

src/
├── domain/        # Business logic (no external deps)
├── infrastructure/ # External integrations
└── application/   # Services, handlers

Rule: Dependencies flow inward (application → infrastructure → domain)

Modular Architecture

src/
├── users/         # User module (self-contained)
├── orders/        # Order module (self-contained)
└── shared/        # Shared utilities

Rule: Modules communicate via defined interfaces

Flat Architecture

src/
├── models/
├── services/
├── utils/
└── handlers/

Rule: Services depend on models, handlers depend on services

Implementation Strategy

Based on discovered architecture:

1. •Single-layer change: Direct implementation
2. •Multi-layer change: Implement bottom-up (domain → infrastructure → application)
3. •New module: Follow existing module patterns
4. •Cross-cutting: Identify shared concerns, avoid duplication

Example Usage

User: "Add email notifications when orders are placed"

/developer workflow:
1. Domain concepts: order, notification
2. Locate: src/domain/order, src/infrastructure/email
3. Plan:
   - Add notification trigger in order domain
   - Create email service in infrastructure
   - Wire up in application layer
4. Implement bottom-up
5. Validate with tests

Automation

See skill.yaml for discovery procedures. See sharp-edges.yaml for common architecture mistakes. See collaboration.yaml for skill composition patterns.