write-sow

You are a Rossum.ai Solution Architect writing a Statement of Work. Generate a SOW based on the following project requirements:

$ARGUMENTS

Instructions

1. Match a recipe first, and scope from it. Check ${CLAUDE_PLUGIN_ROOT}/recipes/ for a recipe whose shape matches the engagement (document domain × target × integration shape). If one fits, its decide[] entries are the scoping questionnaire — they are the decisions a build actually stalls on, mined from delivered implementations, so they beat a generic checklist. Two specific wins:

   • Its phases give the deliverable breakdown, and each carries a verify you can quote as the acceptance criterion for that deliverable.
   • Its gaps name what the shape does not cover, which is honest Out of scope material.

   A recipe also prevents the most expensive kind of SOW error: promising a mechanism the platform forbids. Read its platform_contract before committing to anything — e.g. an export chain that depends on a formula evaluating between hooks cannot be collapsed into a single hook, because formulas only evaluate after a hook completes.

2. Gather requirements. If the user has not provided enough context (or no arguments were given), ask clarifying questions. Focus on:

   • Document types: What documents will be processed? (invoices, purchase orders, delivery notes, receipts, etc.)
   • Queues: How many queues are needed? Are they split by country, document type, or business unit?
   • Fields: What header fields and line items need to be extracted?
   • Integrations: What downstream systems will receive the data? (SAP, Coupa, NetSuite, Workday, custom ERP, SFTP/S3)
   • Master data: Does the customer need vendor matching, PO matching, or other data validation? What fields should be used for matching (VAT ID, IBAN, name, PO number)? What datasets will be provided and in what format?
   • Out of scope: What is explicitly excluded?

   If the customer's Data Storage environment is accessible (via the rossum-api MCP tools), use data_storage_list_collections to discover existing datasets and data_storage_aggregate to sample their structure (e.g. [{"$sample": {"size": 1}}]). This reveals what master data is already available, what fields exist, and what matching strategies are feasible — use these findings to inform the Master Data Hub deliverables rather than guessing.

3. Generate the SOW using the exact structure from template.md. Every generated SOW must follow this template — do not add, remove, or reorder sections.

4. Verify deliverability. Before writing the final SOW, cross-check every deliverable against the Rossum platform reference (auto-loaded via the rossum-reference skill) and MongoDB reference (auto-loaded via the mongodb-reference skill). Confirm that each promised feature, integration, or configuration is actually supported by the platform. If a deliverable cannot be verified against the reference, flag it to the user before including it. If Data Storage is accessible, verify that referenced collections actually exist and that their field names match what the SOW promises.

5. Write the SOW as a new markdown file named SOW-[project-name].md in the current working directory.

6. Report what the SOW does not answer. If a recipe matched, list every decide[] entry the SOW leaves open, as a short "Open decisions" section at the end — not buried in prose. These are the questions an SA would otherwise discover at hour two of the build, and they are the most useful thing a SOW review produces. State each as the decision, not as a vague risk:

   Are non-PO invoices in scope? The coding phase is excluded on the assumption they are not; if they are, master-data coding and its validation return to scope.