Capability Packs

A capability pack describes what your product supports. It is the internal reference the Integration Fit Gap Analyzer compares target systems against. Without a capability pack, the fit-gap has nothing to say you support.

Capability packs live in capability-packs/ at the repo root. Solutioneer ships one pack out of the box: solutioneer-core.yaml.

The format

The pack is a YAML file with a small fixed shape:

id: solutioneer-core
product: Solutioneer
authMethods:
  - oauth2
  - api_key
objects:
  - account
  - event
  - document
events:
  - webhooks
  - status_update
constraints:
  - writeback requires explicit destination config
  - unsupported claims must stay unknown
knownPatterns:
  - docs-first fit-gap analysis
  - artifact-driven poc handoff

Fields:

• id — a stable identifier used by the fit-gap’s notes.capabilityPackId.
• product — a human-readable product name.
• authMethods — the auth mechanisms your product supports.
• objects — the domain objects your product exposes.
• events — the event surface your product emits or consumes.
• constraints — hard constraints the fit-gap should respect.
• knownPatterns — integration patterns your product already supports, useful as fit-gap anchors.

All fields are optional, but a pack with nothing in it gives the fit-gap nothing to compare against.

How the fit-gap uses a pack

The Integration Fit Gap Analyzer:

1. Loads the capability pack first (before any research).
2. Uses vendor docs URLs if provided; otherwise discovers docs with Firecrawl.
3. For each target system, checks whether the pack’s capabilities match the vendor’s surface.
4. Marks rows supported only when direct evidence exists on both sides — the pack asserts the capability, and the vendor docs confirm it.
5. Marks rows unknown when either side is missing.

The pack is an internal source of truth. It does not grant capabilities; it declares them. If your product adds a new auth method, update the pack so the fit-gap can see it.

Adding your own capability pack

Create a new YAML file in capability-packs/, give it an id, and fill in the fields that apply to your product. Then pass the id to the fit-gap as notes.capabilityPackId:

Can we integrate against Snowflake? Compare to the my-product-core capability pack.

Codex will load capability-packs/my-product-core.yaml and use it.

Why this is kept small

Capability packs are deliberately small. The goal is to keep the pack honest — a pack that claims too much is worse than a pack that claims too little. “Supported but with a workaround” is a row the fit-gap itself surfaces; it is not something you encode in the pack.

If the pack grows into a large spec, consider splitting it:

• A “core” pack with the always-true capabilities.
• A product-line pack per surface area.
• A pack per integration family (events, auth, storage).

The fit-gap takes exactly one pack id per run.

Relation to the shipped pack

solutioneer-core.yaml is the pack for Solutioneer itself. If you are running fit-gaps against Solutioneer’s own capabilities (for example, during a self-demo), that is the pack to pass. For real customer work, point at a pack that describes your product.