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’”
  • “When a member’s PEP status changes, send a form and remind them until they submit”
  • “Create a periodic review alert 90 days after each corporate client update”
  • “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?”
  • “Scope a manual-run playbook analysts trigger from an alert page”

​
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, notifications, case opening, AI analysis, client outreach, external API calls. Use workflows for everything except real-time transaction blocking.

​
What Workflows Can Express

  • Event triggers: entity created/updated (individual client, corporate client, individual member, corporate member, alert, case, transaction) with field-level filters — including jurisdiction, rule name, screening statuses, assignee, sub-disposition, transition filters (changed_from_to), and created/updated date ranges
  • Scheduled triggers: calendar-based (daily, weekly, monthly) scan of individual or corporate clients matching filters
  • Manual triggers: analyst-initiated runs from alert, case, client, or transaction record pages
  • Steps:
    • Action — customer email/form with reminders; Deep Research; PEP/Sanctions screening with optional alert on match
    • Record — create alert (with optional delay), update alert/case/client/transaction; escalate alert and update case in same run
    • Notify — in-app, email, Slack to analysts with smart data variables
    • Agent — AI analysis with tools and structured output
    • Webhook — outbound HTTPS to external systems
    • Branch — conditional paths on entity fields or prior step outputs

​
What Workflows Cannot Express (Capability Gaps)

​
Output Format

A 1–2 paragraph plain-English description containing: the trigger (event + filters, calendar schedule + population, or manual run context), 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.