Integration Runbook Builder
Produces the runbook that takes an enterprise integration from kickoff to go-live: connection setup, document flows, test plan, cutover checklist, and failure escalation paths. One runbook per protocol, from a shared skeleton.
Inputs
- Protocol: EDI, cXML, REST API, SFTP, or email/CSV
- Direction and documents: e.g., outbound PO (EDI 850), inbound PO acknowledgment (855), ASN (856), invoice (810)
- Buyer platform and supplier system names
- Environments available (sandbox, staging, production)
Workflow
- Read the protocol module in
references/ (one file per protocol: edi.md, cxml.md, api.md, sftp.md, csv.md). Each module carries the protocol's connection prerequisites, document mapping table skeleton, and known failure modes.
- Run
scripts/scaffold_runbook.py --protocol <p> to emit the skeleton with the correct sections.
- Fill the mapping table: every field the buyer sends, the field it lands in, transformation rule, and the owner of each mapping decision.
- Build the test plan as paired assertions: for each document flow, the triggering action, the expected artifact, and the exact location to verify it.
- Append the cutover checklist and the escalation matrix (first responder, platform owner, supplier owner, and the evidence each needs).
Output format
Single markdown runbook: ## Connection, ## Document Flows, ## Field Mapping, ## Test Plan, ## Cutover, ## Escalation.
Guardrails
- Every test plan entry must be verifiable by a named artifact. "Confirm it works" is not a test step.
- Mapping tables with unresolved owners block go-live. Mark them loudly.
1---2name: integration-runbook-builder3description: Generate a protocol-specific B2B integration runbook (EDI, cXML, API, SFTP, or email/CSV) for a new enterprise customer integration. Use this skill whenever the user mentions integration docs, onboarding runbooks, EDI 850/855/856/810 flows, SFTP file drops, integration kickoff, or asks to document how a customer will connect, even if they only name the protocol.4---56# Integration Runbook Builder78Produces the runbook that takes an enterprise integration from kickoff to go-live: connection setup, document flows, test plan, cutover checklist, and failure escalation paths. One runbook per protocol, from a shared skeleton.910## Inputs1112- Protocol: EDI, cXML, REST API, SFTP, or email/CSV13- Direction and documents: e.g., outbound PO (EDI 850), inbound PO acknowledgment (855), ASN (856), invoice (810)14- Buyer platform and supplier system names15- Environments available (sandbox, staging, production)1617## Workflow18191. Read the protocol module in `references/` (one file per protocol: `edi.md`, `cxml.md`, `api.md`, `sftp.md`, `csv.md`). Each module carries the protocol's connection prerequisites, document mapping table skeleton, and known failure modes.202. Run `scripts/scaffold_runbook.py --protocol <p>` to emit the skeleton with the correct sections.213. Fill the mapping table: every field the buyer sends, the field it lands in, transformation rule, and the owner of each mapping decision.224. Build the test plan as paired assertions: for each document flow, the triggering action, the expected artifact, and the exact location to verify it.235. Append the cutover checklist and the escalation matrix (first responder, platform owner, supplier owner, and the evidence each needs).2425## Output format2627Single markdown runbook: `## Connection`, `## Document Flows`, `## Field Mapping`, `## Test Plan`, `## Cutover`, `## Escalation`.2829## Guardrails3031- Every test plan entry must be verifiable by a named artifact. "Confirm it works" is not a test step.32- Mapping tables with unresolved owners block go-live. Mark them loudly.
Prashanthvara