Integration Fit Gap Analyzer

integration-fit-gap-analyzer produces a defensible fit-gap assessment in chat. It grounds support claims in evidence and leaves unsupported or ungrounded areas as unknown rather than guessing.

What this skill is

A conversational integration-assessment workflow. You hand it a target stack (vendor systems, API docs URLs, or both) and an internal capability pack, and it returns:

• A fit-gap summary.
• A support / workaround / gap / unknown matrix.
• Open questions.
• Risks.
• Citations, or explicit unknown rows where grounding was not possible.

It can call every Firecrawl mode (search, map, crawl, scrape, and interact) for doc discovery and extraction, and it can create Linear issues, Confluence pages, Google Docs, or GitHub issues for gap and unknown rows when you explicitly ask for tracker writeback.

Trigger conditions

Use this skill when the user asks:

• “Can we integrate with X?”
• “Do we support Y?”
• “What are the integration risks?”
• “Where are the gaps or workarounds?”

Intake order

Codex asks one question at a time, in this order:

1. notes.targetSystems or docs URLs.
2. notes.capabilityPackId — the internal capability pack to compare against.
3. notes.decision — the key decision being answered.

Output shape

The artifact is returned in chat with these sections:

1. Fit-gap summary
2. Matrix
3. Open questions
4. Risks
5. Citations / unknowns

How to best use this skill

Feed it docs URLs when you have them. If the prospect has already pointed you at their API or integration docs, include the URLs. Codex will prefer those over discovery via Firecrawl, which keeps grounding tighter.

Choose the right capability pack. Capability packs (capability-packs/*) describe what your product supports. The default solutioneer-core pack is a good starting point for demos of this pack itself, but for real assessments you should point at a pack that actually describes your product’s surface.

Trust unknown. The skill is deliberately unwilling to mark things supported without direct evidence. If a row is unknown, treat it as open work — either for research or for a call to the vendor. Do not pressure the skill into a supported verdict. Freehanding integration claims is the exact failure mode Solutioneer is designed to avoid.

Create trackers only for gap and unknown. When you ask for tracker writeback, Codex only creates issues for the rows that actually represent open work. supported rows do not get tracker issues.

Name the decision up front. “Can we win this deal without native Stripe support?” produces a sharper matrix than “general fit-gap on Stripe”.

Save and writeback are opt-in. By default the report is returned in chat. External tracker or doc creation requires a connected Composio toolkit.

How to combine with other skills

• With Account Intel Brief. The brief’s stack signals often point to the vendors that should be in the fit-gap matrix. Run the brief first, then feed its stack signals into notes.targetSystems.
• With Demo Scenario Builder. Run the fit-gap before or during demo prep when the account is likely to ask specific integration questions. The demo’s “Likely objections” section will pick up the fit-gap’s answers instead of winging them.
• With POC Handoff Orchestrator. The POC plan explicitly consumes fit-gap artifacts. Keep the fit-gap in the same chat so the handoff can translate gap and unknown rows into POC milestones and risks without re-researching.

Example invocations

Explicit:

$integration-fit-gap-analyzer "Beta Manufacturing — Segment and Stripe"

Natural language:

Can we integrate Solutioneer with Segment and HubSpot? Compare against the solutioneer-core capability pack.

Example normalized input (for reference):

{
  "account": { "name": "Beta Manufacturing" },
  "objective": "Assess integration fit against Segment and Stripe",
  "notes": {
    "capabilityPackId": "solutioneer-core",
    "targetSystems": ["Segment", "Stripe"],
    "vendorDocs": []
  },
  "artifactRefs": [],
  "destinations": {},
  "providerMode": "auto"
}

Provider behavior

• With FIRECRAWL_API_KEY — Firecrawl discovers and extracts vendor docs across all five modes. Every supported row carries a citation.
• Without FIRECRAWL_API_KEY — unsupported or ungrounded rows are kept as unknown. Codex does not replace missing evidence with guessed support claims.
• External writeback — requires COMPOSIO_API_KEY and a connected toolkit. Supported toolkits: linear, confluence, googlesuper, and github. See Connect Linear, Connect Confluence, Connect Google Docs & Sheets, and Connect GitHub.

Related reference

• Capability Packs — the YAML format Codex uses to describe what your product supports.
• Grounding Rules — why unknown is preferred over a guessed supported.