adapter-scaffold

Name: adapter-scaffold
Availability: InStock
Author: Vel-Labs

Create and validate ClearIntent adapters with typed success, degraded, and failure states.

Updated Apr 26, 2026

Search Tags:#integration #scaffolding #governance #interface #adapter #clearintent #vendor-boundary

Ready to run

npx skills add https://github.com/Vel-Labs/ClearIntent --skill adapter-scaffold-vel-labs

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: adapter-scaffold
Source: https://github.com/Vel-Labs/ClearIntent/tree/main/skills/adapter-scaffold
Command: npx skills add https://github.com/Vel-Labs/ClearIntent --skill adapter-scaffold-vel-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Adapter scaffolding isolates vendor behavior while preserving the shared ClearIntent authority contract.

Core Features & Use Cases

Define narrow adapter interfaces before implementation.
Consume contract/core types and results; do not redefine intent, policy, risk, receipt, or audit shapes locally.
Return typed success, failure, and degraded states.
Keep vendor SDK quirks behind the adapter boundary.
Update provider docs, roadmap/current-state, decisions, changelog, and hackathon eligibility notes when claims change.

Quick Start

Review the existing adapter design and scaffold a new adapter using the outlined interface guidelines.

Frequently Asked Questions about adapter-scaffold

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

FAQPage Schema

How do I isolate vendor SDK quirks when building ClearIntent integrations?▼

You isolate vendor SDK quirks by defining a narrow adapter interface that masks vendor behavior behind a strict boundary. This preserves the shared ClearIntent authority contract while preventing vendor-specific logic from leaking into core workflows.

What typed states should an integration adapter return for governance workflows?▼

Integration adapters should return typed success, degraded, and failure states. Returning these specific result states ensures governance workflows can accurately track authority contracts and handle vendor boundary exceptions consistently.

Can I redefine intent, policy, or audit shapes inside a local adapter implementation?▼

No, you cannot redefine intent, policy, risk, receipt, or audit shapes locally. Adapters must consume shared contract and core types directly to maintain alignment with the ClearIntent authority contract across all integration boundaries.

Does adapter scaffolding support signer hardware and ENS integration workflows?▼

Yes, adapter scaffolding supports signer hardware and ENS integration workflows. It automates adapter creation and validation across design, implementation, and review phases for these specific vendor boundaries within ClearIntent environments.

When should I update provider docs and changelog for an integration adapter?▼

You should update provider docs, roadmap, decisions, and changelog whenever claims about the adapter change. Keeping these documents current ensures the vendor boundary remains transparent and the integration state is accurately tracked.

Why define a narrow adapter interface before implementing vendor integrations?▼

Defining a narrow adapter interface before implementation isolates vendor behavior while preserving the shared ClearIntent authority contract. This practice prevents vendor SDK quirks from contaminating core types and ensures consistent typed result states.