stack-patterns_skill

This skill helps you learn and apply Outfitter stack patterns across handlers, results, errors, and package conventions for safer, reusable code.
  • TypeScript

25

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill outfitter-dev/agents --skill stack-patterns

  • SKILL.md8.9 KB

Overview

This skill is a concise reference for the Outfitter stack patterns, covering the Handler contract, Result types, error taxonomy, and @outfitter/* package conventions. It helps engineers adopt consistent, testable handlers and map domain errors to exit/HTTP codes. Use it to standardize CLI, MCP, daemon, and library behavior across projects.

How this skill works

It documents the canonical Handler signature: a pure function receiving typed input and a HandlerContext and returning Result<T, E>. It explains use of better-result for explicit results, Zod-based validation helpers, and a ten-category error taxonomy that maps to exit and HTTP status codes. It also lists package responsibilities and Bun-first API recommendations to guide implementation choices.

When to use it

  • When writing or testing handlers that must be transport-agnostic
  • When mapping domain errors to exit codes and HTTP statuses
  • When validating inputs with Zod and creating typed Results
  • When choosing which @outfitter/* packages to add to a project
  • When designing CLI output, MCP tools, or background daemons

Best practices

  • Always start new projects with @outfitter/contracts for types, Result utilities, and error classes
  • Keep handlers pure and transport-agnostic so they are reusable across CLI, HTTP, and MCP
  • Use createValidator with Zod to return typed Result values instead of throwing
  • Map domain errors to the 10-category taxonomy to ensure consistent exit and HTTP codes
  • Use HandlerContext for cross-cutting concerns: structured logger, requestId, signal, config, and workspace/cwd
  • Prefer Bun-native APIs where available for performance and consistency

Example use cases

  • Implementing a getUser handler that returns Result.ok(user) or Result.err(NotFoundError) and is called from CLI, MCP, and HTTP layers
  • Validating raw CLI input with a Zod schema and returning ValidationError via Result.err
  • Mapping database uniqueness conflicts to ConflictError so the CLI returns exit code 3 and HTTP 409
  • Building an MCP tool using @outfitter/mcp with registered Zod schemas and handlers
  • Writing a daemon with @outfitter/daemon that uses the HandlerContext signal for graceful shutdown

FAQ

Result makes control flow explicit, preserves strong TypeScript types for success and error branches, and simplifies testing and composition.

When should I use @outfitter/cli vs @outfitter/mcp?

Use @outfitter/cli for command-line apps and formatted output/UI components. Use @outfitter/mcp when registering tools with the MCP server or building tool schemas for AI agent interaction.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational