POC Handoff Orchestrator

poc-handoff-orchestrator produces a delivery-ready handoff package in chat. It consumes prior artifacts first and only calls out for research to fill missing technical grounding.

What this skill is

A conversational pre-sales-to-delivery handoff workflow. You hand it the prior discovery, demo, and fit-gap context — or point at a chat that contains them — and it returns:

• A short summary.
• A POC plan.
• An architecture note.
• Milestones with owners where known.
• A risk register.
• Dependencies.
• Citations, or assumptions when grounding was incomplete.

It can call Firecrawl search and scrape to fill missing technical citations, and it can create Linear projects, project milestones, issues, and updates, Confluence pages, Google Docs, or GitHub issues when you explicitly ask for writeback.

Trigger conditions

Use this skill when the user asks for:

• A POC plan.
• A handoff package.
• Architecture notes after discovery.
• Milestones, owners, and risks for a pilot or proof.

Intake order

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

1. Prior discovery, demo, or fit-gap context.
2. notes.useCase — the chosen use case.
3. notes.successCriteria — what “done” looks like.
4. notes.milestones — timing and target dates.

Output shape

The artifact is returned in chat with these sections:

1. Summary
2. POC plan
3. Architecture note
4. Milestones
5. Risks
6. Dependencies
7. Citations / assumptions

How to best use this skill

Run it last in the chain. The handoff is most useful when it has real prior artifacts to consume. Running it without a brief, demo, or fit-gap in scope will work, but the plan will carry more assumptions than citations.

Bring your artifacts into chat. The easiest way is to run the handoff in the same conversation where the prior skills produced their artifacts. You can also reference prior artifacts via artifactRefs if they live elsewhere.

Tie milestones to success criteria. “Kickoff within 2 weeks, validation by end of month” translates directly into milestone structure. Without explicit timing you get milestones with TBD dates, which is fine for a draft but worse for a real handoff.

Treat the risk register as open work. Risks flagged by the handoff are often the most useful output — they become the escalation list for the delivery team. If a risk is too vague to act on, ask Codex to tighten it.

Save and writeback are opt-in, but often worth it here. The handoff is the one skill where external writeback is most useful in practice. A Linear project with a milestone set + issue-per-risk is a reasonable default when the matching toolkits are connected. Codex will still confirm the destination and toolkit connectivity before writing.

How to combine with other skills

• With Account Intel Brief. The brief’s company snapshot and stack signals inform the architecture note.
• With Demo Scenario Builder. The demo’s seed data, objections, and persona context shape the POC plan’s scope and success criteria.
• With Integration Fit Gap Analyzer. This is the most load-bearing upstream skill. gap and unknown rows from the fit-gap become POC milestones (for confirming support) and risks (for scoping unsupported behavior). The handoff explicitly threads fit-gap evidence into the architecture note.

Run in order: brief → demo → fit-gap → handoff. Each skill picks up what the prior skills produced. You do not have to run every upstream skill, but the handoff is most valuable when it has something to consume.

Example invocations

Explicit:

$poc-handoff-orchestrator acme-health

Natural language:

Turn this discovery and fit-gap into a POC handoff package. Kickoff within 2 weeks, validation by end of month.

Example normalized input (for reference):

{
  "account": { "name": "Acme Health" },
  "objective": "Prepare the POC handoff package",
  "notes": {
    "targetDates": ["Kickoff within 2 weeks", "Validation by end of month"]
  },
  "artifactRefs": [],
  "destinations": {},
  "providerMode": "auto"
}

Provider behavior

• With FIRECRAWL_API_KEY — Firecrawl fills missing technical citations via search and scrape.
• Without FIRECRAWL_API_KEY — the package stays local-only and uncited claims are flagged as assumptions.
• External writeback — requires COMPOSIO_API_KEY and a connected toolkit. Supported toolkits: linear, confluence, googlesuper, and github. This skill uses the broadest set of Composio tools, including Linear project and milestone creation, project updates, and issue creation. See Connect Linear, Connect Confluence, Connect Google Docs & Sheets, and Connect GitHub.