Matter Drill Down

matter-drill-down

Working view on a single matter for the LPM's own operational use. Structured around three primary elements: deliverables, issues, and risks. Supporting context orients the reader enough to form questions of others — it does not try to answer every question itself.

The skill is different from status-report-drafter in that the output is for the LPM, not for a partner or client audience. Different register, different structural choices, different expectation of distribution. The drill-down is a working surface; the status report is a communications artefact.

The skill operates in four modes. Standard drill-down (Mode 1) is the default — the LPM has decided to focus on one matter and wants the full working picture. Decision-first (Mode 2) narrows the view to open decisions only. Partner prep (Mode 3) reshapes the template for an upcoming partner call on the matter. Handoff briefing (Mode 4) produces the briefing a receiving LPM needs to take over a matter without losing continuity — a constantly-triggered need that is currently painful to do and frequently skipped despite its operational value.

When to use this skill

• The user pastes single-matter correspondence and asks for a working view
• The user asks for a zoom-in from a portfolio briefing — "drill into [matter]", "focus on [matter]"
• The user is preparing for a partner call on a matter
• The user is going on leave, handing a matter over, or onboarding someone new to a matter

For portfolio-level views across multiple matters, use daily-briefing. For audience-facing status reports, use status-report-drafter.

Input Classification (apply before mode selection)

Step 1 — Matter count. Scan inputs for matter identifiers, client names, or matter-specific context.

• If inputs are about a single matter → this skill applies. Proceed to Step 2.
• If inputs span two or more matters → route to daily-briefing.

Step 2 — Mode routing. Identify the user's invocation pattern:

• "Handing over", "leave cover", "taking over", "bringing [name] onto", "going on leave" → Mode 4
• "Prep me for", "partner call", "before the call with" → Mode 3. Mode 3 produces a .docx document using the Mode 3 Template Variation. It does not produce conversational prose, advisory bullet points, or pre-call notes in paragraph form. Produce the document, not a chat answer. If M365 connector is available, invoke outlook_email_search for the matter and outlook_calendar_search for the named partner before producing — do not ask for inputs.
• "Decisions only", "what do I need to decide on", "open decisions" → Mode 2. Mode 2 produces a .docx document using the Mode 2 Template Variation. It does not produce conversational prose or advisory paragraphs. Produce the document, not a chat answer.
• Any other single-matter drill-down request → Mode 1 (default)

Step 3 — Audience check. If the user specifies the output is for a partner or client audience (e.g. "for JMW to send to the client", "status report for the partner", "client-facing update"), this is the wrong skill. Do not produce any output. Do not produce a status report. Do not produce a client-facing document. Do not read the docx skill. Instead, respond with exactly this pattern and stop:

"This is a [status report / client-facing update] for [audience]. That's status-report-drafter, not a drill-down. Run status-report-drafter on [matter] ([matter number]) with the same inputs."

The failure mode is detecting the audience, deciding you can produce the document anyway, and doing so. That is gate-skipping. The correct behaviour is to refuse and route, even though you could produce the document.

Step 4 — Input tagging. If the user has tagged inputs by source ([FROM LC], [INTERNAL], [CLIENT], [PARTNER]), preserve the tags in attribution.

Before Starting Any Mode

M365 retrieval (when connector is available). If the M365 connector is available, invoke outlook_email_search for the matter name before producing output in any mode. Do not ask for pasted inputs if connected mode is available — retrieve first, then produce. For Mode 3: additionally invoke outlook_calendar_search for the named partner (past 30 days and upcoming 14 days) before producing. Do not rely on memory or prior conversation context when connected retrieval is available.

Matter identifiers. Client name, client number, matter name, matter number. Required in every output header. If not provided in inputs, ask once: "Confirm matter identifiers (client name, client number, matter name, matter number) before I produce the working view." Hard gate — do not produce until confirmed or explicit placeholder agreement given.

Current phase and RAG. Required. If not in inputs, infer from correspondence and flag the inference.

Invocation context. State explicitly why the drill-down is being produced: portfolio briefing handoff, LPMHub click-through, direct ask, upcoming partner call, handoff preparation. Include in output header.

Receiving LPM (Mode 4 only). If Mode 4 invocation, identify the receiving LPM. If not provided: "Who is receiving the matter? (Name required for handoff briefing.)"

Call context (Mode 3 only). If Mode 3 invocation, identify the partner and the call purpose. If not provided: "Which partner and what is the purpose of the call?"

Boundary

This skill produces a working view on one matter for the LPM's own consumption. It does not:

• Produce status reports for distribution (use status-report-drafter)
• Produce portfolio-level briefings (use daily-briefing)
• Update RAID logs (use risk-and-issues-manager)
• Draft scope change memos (use scope-change-controller)
• Produce budget variance analysis (use budget-and-fee-manager)
• Produce stakeholder communications plans (use stakeholder-comms-planner)

If the user asks for any of these, route to the appropriate skill and do not produce a drill-down.

Operating Modes

Mode 1 — Standard drill-down (default)

Fires when: User requests a single-matter working view without a more specific invocation pattern.

Input: Correspondence, call notes, matter baseline, current-state context for one matter.

Output: Working view using the standard template (below). 2–3 pages.

Mode 2 — Decision-first

Fires when: User asks "what do I need to decide on [matter]", "open decisions on [matter]", "[matter] — decisions only".

Input: Same as Mode 1.

Output: Produce a .docx working view using the Mode 2 Template Variation below. Do not produce conversational prose, advisory paragraphs, or a list of decisions as chat output. The output is a structured document with an identifier header, expanded decision entries in the template format, and retained Issues and Risks tables. Deliverables and supporting orientation sections collapsed to one line each. Do not end with a question or offer.

Mode 3 — Partner prep

Fires when: User is preparing for a partner call on the matter — "prep me for [partner] call", "before the call with [partner]", "pre-call on [matter]".

Input: Same as Mode 1, plus context on the upcoming call (partner, purpose, timing).

Output: Produce a .docx document using the Mode 3 Template Variation below. Do not produce conversational prose, advisory bullet points, or pre-call notes in paragraph form. The output is a structured document. The first content you produce is the identifier header block — not a comment, question, flag, or advisory text. Starting with the header commits you to document format. Conversational preamble before the header is the failure mode. Produce the document, not a chat answer. The template includes:

• Decisions required from the partner in this call
• Information the partner may not yet have (anchored to since last touchpoint)
• Likely partner questions with prepared answer lines
• Deliverables and Issues sections expanded around what the partner needs to know or decide
• Risks retained but framed as risks the partner should be aware of
• Supporting context (financial position, team state, client-side activity)

Mode 4 — Handoff briefing

Fires when: User is handing a matter to another LPM — "handover on [matter]", "I'm handing [matter] to [name]", "leave cover on [matter]", "taking over [matter]", "bringing [name] onto [matter]".

Input: Same as Mode 1, plus identification of the receiving LPM, plus (where possible) the outgoing LPM's knowledge of the matter that is not in the files.

Domain knowledge specific to Mode 4: Handoff briefings are a constantly-triggered operational need. Leave cover, role transitions, and matter reallocations happen continuously. The briefing is universally painful to produce — it takes time the outgoing LPM does not have — and is frequently skipped despite the operational value of doing it well.

The skill's job in Mode 4 is to make the handoff fast enough that it actually happens. The template prioritises the content that matters most to a receiving LPM picking up the matter cold:

1. Deliverables over the next 2–4 weeks — what is due, when, to whom. This is the operational spine the receiving LPM needs to not drop anything.
2. Issues — current — what is in flight that needs continued management. Status and context for action.
3. Risks — plausible future — what might come up in the handoff window. Context for mitigation.
4. Outstanding commitments the outgoing LPM has made — the things said in emails, on calls, in meetings that are not yet done but have been promised.
5. What is not visible in the matter files — the tacit knowledge. Relationship dynamics with the client, unwritten context on partner preferences, patterns of behaviour on the other side, things the outgoing LPM knows but has not documented anywhere.
6. Who to call — by issue type. If scope questions arise, call X. If a billing question comes up, call Y. If the client pushes back on something, start with Z.

Output: Extended template (below). Longer than Mode 1 — 4–6 pages is acceptable because the handoff briefing is the complete operational transfer document.

Standard Template (Mode 1)

Produce the template sections in this exact order.

MATTER DRILL-DOWN — [Matter short name]

Client:           [Client name] ([Client No.])
Matter:           [Matter name] ([Matter No.])
Lead Partner:     [Initials or name]
Lead LPM:         [Name]
Phase:            [Current phase and position]
RAG:              [Green / Amber / Red]
Fee model:        [Fixed fee / T&M cap / Phased / etc.]
WIP / Budget:     [Current WIP] / [Budget]
Prepared:         [Date and time]
Invocation:       [Why this drill-down is being produced]

SUMMARY
[2–3 sentences. Direct, no hedging. Current position. The one or
two dynamics shaping the week. The next decision point.]

DELIVERABLES — DUE THIS WEEK AND NEXT
| # | Deliverable | Owner | By when | Status |
|---|---|---|---|---|

ISSUES — CURRENT
| Issue | Status | Context for action |
|---|---|---|

RISKS — PLAUSIBLE FUTURE
| Risk | Signal | Mitigation context |
|---|---|---|

OPEN DECISIONS
| # | Decision | Owner | By when | Current state |
|---|---|---|---|---|

SCOPE SIGNALS
Active scope signals on this matter. If none, state "No active
scope signals" and move on.

| Signal type | Driver | Status | Handoff |
|---|---|---|---|

FINANCIAL POSITION
One paragraph. WIP against plan, variance and its nature (structural 
vs substantive), forward exposures. Do not reproduce full variance 
analysis here — hand off to `budget-and-fee-manager` for detail.

TEAM AND STAKEHOLDER STATE
Internal team: [1–3 lines — who is on, current load, staffing watch items]
Client side: [1–3 lines — who is engaging, current tone, any changes]
External counsel: [1–3 lines — LC status by jurisdiction, escalations]

CROSS-MATTER CONTEXT
How this matter connects to others in the portfolio. Shared partner,
shared LPM, same client, regulatory overlay, counterparty. If no
notable connections, state "No notable cross-matter context" and
move on. Do not invent connections.

HANDOFFS
Single-matter skills to invoke as follow-through.

| Skill | Trigger | Priority |
|---|---|---|

End of drill-down.

Output rule: Produce from available information. Use placeholders for unknowns. Do not withhold pending matter identifiers — ask once, then produce. Do not end with "want me to produce this as a .docx?" — produce the .docx.

Attribution rule: Substantive analysis or recommendations from named individuals are attributed by name. Do not generalise to "the team".

Mode 2 Template Variation (Decision-first)

Produce the decision-first working view as a .docx using the template below. Do not produce conversational prose, advisory commentary, or a list of decisions in paragraph form. The output is a structured document with an identifier header, expanded decision entries, and retained Issues and Risks tables. Do not end with a question or offer.

Same header. Collapse Deliverables, Team state, Financial position, Cross-matter context to one line each. Expand:

OPEN DECISIONS — EXPANDED

For each decision:
- Decision statement
- Owner and by-when
- Options under consideration
- Current state (what is known, what is pending)
- What is blocking progress
- LPM recommendation (if applicable)

ISSUES — CURRENT
[Standard table, retained — issues constrain decisions]

RISKS — PLAUSIBLE FUTURE
[Standard table, retained — risks inform decisions]

Mode 3 Template Variation (Partner prep)

Produce the partner-prep working view as a .docx using the template below. Do not produce conversational prose, advisory bullet points, or pre-call notes in paragraph form. The output is a structured document with an identifier header and the Mode 3 sections in order. Do not end with a question or offer.

Same header with Partner, Call purpose, Call timing added.

SUMMARY
[2–3 sentences. Frame specifically around the call.]

RECENT PARTNER TOUCHPOINTS — [PARTNER NAME]
Last touchpoints with [partner] in the past 30 days. Establishes
what the partner knows coming into this call.

| Date | Meeting / call | What was covered | Follow-up identified |
|---|---|---|---|

Next scheduled: [This call — date, time, format]
If no calendar data: state "Calendar not retrieved — confirm last
touchpoint date from correspondence before producing this section."

DECISIONS REQUIRED FROM THE PARTNER IN THIS CALL
| Decision | Options to consider | LPM recommendation | Why now |
|---|---|---|---|

INFORMATION THE PARTNER MAY NOT HAVE
Items that have arrived or developed since the last partner touchpoint
(see above). Client-side dynamics the partner has not seen, emerging
risks the LPM has spotted since that date. Flagged as "worth raising".

| Item | Source | Why the partner should know |
|---|---|---|

LIKELY PARTNER QUESTIONS WITH PREPARED ANSWER LINES
3–5 questions the LPM anticipates the partner asking. Each with a 
prepared answer line — not a script, a prompt.

| Question | Answer line |
|---|---|

DELIVERABLES — DUE THIS WEEK AND NEXT
[Standard table]

ISSUES — CURRENT
[Standard table]

RISKS — PLAUSIBLE FUTURE
[Standard table]

SUPPORTING CONTEXT
One paragraph each: current financial position, team state, client-side 
activity. Enough to orient the partner if they ask.

HANDOFFS
[Standard table]

Mode 4 Template Variation (Handoff briefing)

Same header with Handoff from, Handoff to, Effective date added.

SUMMARY
[3–5 sentences. What this matter is. Where it is today. What is 
coming up in the handoff window. Anything the receiving LPM 
should know before opening the matter files.]

DELIVERABLES — NEXT 2–4 WEEKS
The operational spine of the handoff. The receiving LPM needs to not 
drop any of these.

| # | Deliverable | Owner | By when | Status | Context |
|---|---|---|---|---|---|

ISSUES — CURRENT
Problems in flight that need continued management. Context suf

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [legalopsconsulting](https://github.com/legalopsconsulting)
- **Source:** [legalopsconsulting/lpm-skills](https://github.com/legalopsconsulting/lpm-skills)
- **License:** Apache-2.0

Install and usage instructions live in the source repository linked above.