stack-architecture

📁 outfitter-dev/agents 📅 Jan 29, 2026
1
总安装量
1
周安装量
#43249
全站排名
安装命令
npx skills add https://github.com/outfitter-dev/agents --skill stack-architecture

Agent 安装分布

github-copilot 1

Skill 文档

Stack Architecture Design

Design transport-agnostic handler systems with proper Result types and error taxonomy.

Process

Step 1: Understand Requirements

Gather information about:

  • Transport surfaces — CLI, MCP, HTTP, or all?
  • Domain operations — What actions does the system perform?
  • Failure modes — What can go wrong? (maps to error taxonomy)
  • External dependencies — APIs, databases, file system?

Step 2: Design Handler Layer

For each domain operation:

  1. Define input type (Zod schema)
  2. Define output type
  3. Identify possible error types (from taxonomy)
  4. Write handler signature: Handler<Input, Output, Error1 | Error2>

Example:

// Input schema
const CreateUserInputSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1),
});

// Output type
interface User {
  id: string;
  email: string;
  name: string;
}

// Handler signature
const createUser: Handler<unknown, User, ValidationError | ConflictError>;

Step 3: Map Errors to Taxonomy

Map domain errors to the 10 categories:

Domain Error Stack Category Error Class
Not found not_found NotFoundError
Invalid input validation ValidationError
Already exists conflict ConflictError
No permission permission PermissionError
Auth required auth AuthError
Timed out timeout TimeoutError
Connection failed network NetworkError
Limit exceeded rate_limit RateLimitError
Bug/unexpected internal InternalError
User cancelled cancelled CancelledError

Step 4: Choose Packages

Packages are organized into three tiers:

Package Tiers

┌─────────────────────────────────────────────────────────────────┐
│                        TOOLING TIER                              │
│  Build-time, dev-time, test-time packages                       │
│  @outfitter/testing                                             │
└─────────────────────────────────────────────────────────────────┘
                              ▲
                              │ depends on
┌─────────────────────────────────────────────────────────────────┐
│                        RUNTIME TIER                              │
│  Application-specific packages for different deployment targets  │
│  @outfitter/cli    @outfitter/mcp    @outfitter/daemon          │
│  @outfitter/config @outfitter/logging @outfitter/file-ops       │
│  @outfitter/state                                               │
└─────────────────────────────────────────────────────────────────┘
                              ▲
                              │ depends on
┌─────────────────────────────────────────────────────────────────┐
│                       FOUNDATION TIER                            │
│  Zero-runtime-dependency core packages                          │
│  @outfitter/contracts    @outfitter/types                       │
└─────────────────────────────────────────────────────────────────┘
Tier Packages Dependency Rule
Foundation contracts, types No @outfitter/* deps
Runtime cli, mcp, daemon, config, logging, file-ops, state May depend on Foundation
Tooling testing May depend on Foundation + Runtime

Package Selection

Package Purpose When to Use
@outfitter/contracts Result types, errors, Handler contract Always (foundation)
@outfitter/types Type utilities, collection helpers Type manipulation
@outfitter/cli CLI commands, output modes, formatting CLI applications
@outfitter/mcp MCP server, tool registration AI agent tools
@outfitter/config XDG paths, config loading Configuration needed
@outfitter/logging Structured logging, redaction Logging needed
@outfitter/daemon Background services, IPC Long-running services
@outfitter/file-ops Secure paths, atomic writes, locking File operations
@outfitter/state Pagination, cursor state Paginated data
@outfitter/testing Test harnesses, fixtures Testing

Selection criteria:

  • All projects need @outfitter/contracts (foundation)
  • CLI applications add @outfitter/cli (includes UI components)
  • MCP servers add @outfitter/mcp
  • File operations need both @outfitter/config (paths) and @outfitter/file-ops (safety)

Step 5: Design Context Flow

Determine:

  • Entry points — Where is context created? (CLI main, MCP server, HTTP handler)
  • Context contents — Logger, config, signal, workspaceRoot
  • Tracing — How requestId flows through operations

Output Templates

Architecture Overview

Project: {PROJECT_NAME}
Transport Surfaces: {CLI | MCP | HTTP | ...}

Directory Structure:
├── src/
│   ├── handlers/           # Transport-agnostic business logic
│   │   ├── {handler-1}.ts
│   │   └── {handler-2}.ts
│   ├── commands/           # CLI adapter (if CLI)
│   ├── tools/              # MCP adapter (if MCP)
│   └── index.ts            # Entry point
└── tests/
    └── handlers/           # Handler tests

Dependencies:
├── @outfitter/contracts    # Foundation (always)
├── @outfitter/{package-2}  # {reason}
└── @outfitter/{package-3}  # {reason}

Handler Inventory

Handler Input Output Errors Description
getUser GetUserInput User NotFoundError Fetch user by ID
createUser CreateUserInput User ValidationError, ConflictError Create new user
deleteUser DeleteUserInput void NotFoundError, PermissionError Remove user

Error Strategy

Domain Errors → Stack Taxonomy:

{domain-error-1} → {stack-category} ({ErrorClass})
  - When: {condition}
  - Exit code: {code}

{domain-error-2} → {stack-category} ({ErrorClass})
  - When: {condition}
  - Exit code: {code}

Implementation Order

  1. Foundation — Install packages, create types
  2. Core handlers — Implement business logic with tests
  3. Transport adapters — Wire up CLI/MCP/HTTP
  4. Testing — Integration tests across transports

Constraints

Always:

  • Recommend Result types over exceptions
  • Map domain errors to taxonomy categories
  • Design handlers as pure functions (input, context) → Result
  • Consider all transport surfaces upfront
  • Include error types in handler signatures

Never:

  • Suggest throwing exceptions
  • Design transport-specific logic in handlers
  • Recommend hardcoded paths
  • Skip error type planning
  • Couple handlers to specific transports

Related Skills

  • outfitter-stack:stack-patterns — Reference for all patterns
  • outfitter:tdd — TDD implementation methodology
  • outfitter-stack:stack-templates — Templates for components