Stacking Your Tech: Practical Tips for Solicitors

Morning Brief — Arora Zbar LLP

Produce a same-day/next-day action plan for a staff member by synthesizing live pulls from Asana, Outlook (email + calendar), Microsoft Teams, and optionally Clio. This is a read-only planning aid — it never drafts, sends, or marks anything complete.

Input: target person

Default target is the current user (resolve via Microsoft 365:get_me or the active session identity). If the user names someone else (“what does the litigation assistant have today”), use that person’s identity for the tool calls instead — only proceed if the requester’s own connector access actually returns that person’s data (i.e., don’t fabricate visibility you don’t have; if calendar/task pulls come back empty or access-denied for a named third party, say so and stop rather than guessing).

Deriving reporting lines and collaborators from data (no hardcoded roster)

The firm’s staff roster changes; this skill must not need hand-editing when someone joins or leaves. Derive context each run from the pulled data itself:

• Frequent collaborators: rank senders/recipients in the Outlook email pull and Teams chat pull over the
• Likely supervisor(s): within that same top set, weight toward whoever is: (a) the sender of direct-address
• If the pulled window doesn’t surface enough signal to infer collaborators/supervisor with any confidence, omit

Context to apply every run

• [example with matter details removed]
• Tone: direct, concise, Canadian English, no preamble, no trailing summary.
• Clio is read-only. Never modify Clio. No emails sent, no Asana tasks completed, without explicit

  confirmation from the user first.

• Privilege: matter numbers and surnames are fine to use in-app; don’t let client identifiers leave firm context

Steps

1. Get today’s and tomorrow’s date

Resolve both before querying so calendar/task windows are correct.

2. Gather in parallel

Batch these as independent calls in one turn — they don’t depend on each other:

• Asana: Asana:get_my_tasks — completed_since="now", opt_fields="name,due_on,due_at,assignee.name,projects.name,notes,modified_at", limit 100
• Outlook calendar: Microsoft 365:outlook_calendar_search — query "*", window from today 00:00 through day-after-tomorrow 00:00, limit 25
• Outlook email: Microsoft 365:outlook_email_search — afterDateTime = 3 days ago 00:00, limit 25
• Teams: Microsoft 365:chat_message_search — query "*", afterDateTime = 2 days ago 00:00, limit 25
• Clio (optional, if a Clio user ID is known for the target): Clio:get_tasks — assignee_id=<target's Clio user id>, status=pending, limit 100; and Clio:get_calendar_entries for today/tomorrow, owner_id=<target's Clio user id>

3. Synthesize into this exact structure

Constraints — do not deviate

• Trust flag: if anything in the pulled data touches the trust ledger or firm trust bank accounts, surface it

  at the top of the response, above the Today section, prefixed Trust flag:, and confirm LSBC implications before proceeding further with the rest of the brief.

• Plan only — don’t draft or send any email, Teams message, or Asana update. If the user wants a draft based
• If a deadline in the pulled data appears to have just passed, say so explicitly and suggest verifying it was
• Keep the whole response under ~500 words.

Tools this skill uses

• Asana:get_my_tasks
• Microsoft 365:outlook_calendar_search
• Microsoft 365:outlook_email_search
• Microsoft 365:chat_message_search
• Microsoft 365:get_me (to resolve “current user” as the default target)
• Clio:get_tasks (optional)

Onboarding Task Review — Arora Zbar LLP

Audit a client onboarding task and return a condensed report of: what Clio actually has (not what a stale screenshot suggests), what’s missing but internally sourceable, what’s genuinely blocked on the client, and whether the firm is exposed (LSBC verification gap, substantive work proceeding without a signed engagement, invoices issued without onboarding complete).

Output format — keep it SHORT by default

Default output is ~100 words, 3 paragraphs, 3–4 inline links. No tables, no bucket breakdowns, no LSBC rule citations, no red-flag section, no references block, no debrief — unless the user asks for them.

The 8-step workflow

1. Fetch the Asana task in full

Use Asana:get_task with include_comments: true, include_subtasks: true, and opt_fields including name, notes, assignee.name, completed, due_on, created_at, memberships.section.name, permalink_url, tags.name.

• ⏱️ Waiting for Client ⏱️ → Client is the blocker
• 🧹 Internal Follow-up / Onboarding finalization 🧹 → Admin or attorney is the blocker
• an associate lawyer File Transfer Management → Transferred from an associate lawyer’s prior firm; expect old-firm patterns
• Deferred onboardings → Deliberately on hold
• 🛫 Clients to Onboard 🛫 → Brand new, work not yet started
• 🆕 New Matters for Existing Clients 🆕 → Abbreviated onboarding (ID already on file)

2. Identify the matter in the firm directory

Look up the client in 02-directory-active.md or 03-directory-closed.md by client name or display number. Extract:

• [example with matter details removed]
• Clio matter ID (the number in [brackets])
• Clio client contact ID (the number after [clio:...])
• Practice area and billing attorney
• Case caption

3. Pull all parties from Clio

For every named party (plaintiffs, defendants where we act, ILA recipients, corporate principals), run Clio:get_contacts with the name. Capture:

• contact_id, primary_phone, primary_email, address (if exposed)
• Note which contacts are populated and which are empty placeholders (created by Flowsana at matter opening but never filled in)

4. Search Outlook for the engagement-letter chain

Search [email] (always — admin runs the chases, not the attorney’s personal inbox) for the client name. Look for:

• “Arora Zbar LLP Engagement Letter” subject — the first send date + any resends. The firm’s pattern is Send → +2w resend → +3w strong follow-up stating “we have yet to receive signed engagement letter, intake form, and funds in trust”
• Lawmatics intake form submissions — sender [email], look for “Form Filled” notifications
• Flowsana notifications — sender [email], confirms the matter was created and Asana project spun up
• Client’s actual replies — has the client responded at all? To whom? Admin? The attorney directly?
• RingCentral text notifications — sender [email], subject “New Text Message from {client}” — these are easy to miss but often contain client responses when email fails
• Outstanding invoice chase emails — subject “RE: Outstanding Invoice {N}” — if an invoice is already out, this is a red flag that the file is being billed without being onboarded

5. Run the Clio field audit

For each of these Clio matter custom fields and contact fields, mark ✓/✗:

• Matter stage
• Opposing Parties
• Referral Source
• Previous File #
• Related Parties
• Initial Meeting Date

6. Classify missing items into three buckets

This is the core output. Use these exact emoji and ordering so Eli’s eye catches it:

• Opposing Parties (read from case caption / NOCC)
• Previous File # (ask an associate lawyer for his old-firm reference, or check Lawmatics)
• Referral Source (an associate lawyer for his transferred files, or check Lawmatics)
• Initial Meeting Date (approximate from an associate lawyer’s records or Lawmatics)
• Matter stage (ask billing attorney)
• Related Parties (link spouses, dependents, corporate principals)

7. Identify red flags for the firm

Scan for these specific exposure patterns and call them out in the headline if present:

8. Recommend the play

Don’t just list what’s missing — tell Eli what he should do. The recommendation is almost always one of:

• “the intake and closings assistant can clear buckets 1 & 2 today, then {attorney} needs to call {client} directly because they respond to the attorney but not admin.” — the Homer Simpson pattern
• “Stop substantive work until engagement is signed and ID verified. Risk is {specific LSBC rule}. {Attorney} should call client with a hard deadline.” — the Marge Simpson pattern
• “This was ready to close; only residual item is {X}. Suggest the intake and closings assistant complete, then move to offboarding.” — rare, but possible
• “Process issue for standup: {pattern}.” — if you see a systemic failure (e.g., an associate lawyer transferred files bypassing onboarding)

Tools this skill uses

• Asana:get_task — the task itself with comments + subtasks
• project_knowledge_search — for the matter in 02-directory-active.md / 03-directory-closed.md
• Clio:get_contacts — for each party
• Microsoft 365:outlook_email_search with mailboxOwnerEmail: [email] — for engagement letter chain
• Microsoft 365:read_resource — to read specific emails when the summaries are ambiguous
• Asana:search_objects (resource_type: task) — for related matter-project tasks if needed

Four observed patterns — name the pattern in the output

Always identify which pattern the file matches. The pattern dictates the play.

1. [example with matter details removed]
2. [example with matter details removed]
3. [example with matter details removed]
4. Internal blocker — firm is the bottleneck (Lisa Simpson 1234) — Admin has done everything; file is stuck because an attorney or partner hasn’t lifted a pause, supplied a template, or made a decision. Play: don’t chase client. Escalate to the internal blocker by name.

Real Estate Matter Audit — Arora Zbar LLP

Methodical walkthrough of a residential real estate matter (purchase, sale, or refinance) for the responsible lawyer. The audit lists every file in the matter folder, every material email thread in admin@arorazbar AND the current user’s mailbox, and every Asana task on the matter project — each on its own line with a status word and (where relevant) a FLAG: marker. The FLAGs roll up into a severity-ordered Issues section at the bottom. The point is complete coverage in a form that’s still concise per item — the lawyer should be able to read top-to-bottom and know exactly what’s on disk, what’s in the inbox, and what’s in Asana without opening anything else.

When this fires

Fire on any of these, when a specific matter number or RE folder is named:

• [example with matter details removed]
• “What’s left on this purchase/sale/refi”
• “Where are we on [matter]”
• “Go through the [client name] file before I sign docs”
• “What do I need to know about [matter]”
• The user pastes a Client Matters - Documents\[Surname, *] path and asks for a review

Output format

Methodical walkthrough, top-loaded for action. The lawyer reads top-to-bottom and stops when they have what they need. So the actionable Issues go first, the full file/inbox/Asana inventories sit beneath them for evidence and completeness.

• Every file gets a line. Don’t skip “obvious” or “template” files. Mark template stubs (template stub) and empty subfolders empty (template) or empty. The lawyer wants to see the full state of the folder.
• Every material email thread gets a line. Dedupe by internetMessageId across anchor queries. Mark each thread handled (closed, no action) or OPEN (something awaits). Don’t filter out “boring” threads; if they’re material to the file (i.e. not pure firm-wide accounting noise), list them.
• Every Asana task gets a line. Group as Open / Closed / Template-N-A. Mark template tasks (template, ...) so they’re visibly accounted for but clearly non-actionable.
• Issues section is a rollup of FLAGs only, severity-ordered. It does not introduce new content. Every line in Issues should correspond to a FLAG: marker earlier in the Files / Inbox / Asana sections.
• One line per item. A second line is acceptable only for a critical sub-fact (e.g. “Scotia paid 2026-05-05; 60-day window to 2026-07-03”). No paragraphs.
• Cite filename with backticks, not paths. Subfolder is the grouping header.

The workflow

Step 0 — Run inline, not in a subagent

Default: execute this skill directly in the current Cowork session. Do not dispatch a fresh subagent (general-purpose Agent, Task, etc.) to run the audit unless the user has explicitly asked for that. Cowork’s permission allowlist is per-context: a freshly-spawned subagent has its own list, so the first call of every MCP tool inside the subagent prompts the user again — Clio, Asana, Outlook, the SharePoint mount, bash, all of them. Across one audit that’s ~8 prompts; across three subagent-dispatched audits in a row it’s ~25 prompts. The skill’s “fire openers in one turn” discipline reduces within-context clustering but does nothing about cross-context re-priming.

Step 1 — Confirm the matter type and identify variant

If the matter number is given, look it up first with Clio:get_matter_summary (use display_number). The practice_area field is a hint, not a fact — use it as the starting point but verify against file state once you’ve done Step 3 (folder discovery). Initial variant selection from practice_area:

• “Real Estate – Residential Purchase” → load references/purchase.md
• “Real Estate – Residential Sale” → load references/sale.md
• “Real Estate – Residential Refinance – *” → load references/refinance.md
• **Form A Transfer in EFS & Affidavits/ or LTSA Documents/ on a refi** → load combined refi+transfer overlay (in references/refinance.md) regardless of whether practice_area says “Borrower Only” or “Borrower and Lender.” Common pattern: spousal-add, spousal-remove (separation), parent-transfer, related-party transfer. Practice_area is often set at intake before this dimension is known.
• **AZ-drafted Promissory Note + Schedule to Mortgage + Lender Consent in Lender Documents/ on a “Refinance – Borrower Only” file** → private mortgage placement misclassified at intake. AZ is drafting both sides; LSBC Rule 3-100 joint-rep considerations apply. See refinance.md sub-type (e) private placement.
• CPS Section 4 contains “Estimated” + “Outside Date” rather than a fixed date, OR seller is a numbered company / LP, OR property identifier is “SL N / EPSN” rather than registered PID, OR deposits are payable to vendor’s solicitor → presale / new construction file. ALSO load references/purchase-presale.md. Presales have a vendor-notice-driven completion mechanic that the standard phase model doesn’t fit.

Step 2 — Opening volley: fire every read-only call in ONE turn

Permission-prompt discipline. Each MCP tool prompts the user the first time it’s invoked in a session. Cluster all the opening reads into a single parallel tool-call block so the user sees one approval flurry, not three spread across the workflow. Spread-out approvals are the main reason this skill feels slow in practice.

1. Clio:get_matter_summary(display_number=...) — financials, trust, key dates, attorneys, last activity.
2. [example with matter details removed]
3. **The directory-mount tool with path="C:\Arora Zbar\AroraZbar"** (named request_cowork_directory in Cowork, request_directory in Claude Code desktop — locate it by searching available tools for “directory”, never assume the exact name) — mounts the entire firm SharePoint root in one go. This covers both Client Matters - Documents\ (open matters) and Vault - Documents\SP Vault\ (closed matters), so the Step 3 cascade and all subsequent Glob/Read calls run inside an already-approved mount. Critical: mount once, up front, before the cascade — not per-matter, after. The mount persists for the session, so subsequent audits in the same session prompt zero times for filesystem access. This path is the common firm sync root, not a guarantee for every machine. If the mount tool errors, denies access, or reports the path doesn’t exist, don’t retry it or treat it as a transient failure — record once that the local mount is unavailable/mismatched on this machine, and go straight to the SharePoint-search path in Step 3 (execution-order steps 6-7) for the rest of this session instead of running the local-Glob steps 1-5 first every time.
4. Microsoft 365:outlook_email_search(mailboxOwnerEmail="[email]", query="<display_number>", limit=25) — seeds the admin@ inbox sweep with the matter-number anchor.
5. Microsoft 365:outlook_email_search(mailboxOwnerEmail="<current user email>", query="<display_number>", limit=25) — seeds the user’s personal mailbox sweep with the same anchor. The current user’s email is in the env block (userEmail). Skip this call if the current user IS admin@arorazbar.
6. Clio:get_matter_trust_balances(client_id=...) — lazy-evaluate per the rubric below. Don’t fire a tool just because the workflow lists it; fire it when its output would actually change an output line.

Step 2.5 — Determine the phase

On forward-motion mode files, the completion date used here should come from the four-source triangulation in Step 2.8 below. If the four sources agree, that’s your completion_date. If they diverge, use the document of record (CPS Section 4 + latest signed Date Change Addendum for purchase/sale; latest signed Date of Advance amendment for refi) as the working date AND surface the triangulation divergence as a top-tier FLAG via Step 2.8’s output. Practically: run Step 2.8’s triangulation first when you have the data, then come back to Step 2.5 to compute the phase against the agreed (or document-of-record) date. On post-mortem mode files (Step 2.7), the completion date is historical and phase computation is informational rather than gating.

• Phase 1: Onboarding — matter open through ~Day -30
• Phase 2: Conveyancing — Day -30 to Day -10
• Phase 3: Pre-close push — Day -10 to Day 0
• Phase 4: Closing day + 1 week — Day 0 to Day +7
• Phase 5: Post-close tail — Day +7 onward
• [example with matter details removed]

Step 2.6 — Compare Clio activity against the variant’s cadence baseline

The Clio matter summary gives wip_hours, wip_amount, oldest_wip_date, and last_activity_date. Compare these against the variant reference’s “Workflow signals that indicate cadence is on track” / “cadence is off” lists. The recurring patterns to watch:

• Phase 1 conveyancer baseline. On purchases and sales, the conveyancer has a heavy Day +1 from open (~3h reviewing CPS, ordering strata, pulling title) per the variant references. A purchase or sale file that’s >5 days old with wip_hours = 0 and no time entries logged is a workflow-off signal — the conveyancer hasn’t started.
• Phase 1 lawyer baseline. an associate lawyer/Eli substantive review entries typically appear Day +1 to +6. A file >7 days old with zero lawyer time entries means the contract review hasn’t happened — surface as a Phase 1 FLAG (not buried in admin hygiene).
• Day 0 bill issuance. On all variants, the bill should be assembled and issued Day 0 to Day +1 from completion/funding. A Day +2 audit with no bill is a Phase 4 cadence FLAG.
• Hours-vs-amount math impossible — e.g. wip_hours: 4 against wip_amount: 17 (no realistic hourly rate produces ＄17 from 4 hours). Typically means a fee-correction or write-off was recorded as the latest entry and wip_amount reflects only that, while wip_hours reflects gross.
• Amount-too-low for phase — e.g. wip_amount: 268.05 over 95 days on a mid-Phase 2 file where the conveyancer’s standard 3h Day +1 + an associate lawyer’s 1-2h substantive review should put the file at 4-5h ≈ ＄1,000-＄1,500. Means time wasn’t entered.

Step 2.7 — Pick the audit mode: forward-motion or post-mortem

The phase model (Phase 1–5 with ramps) assumes the file is progressing toward a future completion. Many files don’t fit that frame: cancelled deals, files sitting past a passed completion date, files predating the firm’s current systems. The audit’s first decision is which mode applies — the rest of the workflow follows from that.

• The matter has a completion / funding date that is in the future, OR within the last ~10 days, AND
• There are signals of active progression (recent file mtimes, recent Clio time entries, open Asana tasks with near-due dates, recent inbox correspondence)
• Clio.status == 'Closed'
• Completion date is more than ~14 days past AND there is no recent activity (Clio last_activity > 14 days, no recent Asana task closures, no recent inbox)
• Explicit cancellation signals: FCT cancellation email on file, insurance cancellation pre-funding, batch task close on Asana with no closing-day correspondence, client went silent and was not chased back
• Matter opened before the firm’s current Asana template was deployed (signal: zero Zapier-generated template tasks on the project, only manual tasks) — file is not stale, just predates the current systems

Step 2.8 — Completion-date triangulation across four sources

Run on EVERY forward-motion mode audit (purchase, sale, or refinance). Post-mortem mode skips this check — the completion date is historical at that point and divergence in stored records is a separate post-mortem cleanup item, not a closing-blocker.

1. Document of record — variant-specific:
2. Asana parent matter task — the <display_number>: <description> task. Pull due_on from Asana:get_tasks. The parent task is typically multi-homed in the CLOSING DAY TASKS portfolio; both copies should carry the same due_on.
3. Calendar invites in admin@arorazbar inbox — search for “Accepted: Closing Day – <display_number>” or “Closing Day – <surname>” subject patterns. Multiple invites with different dates indicate the calendar was bumped; the most recent invite is the working assumption inside the firm.
4. Most recent client / counterparty correspondence referencing a date — the last thread in the matter inbox sweep that mentions a specific completion / funding / closing date. Often a lender confirmation, a buyer’s-solicitor coordination email, or a the intake and closings assistant signing-appointment booking.
5. “Document of record (CPS / lender instructions): <date>“
6. “Asana parent task: <date>“

Step 3 — Walk the matter’s SharePoint folder file by file

Folder location is a search problem, not a sequential cascade. Folders for Arora Zbar matters live in any of five libraries, with non-deterministic naming. There’s no formula that tells you in advance which library a given matter is in or what its folder is named. The skill’s job is to fan out wide enough that real files are reliably found, and to stop honestly when they aren’t.

1. C:\Arora Zbar\AroraZbar\Client Matters - Documents\ — active matters, the primary library
2. C:\Arora Zbar\AroraZbar\Vault - Documents\SP Vault\ — closed matters that have been migrated to the current Vault
3. Alternate SharePoint sites (e.g. sites/Clio/Shared Documents/) — the firm’s legacy Clio document library, pre-Vault migration. Reachable only via Microsoft 365:sharepoint_search.
4. SharePoint Online not locally synced — some Vault folders live in SharePoint Online but are not on the local mount at all. Reachable only via Microsoft 365:sharepoint_search.
5. Pre-DMS legacy paths — files that predate the firm’s current document management. Old Asana task notes sometimes reference paths like C:\Users\<old-user>\AroraZbar\Clio - Documents\<Surname>\ (old workstation accounts that no longer exist on current machines). These are not reachable from a current session.
6. ***<surname>* with leading and trailing wildcards** (e.g. *Homer Simpson*) — most reliable against a single-library root

The Haiku extractors — bonus path for inline Code sessions only

The skill ships three Haiku-based extractor scripts (extractors/cps.py, extractors/lender_instructions.py, extractors/trust_reconciliation.py). They take PDF text in (via --pdf <path> or --stdin), call Haiku with a typed JSON schema, and return structured facts. The orchestrator never sees the document body; it reads the JSON struct and decides what to flag.

• ANTHROPIC_API_KEY is set in the bash sandbox environment
• Bash itself is available (denied in subagent context; sometimes denied in Cowork)
• Python can install pypdf and anthropic on first run
• Completion date in CPS Section 4 vs Clio key dates vs Asana parent-task due date
• PID + legal description consistency across CPS, title search, Form A
• Mortgagor names on Form B match title (post-transfer)

Step 3.5 — Sweep BOTH the admin@arorazbar inbox AND the current user’s mailbox

The audit covers two mailboxes:

1. **[email]** — the shared firm inbox where intake, signing-platform notifications, and most client-facing threads land
2. The current user’s mailbox — extracted from the session context (e.g. [email] when Eli runs the skill, [email] when an associate lawyer does). Look up userEmail from the env block at the top of the system prompt. If the current user is admin@arorazbar, run only the shared sweep and label accordingly.
3. Civic address — full street number AND name (e.g. 2222 Edgemont, not Edgemont). Sharpest anchor on the shared inbox.
4. [example with matter details removed]
5. Named counterparty law firm or lender (e.g. Marge Simpson Law, Lisa Simpson, Vancity [account]) — narrow third for tied-in transactions.
6. Client surname (e.g. Bart Simpson) — last resort, expect overflow. Surname queries on admin@ regularly overflow the token budget (50–72K char spills) on any surname that’s also an active corporate-client name, shared across multiple matters, or short enough to false-positive. Run only if (1)–(3) clearly missed material. If the surname overflows, accept that admin@ surname coverage is partial; the matter-number and civic-address anchors are normally sufficient.

Step 4 — List every Asana task with status

Open and Closed tasks get one line each. Template / N-A tasks get ONE collapsed summary line for the whole group. The earlier rule of “every task gets a line including templates” produced 18 lines of (template, fires Phase 5) on Phase 1 presale audits — that’s noise pretending to be coverage. The new contract:

• Open — every open task that has a fired predicate (i.e. is actually waiting on a human). Sort by due date ascending. Format: "<task name>" · <assignee> · due <YYYY-MM-DD> — open · [Asana](<permalink_url>). Each line links to its specific task.
• Closed — every closed task. Sort by due date ascending. Format: "<task name>" · <assignee> · due <YYYY-MM-DD> — closed <YYYY-MM-DD> · [Asana](<permalink_url>). Each line links to its specific task. (Closed tasks are listed because the lawyer wants to see what’s been done; this is the audit trail of the conveyancer’s progress.)
• Template / N-A — ONE collapsed summary line with a count, brief description of the categories (“60-day discharge, STC order, Law Society Report, strata holdback creation, etc.”), and a link to the Asana project view. Format: Template / N-A ({T} tasks): {one-phrase summary of categories present} — fire when their predicates trigger, none actionable now. [Asana project]({url}).
• open — assigned, not yet completed, predicate has fired or task is unconditional
• closed <YYYY-MM-DD> — completed; date is completed_at (lossy as a cadence signal — see below)
• (template, fires Phase {n}) — Zapier-generated task whose predicate fires at a later phase (e.g. “60 days after… ensure mortgage discharged” — fires post-funding regardless of fact pattern)

Step 5 — Compose the output

Eye-flow: header line → Snapshot → Files (every file, by subfolder) → Inbox (every material thread, by mailbox) → Asana (every task, by status group) → ⚠ Issues (severity-ordered rollup of FLAGs) → Trust flag (if any) → Sources.

1. Document errors (wrong PID, SOA math, mismatched Order to Pay vs SOA, unsigned where signed required) — these block closing
2. Phase-appropriate missing items (per variant phase model — only flag if expected at current phase)
3. LSBC compliance gaps (Rule 3-100 / 3-102, joint-rep consent, ILA where required)
4. Lender-specific buried diligence (specific instructions page 2–4 items)
5. Coordination gaps (out-of-province counsel, tied-in transactions, unsent client comms within 48h SLA)
6. Admin/billing hygiene (WIP=＄0, AR aging, missing time entries, last-activity gaps, stale Asana tasks needing cleanup)

Common document errors to catch

These come up file after file. Always look for them:

1. Buyer/Seller SOA math errors. Cross-reference the mortgage proceeds line against the lender commitment letter and the Lender Order to Pay. A common pattern is a draft SOA showing a placeholder mortgage amount (＄300K, ＄500K) when the actual commitment is materially larger. The balance-to-complete number is then wrong by hundreds of thousands.
2. Source of funds note left blank. The SOA usually has a “source of economic activity” or “source of funds” note. If it’s blank, the Rule 3-102 declaration isn’t documented. Flag it.
3. GST certificate not ticked. For new construction (taxable) or older properties (exempt) — confirm the executed copy has the correct box ticked. New construction = GST payable by buyer.
4. PID / legal description typos. Eyeball PIDs and legal descriptions in correspondence and on the Form A. OCR artifacts on signed PDFs can show “DL 340” when the title says “DL 540” — always verify against the actual title search.
5. Engagement letter scope vs current parties. If a party was removed by addendum (e.g. spouse off title), confirm whether their engagement letter still makes sense and whether a scope amendment is appropriate.
6. BMO/lender specific instructions buried diligence. Lender instructions often have one-off items on page 2-3 — solar panel ownership, non-disturbance agreements, environmental, ALTA endorsements, special covenants. Read the instructions, not just the commitment letter.

Trust account flag — surface immediately

Per firm rules, anything touching the trust ledger, trust balances, or the firm’s BMO/TD/Vancity trust accounts surfaces immediately and requires LSBC implication confirmation before proceeding. In RE matters this typically appears as:

• Out-of-province or out-of-jurisdiction counsel requesting trust account info to wire purchase funds.
• Realtor or other firm asking where to send excess deposit.
• Lender requesting wire confirmation.
• Source-of-funds documentation tied to another trust transaction.

Delegating the document read (only when needed)

Most matter folders are small enough that direct Glob + Read after request_cowork_directory is faster than delegation. Only delegate when the folder has 100+ files or when reading large signed PDFs would blow the main context.

Variant-specific guidance

The body of this skill covers the universal workflow. For variant-specific diligence items — what’s particularly worth surfacing on a purchase vs a sale vs a refinance — read:

• references/purchase.md — lender specific instructions, GST/PTT/FTHB/NBHE math, Section 116, Section 1.04/1.05 Prohibition Act, excess deposit, FBT, occupancy permit, title insurance
• references/purchase-presale.md — presale / new-construction sub-variant: vendor-notice completion mechanic, no fixed completion date, Estimated Range + Outside Date, GST on new construction (no NHR above ＄450K), Phase 2 holding-pattern flagging
• references/sale.md — payout statement, holdbacks, Section 116, capital gains, commission flow, vendor undertakings, RTA tenanted-sale handling (Section 49 compensation, RTB-32P, security deposit return, owner-occupied warranty)
• references/refinance.md — discharge of existing charges, lender instructions, spousal consent, LOTR if title transferring

Tools this skill uses

• Clio:get_matter_summary — matter overview
• Clio:get_matters — if user named a client not a number
• Clio:get_matter_trust_balances — client-level trust roll-up across matters (a single matter’s figure comes from get_matter_summary, not this)
• Asana:search_objects(resource_type=project) — find the matter project
• Asana:get_tasks — open + completed tasks in the project
• Microsoft 365:sharepoint_folder_search — fallback only when local sync misses; the synced path under Client Matters - Documents\<Surname, *>\ discovered via the Step 3 cascade is the primary read path

What the audit does NOT do

• Does not give legal advice, take strategic positions on closing structure, or recommend whether to close.
• Does not write/modify/delete in Clio.
• Does not send anything —

Matter Document Search — Arora Zbar LLP

The firm already extracts and indexes the text of every document filed in a client matter folder. This skill queries that index for one matter instead of opening SharePoint and reading folders by hand. You give it a matter number and a description of what you’re looking for; it gives you back a ranked list with the matching sentence and a link that opens the file.

When this fires

• [example with matter details removed]
• “Are there any IDs in the Homer Simpson folder?” (resolve the matter number first — see Step 1)
• [example with matter details removed]
• “Is there a signed Form A on this file?”
• “Find the final invoice and scope from the contractor”
• The user names a matter and asks where a document is, or what a document says

Do NOT use this to answer “does this matter exist” or “who is the client” — that is the matter workspace, not a document search.

What it searches, and what it does not

Searches: every document filed in the matter’s SharePoint folder that the firm’s extractor has read — PDFs (including scanned ones run through OCR), Word documents, and their AI summaries.

• Email and email attachments. A document that only ever arrived as an attachment and was
• Matters with no SharePoint folder linked (about 1 in 10 — see Step 4).
• Anything past the first 200,000 characters of a very long document.

Step 1 — Get the matter display number

[example with matter details removed]

Step 2 — Call the endpoint

Open it with the browser tool. You are already signed in to the portal, so the request carries your own permissions — if you cannot open that matter in the portal, this returns 403 and that is correct, not a bug to work around.

Response shape

Step 3 — Report the results

Lead with the answer in one plain sentence, then the evidence. One line per document:

• Always give the link. The point of the skill is that the user does not go looking.
• Quote the snippet, don’t paraphrase it. The user is deciding whether to open the file.
• Say when a hit is filename-only (has_extracted_text: false) — the body was never searched,
• Do not claim a document is “the” one the user asked for unless the snippet actually says so.

Step 4 — When it comes back empty

An empty result is a real answer, but only after you say which of these it is:

1. The document is not filed in the matter folder. Most likely it is an email attachment.
2. The matter has no folder linked. folder_path is null. about one matter in ten
3. The matter number was wrong. A 404 means no matter carries that display number; a 409 means
4. The wording missed. Try the user’s terms again with synonyms — the ranking is lexical, so

How the ranking works — and its one real limit

Ranking is Postgres full-text over the filename and the AI summary, plus trigram matching on the filename, normalized by document length so a 100-page contract does not outrank a two-page letter just by repeating a common word. A document whose body contains one of your words gets a bonus on top, and body_hit on each row tells you whether that fired.

Scan Organizer — Arora Zbar LLP

Read newly scanned PDFs, propose firm-convention names and destinations, and (with user approval) execute the moves. Firm rules live in the How-to Guide’s File Naming Conventions task (Asana [id]).

How it works — where the files live

Prefer the M365/SharePoint connector. It carries the user’s own auth and works on every machine. Search available tools for “sharepoint folder” or “sharepoint search” (e.g. sharepoint_folder_search) and query the Vault site’s Shared Documents library (current/primary) or the Clio site’s (legacy, pre-Vault migration). Do not search for a library named “Client Matters – Documents” — that’s a local OneDrive sync-folder display name, not a SharePoint library, and it returns zero results.

• Reading Filesystem:read_file on the local path reads the synced copy instantly
• Moving via Filesystem:move_file on the local path gets propagated to SharePoint by OneDrive within ~30–60 seconds
• User’s machine (Windows) — Filesystem:* tools, where the real files live
• Claude’s container (Linux) — bash, view, with pdftotext/pdftoppm/tesseract available for rasterization when needed. Use Filesystem:copy_file_user_to_claude to pull a disposable copy for processing.

Workflow — 8 steps, do not skip the approval gate

1. Confirm the matter

Ask for display number (e.g. “1234-2”) or client + matter description. Resolve to Clio ID, client folder name (client name, NOT display number), billing attorney, practice area. The matter folder is {Client Name}\{Display Number} {Description}\ — under the Vault site’s Shared Documents library on the connector, or under the sync root the user confirmed. Build the full path from that confirmed root; never assemble one from a drive letter this skill supplied.

2. Locate the scans

Ask which folder they’re in. Filesystem:list_directory to see the files. Flag obvious batch-scan placeholders (SKM_..., IMG_..., scan_001.pdf, Homer Simpson SCANS BATCH N.pdf).

3. Inventory the matter’s existing folders

Filesystem:directory_tree on the matter root. You need to know what subfolders already exist — every matter is slightly different (some have Financial statements/, some have Listed Documents/ with protected exhibits, etc.).

4. Read each PDF — see “Reading scans” below

5. Classify and route each scan — see “Naming”, “Routing”, and “Flags” below

If any rule says “ask the attorney”, STOP and flag it. Don’t guess.

6. Present the plan — STOP for user approval

Output this table:

7. Execute — only after approval

For each non-flagged item:

1. Filesystem:create_directory if the destination subfolder doesn’t exist yet
2. Filesystem:move_file source → destination — one at a time so per-file approval prompts fire
3. On name collision: STOP, ask the user (never overwrite)
4. Never move flagged items unless the user explicitly overrode that specific flag

8. Report what was done

Add: “OneDrive should sync these to SharePoint within ~30–60 seconds.”

Reading scans

Default: text extraction. Filesystem:read_file on the PDF usually returns extractable text for digital PDFs (letters, invoices, statements). Look for date, from/to, subject, document-type keywords (Invoice, Statement, Notice, Letter, Agreement, Transcript).

Naming

Format: yyyy-mm-dd [shorthand] [from/to] [re: subject] [- status]

• ID docs: yyyy-mm-dd {first-initial}.{last-name} ID → 2025-03-14 S.Marge Simpson ID
• Outgoing cheques: Cheque {number} (yyyy-mm-dd) {matter number} → Cheque 1234 (2026-04-15) 1234-2
• Void cheques: append void → Cheque 1234 (2026-04-15) 1234-2 void
• Deposit slips: (yyyy-mm-dd) Deposit Slip {matter number}
• Bank/account statements: yyyy-mm-dd statement (or e-statement if electronic)
• Date-range batches (e.g. a week of invoices from one vendor): yyyy-mm-dd - yyyy-mm-dd Vendor Invoices

Routing

Matter path: Client Matters - Documents/{Client Name}/{Display Number} {Description}/. Decision tree — stop at first match:

• Conveyance (RE-Purchase/Sale/Refi): no Pleadings/Transcripts — use Closing/, Title/, Mortgage/, Instructions/, Holdback/. Client scans (ID, pay stubs, bare trust) go to Instructions/Client Documents/.
• Corporate (Incorporation/Corporate/Solicitor): uses Minute Book/, Resolutions/, Filings/, Agreements/, Appara/.

Flags

Any flagged item does NOT get moved in Step 7 unless the user explicitly overrides it for that specific file.

🛑 Hard stops — need attorney sign-off

• Trial exhibit prefix (K, D, E, O, P + digit): the letter maps to a brief/discovery list — renaming breaks cross-references. Flag 🛑 Trial exhibit.
• Privileged material (solicitor–client comms, work product, litigation-privileged): flag 🛑 Privileged — goes to Privileged/ or Research/, never mixed into Documents/ (waives privilege).
• Opposing counsel correspondence: flag 🛑 Opposing counsel — may need logging, a response deadline, or disclosure handling.
• Without-prejudice / settlement: flag 🛑 Without prejudice — may need separate folder.

⚠️ Soft flags — proceed with care

• Date unreadable: [date needed] placeholder, flag ⚠️ Date needed. Do not move until user fills it in.
• Type unclear: flag ⚠️ Type unclear — don’t guess.
• Possible duplicate: flag ⚠️ Duplicate? — move_file won’t overwrite anyway; suggest Better Quality/ subfolder if it’s a cleaner scan.
• Multi-document PDF: flag ⚠️ Split needed — propose the split in prose, don’t try to rename a bundle.
• Cross-matter relevance: flag ⚠️ May belong to [other DN] — don’t silently re-route.

🔒 Privacy flags — NEVER proceed without attorney approval

• Staff personal info: flag 🔒 Staff personal info — don’t file, return to user.
• Wrong client’s material: flag 🔒 Wrong client — stop immediately, this is a professional responsibility issue.

Override policy: for 🛑 flags, require an explicit override phrase from the user (“yes, rename K8 even though it’s a trial exhibit”). For 🔒 flags, do NOT proceed regardless — direct the user to the billing attorney or Eli.

Output format — mandatory

Every plan (Step 6) includes:

1. Confidence tag (✅/⚠️/❓)
2. One-line summary (“12 scans read, 10 ready, 2 flagged for the litigation partner”)
3. Rename-and-move table
4. Batch summary (counts, patterns, folder creation suggestions)
5. Flagged items — expanded separately so they stand out
6. Explicit approval ask

Examples

Example 1 — Clean batch, full execution

User: “Scanned 5 docs for 1234-2 in Documents/Our client/New Documents provided by client/. File them properly.”

1. Resolves 1234-2 → Lisa Simpson Singh, Lit-Defendant, the litigation partner
2. Filesystem:list_directory on the path → sees scan_001.pdf through scan_005.pdf
3. Filesystem:directory_tree on matter root → confirms Financial statements/, Miscellaneous/, IDs/ exist
4. Reads each: scan_001 = Fortis letter (text extract), scan_002 = CIBC statement (text), scan_003 = image-only → rasterize → City of Langley bylaw letter, scan_004 = Bart Simpson Sheret invoices, scan_005 = BC licence

Example 2 — Trial-exhibit hard stop

User: “3 scans for 1234-2, rename please.”

Example 3 — Not enough information

User: “File these for Ned Flanders.”

1. [example with matter details removed]
2. Where are the scans? (SharePoint folder, or the path under your matter-documents sync root)
3. Source? (Client / mail / discovery)
4. Any trial exhibits in the batch?

Safety summary

1. Never execute Step 7 without explicit approval at Step 6
2. Never touch exhibit-prefixed files (K/D/E/O/P + digit) without attorney sign-off
3. Never overwrite — move_file fails on collision, stop and ask
4. Never invent a date — use [date needed] and flag
5. Never invent content — “Unknown, user to review” is valid
6. Never cross-file — if content belongs to a different matter, STOP

ScanSnap Cheque Rename — Arora Zbar LLP

Rename freshly scanned cheque PDFs to firm convention, optionally reorder pages so the cheque front is page 1, and produce the standard deposit announcement for #Communications. Cheques are trust-adjacent records — every action in this skill is conservative-by-default.

Hard rules — read these first

1. **NEVER write binary PDF content via write_file.** It is text-only and will silently corrupt the file. For binary outputs (reordered PDFs), use present_files with a download link. Renames/moves use move_file and are safe.
2. NEVER test write/edit operations on a live cheque PDF. Always test on /home/claude/test.pdf or another throwaway path first. A corrupted trust cheque is a Law Society reportable problem.
3. READ EVERY candidate file before answering “I found N cheques.” Garbled / mojibake filenames from ScanSnap are common (e.g. 04302026_!T''.fas4 _. 5. •__a-L- .ter Arora Zbar LLP BANK OF MON.pdf is a real cheque). Never silently drop unreadable filenames or pad the count with files that don’t fit the criteria.
4. DISTINGUISH trust draws from general account payments. A cheque drawn on BMO General payable to a third party is NOT a trust cheque to Arora Zbar, even if it sits in the same folder. The two flows have completely different reporting needs.
5. CONFIRM before any move/rename on disk. Even non-destructive operations need an explicit “yes” — staff may have batched files for a different reason.

File access

Prefer the M365 connector to reach the ScanSnap folder. It carries the user’s own auth and works on every machine. Microsoft 365:read_resource on the OneDrive item URI works for metadata, but the underlying scans are image-only PDFs, so M365 returns empty content — use it to locate and confirm the folder, then pull the bytes another way for OCR.

Workflow — 6 steps, do not skip the approval gate

1. Inventory the folder

Filesystem:list_directory on the ScanSnap folder. Identify every cheque-candidate file. Cheque candidates include any file whose name suggests a cheque (BMO, Bank of Montreal, Vancity, TD, “cheque”, “Arora Zbar LLP”, or a 4-digit number that looks like a cheque number) AND any file whose name is garbled / mojibake. Mojibake filenames are NOT exempt — they are usually scanned cheques whose ScanSnap auto-naming failed.

2. OCR every candidate

ScanSnap cheques are image-only PDFs with no embedded text. Run OCR on every candidate:

3. Extract structured fields per cheque

For each cheque, capture:

4. Categorize each cheque

If the user asks “find the N cheques to Arora Zbar today”, they almost always mean Trust draws specifically.

5. Propose renames and (optional) page reorder — STOP for approval

Naming format for ScanSnap-deposit cheques: Cheque {number} {yyyy-mm-dd} {matter}.pdf

• [example with matter details removed]
• [example with matter details removed]

6. Execute — only after approval

Renames (always safe):

1. Work in /home/claude/cheques/ on the disposable copy — NEVER on the original on the user’s disk.
2. Use pypdf to swap page order:
3. Move the reordered file into /mnt/user-data/outputs/ and call present_files with the path. The user downloads the result and drops it into ScanSnap to overwrite the renamed (still back-first) version.
4. **Never attempt to write the reordered binary back via Filesystem:write_file. It corrupts the file.**

Format for #Communications Teams post

the intake coordinator’s verified convention (one line per cheque, plain text):

Output format — mandatory

Every plan (Step 5) includes:

1. Confidence tag (✅ / ⚠️ / ❓)
2. One-line summary (e.g. “4 cheques in folder, 3 trust draws to AZ totaling $7,356.99, 1 general-account payment to third party”)
3. Rename plan table
4. Categorization breakdown (trust draws vs other)
5. Flagged items (mojibake reads, missing fields, unusual payees)
6. The the intake coordinator-format Teams post, ready to copy

Common failure modes — and how to avoid them

LSBC compliance note

Trust account work is regulated under LSBC Rule 3-58 (deposits) and 3-65 (record-keeping). This skill handles the file-level naming and page order only — it does NOT touch the Clio trust ledger or move money. If the user’s request implies a trust-ledger entry, transfer, or reconciliation, surface that as a separate task and confirm with the lawyer of record before proceeding. Never assume “rename the cheques” implies “and post the trust transfer in Clio.”

What this skill explicitly does NOT do

• Post to Clio trust ledger (use the Clio MCP server, with confirmation, in a separate task)
• Run the DepositEdge upload (manual; staff handles)
• Write the Teams post into the channel (drafts only — staff hits send)
• Reconcile against the bank statement (separate workflow)
• Handle incoming cheques to the firm (separate deposit-slip workflow)
• Handle staff-personal or wrong-client cheques (return to user, do not file)

Teams Triage

Search a staff member’s Teams chats, separate what they’re waiting on from what they owe a reply on, and produce a landscape .docx action list with the resolved items filtered out.

Inputs

• Whose chats: the current user, unless they name someone else’s mailbox to triage on their

  behalf (e.g. covering for someone out of office).

• Which colleague(s): infer from the request — e.g. “triage my Teams chats with Homer Simpson and
• Lookback window: default to roughly the last 4 months of activity when categorizing items

Step 1 — Search Teams messages

Use Microsoft 365:chat_message_search with targeted, single-keyword queries. Do not use broad date-range searches or high limit values — they time out, and the connector hard-caps limit at 25 anyway. Run 8-12 short keyword searches (limit: 10-15 each), pacing them in small batches of 2-3 with a brief pause between batches rather than firing all at once — Graph throttles burst searches. If a search returns a 429/throttling error, retry it once after a short pause; if the retry also 429s, note that keyword as “skipped (throttled)” in the output and continue — never block the whole triage on one query:

• If colleague names were given, include each name as its own query term.
• Cover common topic keywords relevant to the user’s practice area/role (e.g. matter-type terms,
• Collect every unique chat ID returned across all searches — that’s the working set for Step 2.

Step 2 — Read full chat threads

For each unique chat ID from Step 1, use Microsoft 365:read_resource to pull the full thread — not just the matched messages. If a call times out, retry once; if it still fails, note that chat as “could not read” and continue with the rest.

Step 3 — Categorise items

Sort every substantive item raised in the last ~4 months into exactly one section:

• Section A — Waiting on Others: the user asked someone to do something, or is waiting on a
• Section B — User Action Items: someone asked the user to do something, and the user hasn’t
• Section C — Resolved: an item that was raised and has since been answered, completed, or is

Step 4 — Create the Word document

Use the docx skill’s tooling (via the anthropic-skills docx npm-package helper) to build the file. Exact spec — keep byte-for-byte, this formatting was hard-won:

• Landscape orientation, 0.75″ margins.
• Title: Teams Triage — Action Items (Month DD YYYY) (use today’s date).
• One table, 7 columns: #, Subject/Matter, Details, Sender, Date, Status, Notes.
• Column widths in DXA: [400, 1300, 3000, 1000, 800, 800, 2060] (total 9360).
• Header row: navy fill 1F3864, white bold text.
• Section A rows: yellow fill FFF2CC.

Step 5 — Validate and save

Validate the generated file with the bundled docx skill’s scripts/office/validate.py before presenting it. Save to the triaged user’s project folder (ask where, if it isn’t obvious from context — do not guess a SharePoint path).

Tools this skill uses

• Microsoft 365:chat_message_search — short single-keyword searches to discover chat IDs
• Microsoft 365:read_resource — full-thread reads to catch short replies search would miss
• the bundled docx skill / scripts/office/validate.py — document generation and validation

Time Entry Gap Check — Arora Zbar LLP

Cross-reference a timekeeper’s Clio time entries for their previous workday against everything else they actually did that day — calendar, sent email, Teams, completed Asana tasks — and surface activity that has no corresponding entry against the right matter. Clio is READ-ONLY for this skill; never write, update, or delete a Clio record. The output is a gap list the timekeeper reviews and enters manually.

Output format — keep it tight

No preamble, no trailing summary. Structure:

0. Resolve who and when

Target timekeeper — default to the current session user. If the requester names someone else (“check yesterday’s time entries for Priya”), that named person is the target instead — this is the supervising-partner path, allowed for anyone the requester manages.

• If the Clio connector exposes a current-user / who-am-i style lookup and the target is the
• Otherwise look the target up by name via the Clio users list/search tool available in the
• If Clio can’t resolve the name unambiguously, ask once for the person’s Clio user ID or
• If today is Monday, “yesterday” = the previous Friday (skip the weekend).
• Otherwise yesterday = today minus 1 calendar day.
• Use the yesterday-00:00 → today-00:00 Pacific window consistently across every source below.

1. Pull Clio time entries for that day

Clio:get_activities with user_id=<resolved id>, start_date=<yesterday>, end_date=<yesterday>, type="TimeEntry", limit=100. Note total hours and which matter numbers were billed against — this is the baseline everything else gets checked against.

2. Pull calendar events

Microsoft 365:outlook_calendar_search with query="*", afterDateTime=<yesterday>T00:00:00, beforeDateTime=<today>T00:00:00, limit=25, paginated per the contract above. Ignore all-day deadline reminders unless there’s independent evidence the timekeeper did substantive work on them that day.

3. Pull sent email

Microsoft 365:outlook_email_search with folderName="Sent Items", the same date window, limit=25, paginated per the contract above — sent mail is the highest-volume source in this check and the one most likely to run past a single page.

4. Pull Teams messages

Microsoft 365:chat_message_search with sender=<target's email>, the same date window, limit=25, paginated per the contract above. Focus on substantive messages — matter work, client instructions, task coordination. Ignore casual/social chatter.

5. Pull completed Asana tasks

Asana:search_tasks with assignee_any=<target>, completed_at_after/completed_at_before set to the yesterday window, opt_fields="name,projects,completed_at", limit=100.

6. Cross-reference — this is the hard part, keep it exact

[example with matter details removed] email subjects, Asana project names, calendar event titles, or Teams channel/chat names.

• Match each item from steps 2–5 to a Clio time entry on the same matter for that day.
• Cluster related Teams messages on the same matter into one potential gap, not one gap
• **If an event/email/message plausibly falls within an existing time entry’s scope, don’t
• A gap is: substantive activity on a matter with zero time entries against that matter that

7. Output

Total Clio hours logged yesterday, then the bulleted gap list per the format above. If truly nothing is missing, say so plainly — don’t manufacture a gap to look thorough.

Constraints

• Clio is READ-ONLY. Never call a Clio write/update/delete tool from this skill, including

  to create the missing entries — draft them for the human to enter.

• Privileged client work. Don’t surface client identifiers outside firm context; matter
• Canadian English spelling in all output.
• **Microsoft 365 limit is hard-capped at 25 by the connector.** Requesting more returns a
• No skill-review debrief in the output — that only belongs in skill-development

Tools this skill uses

• Clio:get_activities — the day’s time entries (read-only baseline)
• Microsoft 365:outlook_calendar_search — calendar events attended/organized
• Microsoft 365:outlook_email_search — sent mail, paginated to the contract’s ceiling
• Microsoft 365:chat_message_search — Teams messages, filtered to substantive content
• Asana:search_tasks — tasks completed that day

Draft Disengagement / Non-Engagement Email — Arora Zbar LLP

Produces a sending-ready draft for one of two scenarios:

• Disengagement — an active client (file open in Clio) has stopped responding and the firm needs to withdraw on reasonable notice.
• Non-engagement — a prospect engaged in initial discussions but never retained the firm, and we need to close the loop and limit exposure.

When this skill fires

Staff rarely use the word “disengagement.” Fire this skill on any of:

• “Write a withdrawal letter for [matter/client]”
• “We need to drop [client] — can you draft the email?”
• “Client has been ghosting us. Draft the closing email.”
• “Write a non-engagement for that prospect who went silent”
• “Close the loop email for [person]”
• “End the retainer — draft the letter”

The workflow

Step 1 — Pull the file facts from Clio

Everything downstream depends on getting the right matter data, so do this first. Call in this order:

1. **Clio:get_matters(query=...)** — search by client surname, matter keyword, or display number. If the user gave a file number, search for it directly.
2. **Clio:get_matter(display_number=...)** on the hit — confirms full detail: display_number, client_name, description, practice_area, responsible_attorney, open_date.
3. **Clio:get_activities(matter_id=...)** — time entries and disbursements. Pass matter_id only; do not pass start_date + end_date together (that combination silently returns junk historical data).
4. **Clio:get_bills(matter_id=...)** — any issued bills. Note any awaiting_payment status.
5. **Clio:get_payments(matter_id=...)** — payments received (retainer deposits, trust top-ups).

Step 2 — Classify the situation

Step 3 — Draft using the house style

Eli’s style is compact and decisive. A few principles apply across every letter:

Step 4 — Use Eli’s letter structure

Opening paragraph:

1. Our work will stop. We will take no further substantive steps on your behalf after the Effective Date. Given the nature of [your claim against Mr./Ms. Surname / the transaction / your file], if you wish to [continue pursuing it / complete the matter], you should retain new counsel without delay.
2. Your file and property. Your file and any original documents in our possession will be made available to you or to your new counsel on request. Please contact our office to arrange pickup or transfer. If we do not hear from you, the file will be retained in accordance with our retention policy and Law Society of BC requirements.
3. Trust funds. [Actual position, not a placeholder. Either: “We do not currently hold any funds in trust for you.” Or: “We currently hold $[amount] in our trust account in relation to your matter. After application to our final account, any balance will be refunded to you — please confirm the address to which the refund should be sent.”]
4. Final account. [Only if there are bills or time to render. Skip entirely if the file had no activity. If an unpaid bill exists: “Our account dated [date] in the amount of $[amount] remains outstanding. Payment is due [terms]. Our withdrawal does not affect your obligation to pay for services rendered to the Effective Date.”]
5. Limitation period / applicable deadlines. [Tailored to practice area — see Step 5. Always present for litigation; always present in some form for any matter with a hard deadline.]
6. Confidentiality. Our duty of confidentiality continues after we cease to act. Information you shared with us in the course of the retainer will remain confidential.

Step 5 — Tailor the deadline paragraph to the practice area

This is the single most important paragraph for LSBC exposure. Generic wording is not enough — name the concrete risk.

• Plaintiff litigation — Limitation Act (British Columbia), 2-year default from discovery. If a NOCC is not yet filed, this is urgent. If the expiry date is known, state it explicitly: “the limitation period may expire on or about [date].” Risk: “your right to sue may be permanently lost.”
• Defendant litigation — response-to-pleading deadlines (21 days for Response to Civil Claim under the Supreme Court Civil Rules), discovery obligations, any scheduled dates. Risk: “default judgment may be entered against you.”
• Conveyancing / real estate — closing date or completion date. Risk: “deposit may be forfeited and the other party may sue for damages or specific performance.”
• Corporate maintenance — annual filing deadlines (BC Registries), tax filings, AGM deadlines. Risk: “the company may be struck from the register.”
• Estates — usually less deadline-critical, but flag probate timing if a grant application is active.

Step 6 — Present the draft, then flag what needs user confirmation

Present the draft (use the message_compose_v1 tool with kind: email so the user can open it directly in their mail client). Then list the items that still need user sign-off before sending:

• Signatory — default is the responsible attorney from Clio, but surface this explicitly.
• Retainer status — especially if there’s no Clio activity or payments, ask the user to confirm a retainer agreement was actually signed. If not, rework as non-engagement.
• Communication log — confirm there is an evidentiary record of attempts. No record = the letter is vulnerable under 3.7-1.
• Specific deadlines — if the user knows a concrete date (limitation expiry, closing date, hearing date), paste it into the limitation/deadline paragraph.
• Opposing party name — double-check the name is correct everywhere it appears.
• Trust balance — verify against accounting if non-zero. Known Clio quirk: get_trust_balances silently ignores date filters and returns oldest-first from late 2020, so if the payment history alone doesn’t clarify, the user should check the trust balance directly in Clio (Accounts → [Account Name]) rather than relying on a tool query.

Non-engagement variation (when there’s no Clio matter)

Same principles, shorter letter. Structure:

Reference exemplar — Homer Simpson v. Marge Simpson (disengagement, minimal-activity file)

[example with matter details removed]

• No “final account” section — nothing had been billed, so the section was omitted rather than stubbed as “we do not propose to render a final account.”
• No court record section — no NOCC filed.
• Opposing party named in sections 1 and 4.
• Limitation is section 4, not section 5 — the “final account” slot was removed and everything renumbered.
• 4-day effective window, reflecting no work and no prejudice from quick withdrawal.
• Referential communication log (“numerous emails shown below”), because the email is sent as a reply in an existing thread.

LSBC compliance anchors

The letter satisfies the BC Code duties on withdrawal when each of these is addressed somewhere in the body:

• BC Code 3.7-1 (reasonable notice for good cause) — the Effective Date and response window.
• BC Code 3.7-7 (avoid prejudice, cooperate with successor counsel) — the limitation/deadline paragraph and the file-and-property paragraph.
• BC Code 3.7-8(a) (written notification) — the letter itself.
• BC Code 3.7-8(b) (deliver papers and property) — the file-and-property paragraph.
• BC Code 3.7-8(d)–(e) (account for funds, refund unearned retainer) — the trust funds paragraph (and final account paragraph when applicable).
• BC Code 3.7-9 (continuing confidentiality) — the confidentiality paragraph.

Email Polish — Arora Zbar LLP

Rewrites a staff-drafted client email in the firm’s voice. The draft the staff member wrote is the source of truth for facts; this skill only changes words.

The house style — one definition, already written

Eli Zbar’s voice is defined in disengagement-email under “Step 3 — Draft using the house style”. Read that section and apply it; do not invent a second voice definition. The four principles that carry over to ordinary correspondence:

1. No bracketed placeholders left in the body. If a fact is missing, it does not get a [bracket] in the polished draft — it goes in the “You still need to supply” list at the bottom, and the sentence is written around the gap or left out.
2. Only the sections that apply. Cut anything the facts do not support. A shorter letter that says the true thing beats a complete-looking one that hedges.
3. Name the party and the thing explicitly. “the sale of 104 – 3023 W 4th Avenue, Vancouver”, not “your matter”. “your completed client intake form”, not “the outstanding documentation”.
4. Compact and decisive. Business prose. No “I hope this email finds you well”, no “please do not hesitate”, no “at your earliest convenience”.
5. One ask, stated once, with a date. Most staff drafts bury the request. Put what the client must do, and by when, in its own short paragraph. If the draft did not contain a date, do not invent one — see the hard rules.
6. Plain words over legal register. The recipient is a client, not a court. “we still need your intake form” beats “we have not yet been in receipt of the aforementioned documentation”.

Hard rules — the whole point of the skill

The polished draft must not contain a single fact the original did not contain.

• Never invent a deadline. Not a closing date, not a “by Friday”, not a “within 7 days”. If the draft has no date and the email needs one, the polished version says “by [the date you need it]” is wrong — instead write the sentence without a date and list “a deadline for the client” under “You still need to supply”.
• Never invent an amount. No dollar figures, no balances, no fee estimates that were not in the draft.
• Never invent a commitment. Do not add “we will file this week”, “we will call you tomorrow”, or any promise about what the firm will do that the sender did not write.
• Never add a legal characterization. Do not upgrade “there may be an issue” into “you are in breach”. Do not add advice, risk warnings, or limitation-period language that was not in the draft.
• Never change a name, address, matter number, or figure that was in the draft. If one looks wrong, flag it — do not silently correct it. (Firm rule: load-bearing strings are never silently renamed.)
• Preserve every substantive point. If the draft made four requests, the polished version makes four requests. Dropping one because it read awkwardly is a defect, not concision.

Workflow

1. Read the draft and inventory the facts

Before rewriting, list to yourself: the recipient, the matter, every substantive fact, every request, every date or amount stated. That inventory is the contract — the polished version reproduces it exactly.

2. Ask at most one question, and only if the email cannot be written without it

Almost never necessary. Polish what you were given. If the sender’s intent is genuinely ambiguous between two different emails, ask one sentence.

3. Rewrite

Subject line, then body. Structure for an ordinary client email:

• One-line context — who is writing and about what file.
• The substance — what has happened, or what is outstanding.
• The ask — one paragraph, what the client does next.
• Sign-off — plain.

4. Present three blocks, in this order

The polished email — ready to send, no brackets, no commentary inside it.

Phrase replacements the firm actually needs

Homer Simpson asked directly: “i dont like timeline reminder, what can I use instead?” — so this table is part of the deliverable, not decoration. When the sender objects to a phrase, offer two or three concrete alternatives with the register named, and let them pick.

Interest & Quantum Calculation — Arora Zbar LLP

Computes interest for a period in which the principal changed, and shows the arithmetic line by line. A number without its working is not a deliverable here — the lawyer signing the letter has to be able to check every step.

The four things that must be stated every time

A bare interest figure is unusable because four choices sit behind it, and different choices give different answers on the same facts. State all four, every time, at the top of the output:

1. Principal and every change to it, each with its effective date.
2. The rate, and whether it is nominal annual, and how it converts to the period (/365, /360, /12).
3. The day-count convention — see the table below. This is the single most common source of a mismatch between two people’s numbers.
4. Payment timing — monthly in advance (paid at the beginning of the period, covering the period ahead) or in arrears (paid at the end, covering the period just finished). “Interest is paid monthly at the beginning of the month” is ambiguous on its face: it can mean in advance, or it can mean an arrears payment that lands on the 1st for the month just ended. Ask which, or state the assumption in bold and compute the other one as an alternative.

Day-count conventions

Actual/365 and monthly-rate answers differ on any month that is not 30.42 days. On a $151,500 balance at 4.9% the gap between Actual/365 and 30/360 for one 30-day month is about $8.75 — small, and exactly the size of gap that makes two people think one of them made an error.

Workflow

1. Restate the facts before computing

List the principal timeline, the rate, and the period. If the user corrected an earlier statement of the facts — which happens constantly, because interest instructions arrive in fragments — restate the corrected version and say which one you used. Marielle’s second prompt was a correction of her first; computing on the superseded facts is the most likely way to be wrong here.

2. Build the principal timeline

Be explicit about the boundary day. State the rule you used: the change date carries the new principal (so June 25 counts in the 6 days). Say it out loud — it is a one-day, real-money difference, and the other person may have used the other rule.

3. Compute on the stated convention, line by line

Every line shows the full expression, not just the result:

4. Show at least the two most plausible conventions

Because you usually do not know which one the other side used, give the primary answer and a short comparison table:

5. Reconcile against a supplied figure

When the user says “my boss got $X, how did he get that”, the job is reverse-engineering, not agreement. Work it:

1. Compute the difference from your own figure.
2. Try each convention in the table.
3. Try the boundary-day the other way (change date carries old principal).
4. Try component rounding — each term rounded to the cent before summing. This is what a person doing it by hand or in a spreadsheet with ROUND() per cell actually does.
5. Try the incremental method: full-month interest on the original principal, plus interest on the increment only, for the days it was outstanding. This is how most people compute a mid-month top-up by hand, and it is a different number from the weighted-balance method.
6. Solve backwards: implied principal-days = figure × basis / rate, and see what day count that implies.

6. Output

Never present the figure without the working. Never present a reconciliation as agreement when it is within a few cents but not exact — quote both numbers and the difference.

Worked reconciliation — the $639.17 case

Facts: principal $151,500.00, increased to $177,000.00 on 2026-06-25; rate 4.9%; interest paid monthly; period is June 2026 (30 days). A supplied figure of $639.17 has to be reconciled.

Trust Administration Fee Report

Prepares the quarterly trust administration fee (TAF) filing for the Law Society of BC from Clio’s trust reports. Claude reads Clio only; it never creates, edits or deletes anything there.

The rule

• Rule 2-110: $20 for each distinct client matter whose trust deposits, received on or after 1 January 2026, add up to more than $10,000.
• The fee is charged once per matter, in the quarter the total first goes over $10,000.
• A client with several matters can owe the fee on each one.
• Reported and paid quarterly, by the 30th of the month after the quarter ends. GST applies; a late filing adds a late fee.

Procedure

1. Ask which quarter. Default to the quarter that ended most recently.
2. Read Clio’s trust transaction report for every deposit into a trust account from 1 January 2026 to the end of that quarter, with each matter’s number and practice area. Deposits only; withdrawals do not count toward the threshold.
3. Put the deposits in date order and keep a running total for each matter.
4. Find the quarter in which each matter’s total first went over $10,000.
5. Sort the matters into four lists: newly due this quarter; already reported in an earlier quarter (never report these again); getting close, between $5,000 and $10,000; everything else.
6. For each newly due matter, check Clio for a trust administration fee already recorded as an expense, and mark it paid or unpaid.
7. Check each matter’s total against Clio’s trust ledger. List every deposit that does not match and stop before totalling if any are unexplained.
8. Total the fee, the GST and any late fee, and split the count into residential conveyance and other, the way the Law Society’s form asks.
9. Return a spreadsheet: the counts to enter in the Law Society’s portal, then the matters behind them with their running totals and the date each crossed $10,000.

Rules

• Show every matter. No samples, no “and N more”.
• Trust figures are compliance figures: state the report and the date range each number came from.
• Claude does the counting; a person checks it against the bank statements and signs off before filing.

Legal Research → Drafting — Arora Zbar LLP

Turns paid-database legal research into document changes a lawyer can check, with a traceable line from every research question to every clause it moved. Research that never reaches a document is unfinished work; a document changed without a recorded reason is unreviewable.

When this fires

• “write research questions for CoCounsel / Westlaw / Lexis and I’ll run them”
• “do the research first, then update the documents”
• “read the research outputs and update the memo / table / letter”
• “update the precedent source table”
• “redline this against the version I gave you”
• “write a plain-English enclosure letter for the client”

Route elsewhere: a pure BC statute question answered from BC Laws with no drafting attached → bc-corporate-research. Residential conveyance file walkthrough → real-estate-matter-audit. Polishing an already-drafted email → email-polish. Reaching an external research site through the browser → the firm's browser skill handles the connector mechanics.

Hard rules

1. Nothing client-identifying leaves the firm. CoCounsel, Westlaw, Lexis and every other external database sit outside firm context. Research questions are phrased generically — no client or party names, no matter numbers, no addresses, no dollar amounts tied to a named party. Draft the question about the legal problem, not about the client.
2. The lawyer runs the paid databases. Do not assume access. Author the questions in copy-pasteable form and hand them over; ingest what comes back. Where a browser session to those sites is genuinely available, the firm's browser skill governs how to drive it — but the default assumption is that the lawyer runs the search.
3. Every research question ends in one of three recorded outcomes. A drafting change (name the clause), no change (state why the document already handles it), or unresolved (state the decision the lawyer now owes). A question with no recorded outcome is an unfinished question.
4. Redline only against the initial baseline. The baseline is the version the lawyer supplied at the start, not the last iteration produced. A document drafted from scratch or built from a precedent has no baseline and gets no redline — say so rather than inventing a comparison.
5. Drafts are unsigned and undated. No execution date, no completed signature block, no “as of” date on an unexecuted instrument. Label drafts as drafts.
6. A citation you have not seen in the source is not a citation. Paid-database output that names a case is evidence; a case remembered from training is not. Flag anything you could not verify against the returned text as unverified, in the deliverable itself.

Workflow

Step 1 — Read the file before writing anything

List the connected matter folder and read the working documents first — covering memo, decision record, precedent table, the instrument being drafted, and any prior research output already saved there. Never draft against a summary of the file when the file itself is reachable.

Step 2 — Author the research questions

Write them numbered and self-contained, each one pasteable into the database on its own with no surrounding context. For each question:

• State the legal problem generically. Statute and section, the doctrine, the competing positions — not the client’s situation.
• Name the jurisdiction. BC unless the point is genuinely federal or the contract is governed elsewhere. Never let a Canadian question return US or Ontario-default authority unnoticed.
• Say what turns on it. One line: which clause changes, or which advice moves, depending on the answer. A question where nothing turns on the answer should not be asked.
• Rank them. Put the load-bearing questions first — the ones the file’s central advice or the largest exposure depends on. The lawyer’s research time is finite and they may only get through the first few.

Step 3 — Ingest the answers

Read the returned output from wherever it landed — the connected matter folder, a downloads folder, or pasted into the session. Then, per question:

• Map the answer back to its question number. Unmapped answers and unanswered questions both get flagged.
• Separate what the source actually held from commentary about it. A firm bulletin describing a case is not the case.
• Record the citation as returned, verbatim. Where a citation could not be verified in the returned text, mark it unverified rather than dressing it up.
• Note where an answer splits — where one half of a theory is well supported and the other fails. Split answers are the ones most often reported as a single yes or no, and that is where advice goes wrong.
• Where the answer contradicts an earlier public-web pass, apply hard rule 7 and say so.

Step 4 — The research-to-change ledger

Before touching a document, write the ledger. One row per question:

Step 5 — Update the documents

Typical deliverable set on a transaction file:

Step 6 — Redline

Apply hard rule 4. For each document state, in one line, which baseline the redline is against — or that there is none because the document is new. Never redline against an intermediate version you produced earlier in the same engagement; that shows the lawyer your own churn rather than the change they need to approve.

Step 7 — Report

Lead with the two or three things that actually need the lawyer’s attention, not a document inventory. Then the ledger totals, then the file list. Where a research answer creates a sequencing or timing trap — a step that must happen before another or priority is lost — surface it as its own point; those are the findings most easily buried in a document list.

Testing an opposing position

When asked to test what the other side is asserting:

• Name the governing statute or provision. An answer that argues without a citation is not a test.
• Separate where they are right from where they are wrong. Both halves get stated plainly. A position can be correct on one branch and hopeless on the other.
• Do not restate their framing generously. Answer the law, not their characterisation of it.
• Keep the correspondence short. Get to the point, state what the firm will do and by when, and stop.

Privilege and confidentiality

• Client names, matter numbers, party identities and file facts stay inside firm systems. Generic phrasing for anything typed into an external database, per hard rule 1.
• Research outputs saved back to the matter folder are privileged work product like anything else in the file.
• Never summarise one client’s matter into another client’s file or correspondence.

BC Corporate & Estate-Planning Research — Arora Zbar LLP

Answers a BC corporate, trust, or estate-planning question from the statute and the case law, not from memory. The deliverable is a short answer a lawyer can rely on and check: the rule, the section that says so, the link, and the honest boundary of what the sources actually settle.

When this fires

• Statute-interpretation questions: “what does s. 86 require”, “is a s. 227 order enough on its own”, “what does WESA s. 60 let the court do”.
• Minute-book / corporate-record questions: what documents evidence an alteration of articles, a share exchange, a court-ordered conversion, a continuation, a share class amendment.
• Share-structure questions: class rights, redemption amounts, par value, series, whether two holders of the same class can be treated differently.
• Estate-planning device questions: Henson trust, alter ego trust, joint partner trust, spousal trust, bare trust, life interest, s. 42 WESA gift construction.
• Family Law Act intersections: excluded property, tracing, trust contributions, s. 85 exclusions.
• Wills variation and executor-capacity questions under WESA Part 4 Division 6.

Do not fire on: litigation strategy on a live file (that’s the lawyer’s call), residential conveyancing (use real-estate-matter-audit), or a question about a specific matter’s facts where the answer turns on documents in the file — see “Matter-specific questions” below.

Hard rules

1. No proposition without a citation. Every legal statement gets a section number or a case citation plus a working link. A statement you cannot cite is either cut or moved to the “Not settled by the sources” block and labelled as such.
2. BC law only. BC statutes, BCSC/BCCA/SCC. Never import Ontario’s OBCA, the federal CBCA (unless the entity is actually federal and you say so), or US concepts. If the client’s entity is federal or extra-provincial, say so and stop — this skill is BC-incorporated companies and BC estates.
3. Read the section this turn. Fetch the BC Laws page and quote from it. Do not answer from training memory — BC Laws text changes and section numbers move.
4. Currency check. Note the BC Laws “current to” date shown on the page. If the question touches a recently amended area (transparency register, benefit companies, WESA electronic wills), say what the page was current to.
5. Distinguish “required” from “prudent”. A minute-book answer must separate what the Act requires from what the firm keeps as good practice. Label the second as practice, not law.
6. Facts you were not given are not facts. Never invent a share class, a date, a redemption amount, or the existence of a court order.

Primary sources — in this order

Tax consequences (21-year rule, s. 73(1) rollover, s. 104(4) deemed disposition, GRE status) are flagged, not answered — name the issue, name the ITA provision if you are confident, and route to the firm’s tax advisor. The firm does not give tax opinions from a research skill.

Workflow

Step 1 — Classify the question

Write one sentence stating what is actually being asked, in the statutory vocabulary. “Can two shareholders get class H shares with different redemption amounts?” becomes: does the BCA permit share rights within a single class to differ as between holders, or must class rights be uniform and any difference be created as a separate class or series? Getting the statutory framing right before searching is the difference between finding the section and reading around it.

• Statute-determined — the Act answers it. Cite and stop.
• Statute plus interpretation — the Act is open-textured; case law fills it. Cite both.
• Fact-dependent — the answer turns on the client’s articles, the notice of articles, the trust deed, or a court order. See Step 5.

Step 2 — Fetch the sections

Fetch the actual BC Laws page(s) and quote the operative words. Fetch every section you intend to cite, plus the definitions section if a defined term is doing work (share, special rights or restrictions, spouse, excluded property).

Step 3 — Case law, only where the statute runs out

Search CanLII for BCSC/BCCA authority when the statutory text is genuinely ambiguous or the question is about how a discretion is exercised (wills variation quantum, oppression relief, trust variation approval). Prefer BCCA over BCSC, and prefer a case that is cited by later cases. Give the neutral citation and the paragraph number, not just the case name.

Step 4 — Assemble the answer

Use the output shape below. Short. The lawyer wants the rule and the cite, not an essay.

Step 5 — Matter-specific questions

If the answer depends on the client’s own documents — the articles, the notice of articles, the shareholders’ agreement, the trust deed, the entered order, the will — say so and name the document. Do not answer generically and hope.

• Answer the general rule, then state the fact that decides it. “The BCA permits X if the articles authorize it. Whether these articles do is answered by Part N of the company’s articles in the minute book — pull it before relying on this.”
• Pull the document. Matter documents live in the firm’s SharePoint sites (Vault, and the legacy Clio site); the local sync folder name differs by machine, so search the connector rather than assuming a path. Matter facts live in Clio.

Output shape

Drop any block that is empty. Never emit a header with nothing under it.

Worked pattern — court-ordered share conversion under BCA s. 227

The pattern this skill is built around, and a useful calibration for how much the statute actually settles:

• s. 227 sits in Part 8 (Proceedings) and is the oppression remedy. s. 227(3) lists the orders the court may make — s. 227(3)(d) “directing an issue or conversion or exchange of shares”, s. 227(3)(g) directing the company to purchase some or all of the shares, s. 227(3)(n) “directing correction of the registers or other records of the company”. So a “s. 227 conversion” is remedial: the authority is the order, not a shareholders’ resolution.
• The entered order is itself a required records-office record — BCA s. 42(1)(c)(i) requires a copy of each entered order of the court made in respect of the company under the Act.
• The order does not self-execute the registry side. Whatever the order changes about the notice of articles or the authorized share structure still needs the corresponding filing, and whatever it changes about holdings still needs the central securities register updated.
• Everything else the firm puts in the minute book behind that order — a directors’ resolution giving effect to it, cancelled and replacement share certificates, a register annotation cross-referencing the court file number — is prudent practice, not an s. 227 requirement. Label it that way.

BC Registries lookup — Arora Zbar LLP

Live reads against the BC corporate registry (Service BC Connect API) on the firm’s account. Every operation in this skill is free. Purchases are unreachable by construction — an allowlist of six read endpoints, charset-validated path parameters, and a response-side tripwire that treats an assessed fee as an incident — not merely discouraged.

Before you start — which tool

Three tools on the firm’s Postgres v2 connector:

Mode 1 — Find an entity by name

Trigger: “is X still active”, “find the incorporation number for X”, “does X exist”.

1. v2_bcregistry_search with the name. Default status="ACTIVE".
2. If nothing comes back, retry with status="" — a dissolved company is a
3. Report every hit with its registry number, legal type, and status. Do not

Mode 2 — Verify one entity

Trigger: staff has a registry number, or Mode 1 found exactly one candidate.

• exact legalName — use this verbatim in any letter or agreement, never the
• legalType and state (ACTIVE / HISTORICAL)
• goodStanding — true/false
• alternateNames — DBA / trade names, each with its own registration date
• foundingDate, lastAnnualReportDate, nextAnnualReport — a company can be
• inDissolution, inLiquidation, hasCourtOrders, hasRestrictions,

Hard limits — read these before promising anything

Directors and officers of a COMPANY are not available. The registry returns 401 for /parties, /directors, and /addresses on any business not affiliated with the firm’s own registry account. To get directors, officers, or the registered office address of a BC company, someone must purchase a BC Company Summary through BC Registries directly ($8.50) — this skill cannot do it and cannot see it. If staff ask for directors of a company, say that plainly and point at the purchase.

• full — the modernized registry has the entity, so status, good standing,
• search_only — the entity exists and may be ACTIVE, but predates the

Mode 3 — Quote a fee without incurring it

Trigger: “how much is a certificate of status”, “what does a corporate search cost”.

Output shape

Plain English answer first — “Yes, still active, in good standing” — then the supporting fields. Include the registry number in every entity mention. Say explicitly when a field is absent rather than describing it vaguely.

Asana Search Skill

The Core Problem

The get_status_overview tool caps at 20 tasks per project, silently, with no warning and no pagination. For any project with more than 20 tasks it returns an incomplete result. Additionally, the basic get_tasks call returns minimal fields by default — no assignees, no dependencies, no parent info, no custom fields.

The Complete opt_fields Reference

For get_tasks — full-data standard request:

Paste this block as the opt_fields value. Trim fields you don’t need if the response is too large.

Key fields explained:

Step 1: Get Project Metadata First

Before fetching tasks, get the project to know how many tasks to expect:

Step 2: Fetch All Tasks with Full Data (Paginated)

Pagination loop — always do this:

1. Call get_tasks with limit=100
2. If next_page in response is not null → call again with offset = next_page.offset
3. Repeat until next_page is null
4. Concatenate all data arrays

Step 3: Multi-Homed Tasks

A task can belong to multiple projects simultaneously. The memberships array has one entry per project the task belongs to.

Step 4: Parent/Subtask Relationships

Finding subtasks of a task

get_tasks returns top-level tasks only — subtasks are invisible unless you call get_task on their parent.

1. Find all tasks where num_subtasks > 0
2. Call get_task(task_id, include_subtasks=True) for each
3. The subtasks array returns objects with gid and name only (no notes, assignee, etc.)
4. To get full subtask data, call get_task on each subtask GID individually

Parent tasks

If a task has parent.gid set, it is a subtask of something else. This can happen when:

• A task was created as a subtask but added to a project (making it appear in get_tasks for that project)
• You’re looking at tasks fetched via a different context than their home project

Recursive subtask trees

get_task returns only one level. To traverse deeper:

Step 5: Dependencies

Dependencies are directional:

• **dependencies = tasks this task is waiting on** (blocked by)
• **dependents = tasks waiting on** this task (it is blocking them)

Step 6: Full Task Detail

Use get_task for any task where you need:

• Full comment history beyond the inline ~5
• Subtask names and GIDs
• Complete custom field values
• Resolved dependency info
• Resolved subtask list with names
• Full comment history (up to comment_limit)

Step 7: Attachments

Not returned by get_tasks or get_task — requires a separate call:

• Pass a project GID to get all project-level attachments
• Pass a task GID to get attachments on that specific task

Tool Selection Reference

Storing Results

Always save raw JSON first. It lets you re-analyse without re-fetching, and Asana API results stored in tool results files may be truncated if too large.

Create Asana Project Skill

The Key Facts

**The right tool is Asana:create_project_preview** — always available, no setup needed.

• Creates a visual preview widget in chat
• User clicks “Create project” button to push it live to Asana
• Handles any number of sections (tested with 15+)
• Handles any number of tasks (tested with 224 in one call)
• ❌ Does NOT support custom fields — those must be attached manually in Asana project settings after creation
• The Asana MCP read tools (get_project, get_tasks, etc.) — these are read-only

Tool Schema

Step-by-Step Workflow

1. Gather requirements

Ask (or infer from context):

• Project name
• Section names and their tasks
• Any task metadata (assignees, due dates, priorities)?
• Custom fields needed? (remind user these must be added manually post-creation)

2. Call create_project_preview

Pass all sections and tasks in one call. No need to batch — the tool handles large projects fine.

3. Tell the user what to do next

After the widget renders, say:

Custom Fields Workaround

The create_project_preview tool does not accept custom field parameters. After the project is created:

1. User opens the project in Asana
2. Clicks the Customize or Fields button (top right)
3. Searches for existing workspace custom fields by name and adds them

Real Example From This Org

In April 2026, this skill was used to create a master project template for workspace [id] (Arora Zbar LLP):

• 15 sections, 224 tasks, all created in a single create_project_preview call
• Custom fields added manually after: Location (enum, GID [id]) and Amount Required (number, GID [id])

Common Mistakes to Avoid