Dotfile

View saved version →

---
name: anomaly-check
description: 'What moved in this workspace recently'
metadata:
  title: 'Trends'
  category: queue
  order: '5'
  plugin: 'true'
---

An anomaly is a number that MOVED, not one that is high. 1. Baseline: show_analytic_widget with cases created per day over the recent weeks — compare the last 7 days to the daily average of the weeks before. 2. Distributions, not totals: show_analytic_widget breakdowns of cases by risk and by assignee, checks by type and by status. The signal is a shift in the mix. 3. To compare two periods, call query_entities with perPage 1 and read the total, twice, with the two date ranges. NEVER paginate to count. 4. At most 5 findings: what moved with both numbers and periods; whether this is normal variation at these volumes; the likely cause only if data supports it; what to look at, linked. 5. A mandatory 'what I could not check' section. If nothing moved, say Nothing abnormal, add the blind spots, stop.

View saved version →

---
name: audit-my-setup
description: 'Review the workspace configuration against its usage and name what is missing, unused or switched off'
metadata:
  title: 'Audit My Setup'
  category: configuration
  order: '11'
  plugin: 'true'
---

1. Read the configuration: templates and rules, controls, document types, custom properties, portals, enabled check types, AI review and policy settings. 2. Compare against what the workspace actually does — which check types are used, which templates applied, which portals get traffic. 3. Report three lists: configured but never used, used but misconfigured, switched off while clearly needed. 4. Rank by what it costs today, with the number behind each. 5. Never recommend enabling something with a cost or regulatory implication without naming it.

View saved version →

---
name: automation-audit
description: 'What stands between your cases and automatic approval, and what to automate next'
metadata:
  title: 'Automation Audit'
  category: audits
  order: '24'
  plugin: 'true'
---

1. STRAIGHT-THROUGH RATE: share of cases decided with no human action at all, overall and per template. This is the headline and it goes first. 2. WHAT BLOCKS AUTO-APPROVAL, ranked by cases held: controls requiring manual completion, check types that never auto-approve, template rules forcing review, and cases that met every criterion but were not auto-approved for a configuration detail. Name the specific control or rule, not the category. 3. DEAD CONFIGURATION: controls defined and never completed, rules that never fire, rules that fire on almost everything. All three block or bloat approval without adding assurance. 4. HUMAN ACTIONS PER CASE: the distribution, and the most frequent repeated action sequences across cases. Where the same three or four actions recur on most cases, name that sequence — it is a routine waiting to be written. 5. AVOIDABLE REWORK: work redone rather than done — hits dismissed that an AI already judged, checks created then deleted, the same document requested twice. Quantify each. 6. AUTOMATION BACKLOG: rank candidates by the human actions they would remove, and say whether the platform can already do it. Close with the three changes that would move the straight-through rate most, each with the cases affected. Be honest when a blocker is a deliberate compliance choice — never recommend removing a control that exists for a reason.

View saved version →

---
name: business-data-audit
description: 'How company data and ownership resolution really work, by vendor and by country'
metadata:
  title: 'Business Data Audit'
  category: audits
  order: '23'
  plugin: 'true'
---

1. UBO RESOLUTION: share of companies whose ownership chain resolved to identified natural persons, partially resolved, or not at all. This is the core KYB quality measure and it leads the report. 2. DEPTH AND BREAK POINTS: how many ownership levels were traversed, and where chains stop — which country, registry, entity type. 3. BY COUNTRY: resolution rate and data completeness per jurisdiction. Name the countries where the current vendor underperforms and whether another configured vendor does better there. 4. BY VENDOR: companies fetched, field completeness, UBO resolution rate, error and timeout rate, median latency. 5. MANUAL COMPLETION: how often a human added or corrected ownership after the vendor returned — the real cost of poor coverage. 6. DOCUMENT ORDERS: ordered, delivered, failed, by vendor and product, with median delivery time. 7. STALENESS: share of companies older than my policy requires — the population a periodic-review routine would target. Close with a routing recommendation per country and its evidence. Never recommend a vendor switch on a sample too small to support it — say so instead.

View saved version →

---
name: case-brief
description: 'Where this case stands: what is done, what blocks it, and the single next action'
metadata:
  title: 'Case Brief'
  category: cases
  order: '7'
  plugin: 'true'
---

No case in context: ask which case, or find it with query_entities, before anything else. 1. Start from the case context, then query_entities on checks, with a case__default__id rule for this case since it reads the whole workspace, and get_check on every check that is not approved, so you read the real result and any review comment. 2. list_case_controls and list_notes. 3. Report: status, risk, template, assignee on one line; what is done; what is blocking — each non-approved check with type, entity, status and the concrete reason from its result, cited not paraphrased, then each incomplete manual control; what is missing that nobody has requested; one next action and who must do it. Link every entity you name. If the next step is a human decision, say so — never invent an escalation path you have no tool for.

View saved version →

---
name: case-timeline
description: 'What happened on this case and why'
metadata:
  title: 'Case Timeline'
  category: cases
  order: '3'
  plugin: 'true'
---

No case in context: ask which case, or find it with query_entities, before anything else. Explain this case's history. 1. Rebuild the chronology: entities created, template applied, checks created, results, reviews and decisions, communications, status and risk changes, controls. 2. For every step name the actor and its nature — a person, the API, the automation engine acting on a template rule, the portal contact, the system. Never state that something happened without saying what caused it. 3. Then answer the negative questions, which are the ones people actually ask: why a check was never created (which rule matched or did not, on which attribute), why the case was not auto-approved (which condition failed), why a step came late. 4. Where the record does not explain something, say so rather than constructing a plausible reason. An honest gap is useful; an invented cause is not. 5. Close with a short answer to my actual question, above the timeline.

View saved version →

---
name: close-out-controls
description: 'Complete the manual controls the file already evidences; list what the rest still needs'
metadata:
  title: 'Close Out Controls'
  category: cases
  order: '10'
  plugin: 'true'
---

No case in context: ask which case, or find it with query_entities, before anything else. 1. list_case_controls. 2. For each incomplete manual control, look for evidence in the case that satisfies it: an approved check, a note, a document, a completed communication. 3. Mark completed only where you can cite the specific evidence, and put that citation in the completion comment. 4. For the rest, say exactly what is missing and who must provide it. 5. Never complete a control you cannot evidence; never touch automatic controls.

View saved version →

---
name: document-audit
description: 'How document collection and review really perform: AI coverage, forensics value, and configuration faults'
metadata:
  title: 'Document Audit'
  category: audits
  order: '22'
  plugin: 'true'
---

1. COVERAGE: documents received, analysed by AI, reviewed by a human, as a share per type. Name types where AI review is available but never used, and types where AI runs but always defers to a human — the second is a cost with no benefit. 2. OUTCOME BY TYPE: approved, rejected, awaiting, and the rejection rate; then the worst types and the top rejection reasons behind each, taken from review comments rather than inferred. 3. RE-REQUEST LOOPS: types needing two or more rounds, with the count and the median added delay. The usual fix is the portal instruction, not the check. 4. EXTRACTION FAILURES: documents where extraction produced nothing usable, forcing manual review, per type. 5. DOCUMENT FORENSICS: whether it is enabled, on which types, its finding rate, and — the question that matters — how often a finding actually changed the outcome. If it never changes an outcome, it is paid noise; say so. 6. EXPIRY COVERAGE: share of approved documents with no expiration date, which is silent staleness. 7. CONFIGURATION FAULTS: types defined and never used, types with neither AI review nor forensics, types where the requested and received document routinely differ. Close with three changes, each with its number, and separate a collection problem (the client sends the wrong thing) from a quality problem (unreadable) from a configuration problem (we asked for the wrong thing) — different fixes, different owners.

View saved version →

---
name: explain-template
description: 'What this template actually does: which checks and controls it creates, under which conditions'
metadata:
  title: 'Explain This Template'
  category: configuration
  order: '12'
  plugin: 'true'
---

1. Read the template's rules, the checks and controls they create, and the conditions on each. 2. Describe in plain language what happens to a case matching a given profile — walk one concrete profile through. 3. Name the conditions easy to get wrong: rules that never fire, rules that fire on almost everything, attributes the rule depends on that are often empty. 4. If I give you a case, say which rules matched and which did not, and why. 5. Never describe a rule you have not read.

View saved version →

---
name: idv-audit
description: 'IDV, ID document and eKYC performance end to end, with a fair vendor comparison'
metadata:
  title: 'Identity Verification Audit'
  category: audits
  order: '21'
  plugin: 'true'
---

METHOD, and state it in the output — the naive version of this comparison is usually wrong. Exclude batch-created checks: bulk re-verification campaigns measure outreach, not vendor quality, so detect them (many created in one or two days, most never engaged) and report them separately. Count only checks old enough to have completed, and only the latest attempt per check. When vendors have different tenure, compare at equal cohort age — approval within 1 hour, 24 hours, 7 days, 14 days side by side, not final rates. Segment by how old the case was when the check was created: population mix usually moves the numbers more than the vendor. REPORT: 1. The funnel per check type — created, never started, started, completed, auto-approved, human-approved, vendor-declined. 2. The two metrics that decide it: straight-through rate, and how often a human overruled a vendor decline. 3. Median and 90th-percentile time to approval. 4. Never-started rate — a drop-off before the subject begins, so a portal problem, not a vendor one. 5. Retry behaviour: attempts per check, and whether a retry usually succeeds. If it does, a first failure is a usability problem, not a fraud signal. 6. Where failures concentrate: document type, issuing country, verification mode. 7. Where both eKYC and IDV run on comparable people, which performs better. 8. EXPOSURE: approved identity documents already expired or expiring within 90 days. Close with a recommendation per check type, and say plainly when a difference is inside noise.

View saved version →

---
name: monitoring-value
description: 'Which ongoing-monitoring alerts are open, and which categories ever lead to an action'
metadata:
  title: 'Monitoring Status'
  category: queue
  order: '18'
  plugin: 'true'
---

1. List the open monitoring alerts by category and age, oldest first. 2. Per category, how many alerts were acknowledged with no further action versus followed by a real action — a risk change, a new check, a case reopened, a decision reversed. 3. Name the categories that never lead to anything. 4. Report how many companies had monitoring switched off in the period, and whether that tracks alert volume.

View saved version →

---
name: onboarding-status
description: 'Where this workspace stands in its setup, what blocks progress, and the next action'
metadata:
  title: 'Onboarding Status'
  category: configuration
  order: '25'
  plugin: 'true'
---

1. Read the configuration: templates and rules, checks and controls per template, document types, custom properties, portals, enabled check types and vendor credentials, AI review policy, users and roles, webhooks and API keys. 2. Score it stage by stage against a complete setup: entities and templates defined; checks wired per entity type; a live collection channel (portal or API); review policy set; risk configured; team and permissions; integration and notifications. For each stage say done, partial or not started — and for partial, exactly what is missing. 3. Then verify it works rather than merely exists: has each template ever been applied, has each portal received a submission, has each check type ever run, has anything ever been approved. Configured but never exercised is not done. 4. Report the stage we are on, the three things blocking progress in order, and the single next action with who owns it — us or the customer. 5. Name anything configured in a way that will cause trouble later: a portal with no template, a control nobody can complete, a check type enabled without vendor credentials, auto-approval on with no risk rules. Keep it to one screen. This gets run repeatedly — if I give you the previous state, lead with what changed.

View saved version →

---
name: portal-funnel
description: 'Where applicants drop off between the invitation and a completed file'
metadata:
  title: 'Client Portal Funnel'
  category: audits
  order: '6'
  plugin: 'true'
---

Build the portal funnel for the period I name: communications sent with a portal link, portals opened, forms started, forms completed, cases reaching a decision. Give the conversion at each step and the drop-off between them, by portal, entity type and country where volumes allow. Name the biggest leak, how many applicants are lost there, and what the data does and does not say about why. If a step cannot be measured, say so rather than interpolating it.

View saved version →

---
name: prune-parties
description: 'Propose which parties are out of scope, with a reason and the threshold applied'
metadata:
  title: 'Prune Parties'
  category: cases
  order: '15'
  plugin: 'true'
---

No case in context: ask which case, or find it with query_entities, before anything else. 1. List every individual and company with role and ownership percentage. 2. Propose which are out of scope: below the ownership threshold, non-controlling roles, duplicates. 3. One-line reason each, and state the threshold you applied. 4. Flag separately anyone you are unsure about rather than defaulting to excluding them, and never mark anything without my confirmation.

View saved version →

---
name: refresh-company
description: 'Re-purchase company data and report only what changed'
metadata:
  title: 'Refresh Business Data'
  category: cases
  order: '14'
  plugin: 'true'
---

No company in context: ask which company, or find it with query_entities, before anything else. 1. buy_company_data — every call is a new vendor request billed under the workspace's existing contract, with no dedup, so check how recent the current data is and skip if fresh enough, saying so. 2. get_company_data_changes: a free deterministic diff of the two latest snapshots. 3. Report only what changed: legal form, status, share capital, directors, ownership, address, registration. 4. Add a note to the case with the diff. 5. If a director, owner or legal status changed, call it material and recommend re-running the affected checks — do not launch them without asking.

View saved version →

---
name: reviewer-consistency
description: 'Where similar cases got different decisions, and which reviewers diverge'
metadata:
  title: 'Reviewer Consistency'
  category: audits
  order: '17'
  plugin: 'true'
---

Group checks by type and comparable result profile, then find groups where outcomes differ. Per group: comparable checks, the split of outcomes, which reviewers sit on each side. Same at case level by risk and template. At most five groups, most material first, saying for each whether it looks like genuine inconsistency or a legitimate difference in the files. Never name a reviewer as wrong — name the divergence and let a human judge.

View saved version →

---
name: screening-audit
description: 'What your AML screening produces, how much is noise, and which lever fixes it'
metadata:
  title: 'Screening Audit'
  category: audits
  order: '20'
  plugin: 'true'
---

1. VOLUME AND SHAPE: searches run, and the distribution of hits per search — not the average. Share of searches with 0, 1-5, 6-20, 21-50, 50+ hits, and which entity types generate the largest counts. 2. OUTCOME: confirmed, dismissed, undecided, with the true-positive rate, broken down by list type — the tuning lever differs per list. 3. AI COVERAGE AND AGREEMENT: what share of hits the AI analysed, and where it did, how often the human agreed. Three separate numbers: AI said false positive and the human agreed; AI said false positive and the human disagreed; no AI analysis at all. The third is a configuration gap, not a workload. 4. THRESHOLD EVIDENCE: relate the match score to the outcome. High-scoring hits routinely dismissed means matching is too loose; low-scoring hits routinely confirmed means too tight. State which, or state that the data does not support either. 5. REPEAT NOISE: the same subject returning the same dismissed hit on every re-screen. 6. ONGOING MONITORING: separate monitoring hits from initial screening and give their rates separately — mixing them misleads. 7. VENDOR: if more than one is in use, compare hits per search and true-positive rate on comparable populations. 8. BACKLOG: undecided hits by age, oldest first. Close with the two or three configuration changes the data supports, each with its number and the detection risk it carries. Never recommend narrowing a list or raising a threshold without naming that risk.

View saved version →

---
name: team-load
description: 'How the open workload is spread across the team right now'
metadata:
  title: 'Team Load'
  category: queue
  order: '8'
  plugin: 'true'
---

1. show_analytic_widget with open cases broken down by assignee, then by risk. 2. show_analytic_widget with the checks pending review broken down by type. 3. Per member, an exact count of open cases: query_entities with perPage 1, read the total, never paginate. Same for unassigned. 4. Report open cases per member split by risk, the unassigned pile, the review queue by type. Name who carries the most high-and-above risk, not who holds the most cases. 5. State what you cannot see: how much each person processed, how fast, when they last touched their cases. Do not infer productivity from case counts.

View saved version →

---
name: team-throughput
description: 'Who processed what over a period, and the trend'
metadata:
  title: 'Team Throughput'
  category: audits
  order: '19'
  plugin: 'true'
---

Per member for the period I name: cases decided, checks reviewed, median and 90th-percentile time from case open to decision, and the trend against the previous period of equal length. Then the three whose queue grows faster than they clear it, and the three whose median time moved most. Always give the two numbers behind a trend, and say when a difference is too small to mean anything.

View saved version →

---
name: template-fit
description: 'Which templates produce the right checks, and which produce work people then undo'
metadata:
  title: 'Template Fit'
  category: audits
  order: '13'
  plugin: 'true'
---

Per template for the period I name: cases created, checks created, checks later deleted by a human, share auto-approved, share decided without a manually added check, median time to decision. Flag the templates whose checks get deleted most, and those where analysts routinely add a check the template did not create. For each, say which rule the pattern points to. Do not propose a change you cannot support with counts.

View saved version →

---
name: time-to-decision
description: 'Where the elapsed time goes between a case opening and a decision'
metadata:
  title: 'Time to Decision'
  category: audits
  order: '16'
  plugin: 'true'
---

For decided cases in the period I name: median and 90th-percentile time from creation to decision, then split that total into waiting on the client, waiting on a vendor, and waiting on us, as a share of total. Break down by template and entity type. Name the longest stage and its share. Distinguish elapsed from working time and say which you measured.