adapter

Translate domain requests and responses to external system wire formats.

4|1|Updated Apr 12, 2026

Search Tags:#context handling #retry policy #service interface #error mapping #outbound integration #wire format translation

Ready to run

npx skills add https://github.com/reliant-labs/forge --skill adapter

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: adapter
Source: https://github.com/reliant-labs/forge/tree/main/internal/templates/project/skills/forge/adapter
Command: npx skills add https://github.com/reliant-labs/forge --skill adapter

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Adapter skills eliminate tightly-coupled vendor code in your domain by isolating outbound integrations behind a narrow, vendor-neutral interface.

Core Features & Use Cases

Outbound boundary translation: Converts your domain types to the external system’s wire format, including authentication, timeouts, retry policy, and response mapping.
Vendor-to-domain error mapping: Translates downstream/vendor failures into domain errors that your callers can handle consistently.
Leaf-node integration design: Keeps the adapter focused on translation logic while multi-step workflows live in interactors/services.

Quick Start

Scaffold a new outbound integration package named stripe-adapter by running a forge command that generates the canonical Service/Deps/New(Deps) shape and contract marker for you.

Frequently Asked Questions about adapter

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I isolate third-party API vendor code from my business logic?▼

To isolate third-party API vendor code, use an adapter pattern that translates domain requests to external wire formats while keeping business logic vendor-neutral. This confines vendor-specific code to a leaf-node package behind a narrow service interface.

How do I map external HTTP API errors to domain errors consistently?▼

Mapping external HTTP API errors to domain errors requires an outbound integration layer that translates downstream vendor failures into domain-specific errors. This ensures callers handle failures consistently without knowing the underlying vendor response structure.

What is the best way to structure an outbound integration for a message broker?▼

The best way to structure an outbound integration for a message broker is using an adapter package with a narrow service interface, context-first method signatures, and vendor-to-domain mapping to keep translation logic isolated from business workflows.

Do I need an adapter package to handle OAuth provider integrations?▼

You need an adapter package to handle OAuth provider integrations when implementing them as leaf-node services. The adapter manages authentication, timeouts, and wire format translation, allowing your domain-oriented caller to depend on a vendor-neutral interface.

How do I implement timeouts and retry policies for external storage backends?▼

Implementing timeouts and retry policies for external storage backends is handled within the adapter layer. The adapter package structure requires context-first method signatures to manage these outbound integration concerns safely without affecting domain logic.

When should I not use an adapter pattern for outbound integration?▼

You should not use an adapter pattern alone when your outbound integration requires multi-step workflows or complex business decisions. Adapters should remain focused on translation logic, while interactors or services handle the broader workflow orchestration.