Skip to main content

​
Overview

The corsa-workflow-scoping skill turns a compliance policy (a clause, obligation, or AML/CFT requirement) into a 1–2 paragraph workflow description that a downstream agent — or a developer using the corsa-workflow-authoring skill — can implement directly. It knows exactly what Corsa workflows can and cannot do, so it never describes features that don’t exist and always flags capability gaps explicitly.

​
What It Helps With

  • Extracting the trigger, steps, and compliance obligations from a policy clause
  • Mapping policy requirements to Corsa workflow capabilities
  • Identifying what falls outside the workflow engine (e.g. real-time transaction blocking belongs to the rules engine)
  • Producing concise, implementation-ready descriptions

​
Quick Start

After installing the skill, ask your coding tool questions like:
  • “Scope a workflow for: ‘when a client reaches HIGH risk, run EDD within 3 business days’”
  • “Translate our AML Policy §5.3 on dormant client re-activation into a Corsa workflow spec”
  • “Can a workflow freeze a transaction in real time?”
  • “What should be a workflow vs. a transaction monitoring rule?”

​
What the Skill Knows

​
The Two-Step Workflow

Use this skill first to produce the spec, then hand it to corsa-workflow-authoring for implementation.

​
Workflow vs. Rule — The Key Distinction

Rules evaluate synchronously per transaction and can block/freeze transactions in real time. Workflows react after events and orchestrate follow-up actions — screening, risk assessment, notifications, case opening, AI analysis. Use workflows for everything except real-time transaction blocking.

​
What Workflows Can Express

  • Event triggers: entity created/updated (individual client, corporate client, alert, case, transaction) with field-level filters
  • Scheduled triggers: periodic scan of individual or corporate clients matching filters
  • Steps: client screening, PEP/sanctions re-screening, risk assessment, document/information requests, periodic review tasks, alert/case creation, entity updates, analyst notifications (in-app, email, Slack), client emails, AI/Copilot analysis, outbound webhooks
  • Branching: conditional fan-out based on entity fields or prior step outputs (e.g. AI verdict)

​
What Workflows Cannot Express (Capability Gaps)

​
Output Format

A 1–2 paragraph plain-English description containing: the trigger (event + filters, or schedule + population), the ordered steps and conditional branches, what records are created/updated, who is notified, and the compliance driver (policy citation + SLA/escalation/record-keeping obligations). No JSON, no node names — intent only, ready for implementation.

​
Source

GitHub Repository

View the full skill source with policy-to-capability mappings and worked examples.