legalopsconsulting/lpm-skills/matter-intake-scoping

Matter Intake and Scoping

Purpose

Support the LPM across the full pre-execution arc: from unstructured client data to a structured brief the partner can write a proposal from, through to the agreed baseline that every other LPM discipline references.

The LPM's role is structural, not determinative. In pre-engagement, the job is removing the painful data-assembly phase — taking whatever the client has thrown at the legal team and organising it so the partner and senior associate can start making legal and commercial decisions rather than hunting through emails. What the firm proposes to do, and at what price, belongs to the partner. The LPM makes that work fast.

This skill operates in four modes:

1. Pre-engagement — organise unstructured client data into a structured brief. The primary mode.
2. Quick intake — capture the agreed baseline after engagement is confirmed.
3. Full intake — comprehensive baseline for large or complex matters.
4. Mid-matter recovery — reconstruct baseline when the LPM inherits mid-flight.

Output format

All outputs from this skill are produced as .docx files unless the user explicitly requests otherwise. These are matter records — they belong in the matter folder, not in the chat window. Inline text is not an acceptable substitute for any mode's primary output. If the user has not asked for a specific format, default to .docx without prompting.

Knowledge infrastructure

This skill references two types of supporting files:

Skill references (in references/ alongside this file):

• standing-assumptions.md — assumption performance register by matter type, maintained by the firm
• matter-type-profiles/[type].md — which knowledge domains are relevant for each matter type; routes to shared-knowledge files

Shared-knowledge files (in shared-knowledge/ at the plugin root, populated by the deploying firm):

• Legal and jurisdictional knowledge files (execution requirements, entity types, regulatory thresholds, etc.)
• Referenced by both LPM and attorney skills; consumed differently by each
• The LPM skill flags that an issue exists and recommends it be addressed. Attorney skills use the same files to do the substantive analysis.

The routing mechanism is this skill's responsibility. The content of the knowledge files belongs to the firm deploying it — populated from their own practice expertise, not from this skill.

Mode 1: Pre-engagement client data structuring

The problem this solves

A client sends a mandate. It arrives as six emails, two org charts, a prior transaction file, a data room link, and notes from a discovery call. The partner needs to get a proposal out. Before they can write a single line of proposed scope, someone has to organise that material into something coherent.

That task — data compilation, conflict detection, gap identification — is painful, time-consuming, and requires no legal judgment. It wastes partner and senior associate time. The LPM does it once, cleanly, so the legal team starts from a brief rather than a pile.

What this mode produces

Primary output: Pre-engagement client brief (docx). Organised, sourced, conflict-flagged raw material for the partner. Does not contain proposed scope, approach, team, or fees — those require judgment that belongs to the partner.

Secondary output: Open questions list. Prioritised items requiring partner input (relationship and commercial context the LPM doesn't have) or client input (missing information).

Step 1: Identify the matter type and load the relevant profile

Before processing inputs, identify the matter type and load the corresponding profile from references/matter-type-profiles/[type].md.

The matter-type profile identifies which knowledge domains are typically relevant, which shared-knowledge files to reference for standard flags, what assumptions commonly arise, and what gaps and conflicts typically appear on this matter type.

If no profile exists for this matter type, proceed without one and note the gap — I'd suggest recommending the firm creates a profile from the outputs of this engagement.

Step 2: Assemble and catalogue the inputs

Take everything provided. Assign each input a source reference ([S1], [S2], etc.). Common sources and what to extract:

• Discovery / scoping call notes — business objective, client-stated priorities, timeline pressures, known constraints. The "why" behind the matter. More valuable than any document.
• Client email correspondence — scope indicators, entity and jurisdiction references, implied expectations, stated constraints, commercial sensitivities.
• Org charts / corporate structure documents — entity count, jurisdiction list, structure complexity, dormant or subsidiary entities.
• Prior transaction / matter files — comparable scope, historical assumptions, what changed during execution.
• Commercial documents (SPA, SHA, LOI, term sheet) — transaction perimeter, defined terms that constrain scope.
• Data room index — entity and document counts, completeness signals.
• RFP / pitch brief — stated requirements, evaluation criteria, client-side constraints.

For each input: what does it confirm, what does it imply, what does it contradict with another source?

Step 3: Apply source-attributed confidence layering

Label every extracted data point with one of four confidence levels. Apply consistently — a brief where everything looks equally solid gives the partner a false picture.

Confirmed — stated explicitly in client correspondence or documents. Source cited. Partner can rely on this directly.

Inferred (from inputs) — the inputs imply this but it has not been confirmed. Flag for partner or client confirmation before the proposal commits to a position.

Inferred (from general knowledge) — not in any client input; identified by applying standard legal, operational, or market knowledge to the matter type and jurisdictions. Always cite the basis. Always mark clearly as external inference. Format: [Inferred from general knowledge: (basis stated). Recommend specialist confirmation before the proposal addresses this.]

Unknown — relevant to scope but not addressed in any available input. Goes directly to the open questions list.

The distinction between Inferred (from inputs) and Inferred (from general knowledge) matters. The partner needs to know whether a flag came from something the client said or from something the LPM knows about how this type of work operates. Both are useful; they have different epistemic status and different implications for what the partner needs to do next.

Step 4: Multi-source conflict detection

When inputs contradict each other, surface it explicitly with both sources cited. Do not resolve conflicts — resolution requires partner and client input.

Rate each conflict: Critical (proposal cannot be issued without resolution) / High (significant scope or relationship implications) / Medium (relevant but not proposal-blocking) / Low (worth noting).

Step 5: Apply external knowledge flags

Consult the matter-type profile (Step 1) to identify which shared-knowledge files are relevant for this matter type and jurisdiction mix. For each relevant knowledge domain, check whether the client inputs address it. If not, surface it as an external knowledge flag using the Inferred (from general knowledge) label.

Format for external knowledge flags in the brief:

[Flag — [knowledge domain]] [Issue description and basis]. This has not been addressed in the client inputs. I'd suggest the partner considers whether to include this in the proposal or confirm with specialist counsel before scope is finalised.

Where no shared-knowledge file exists for a relevant domain, note the gap and suggest the firm creates one.

Step 6: Calibrate the assumptions candidate list

Consult references/standing-assumptions.md for this matter type before drafting the assumptions candidate list.

The standing-assumptions file contains the firm's accumulated record of which assumptions hold on which matter types, which breach, and with what consequence. The goal is a calibrated starting position rather than a copy of the last matter's list applied uncritically.

Copy-paste failure mode to avoid: Importing the standing list without calibration imports both reliable assumptions and failed ones. Nobody removes assumptions that consistently breach because nobody tracks which ones breach. Nobody adds assumptions for failure modes that appeared in recent retrospectives. The list mutates slowly, based on whoever remembered the last painful matter. The standing-assumptions.md file makes this traceable — but only if it is maintained, which requires the continuous-improvement-engine feeding it at matter close.

Calibration logic:

• Retain assumptions that hold consistently — state with confidence
• Strengthen high-failure assumptions — make more precise, lower the deviation threshold
• Surface assumptions that appear repeatedly as undocumented surprises — recommend adding to the standing list
• Flag regulatory timeline assumptions as time-sensitive — these change and must be verified before the proposal commits

Performance note format: "This assumption has held on [X of Y] similar matters / breached on [N] matters, typically due to [pattern] / has not been formally captured but appeared as a surprise on recent matters of this type."

Where standing-assumptions.md is empty or unpopulated for this matter type, produce the candidate list from first principles and recommend the firm begins capturing performance data going forward.

The assumptions candidate list is for partner review and refinement — raw material, not a finished product. I'd suggest the partner adjusts or rejects items as appropriate and takes ownership of the final list before the proposal is issued.

Step 7: Draft the pre-engagement client brief

PRE-ENGAGEMENT CLIENT BRIEF DRAFT — For partner and senior associate use. Not for client circulation.

Client: [Client name] | Client number: [Client number] Matter: [Matter name / working title] | Matter number: [Matter number] Prepared by: [LPM name] | Date: [Date]

SUMMARY — Action required before proposal can issue Items the partner must resolve, in priority order. Includes unresolved conflicts, open questions requiring relationship or commercial context, and any assumption that materially affects scope or fees. This section is the partner's working list — everything below is the supporting evidence.

1. Conflicts across source materials Each conflict with both sources cited, severity rated. Not resolved — for partner decision before the proposal is issued.

2. Open questions Prioritised by impact. Two categories — For the partner (relationship or commercial context the LPM doesn't have) and For the client (missing information that must be obtained before the proposal is written).

3. External knowledge flags Issues identified from shared-knowledge files or general knowledge not addressed in client inputs. Each marked as Inferred (from general knowledge) with basis stated and specialist confirmation recommended.

4. Matter context Business objective as stated by the client (sources cited). Confidence level noted.

5. Extracted data points Organised by category: entities and structure, jurisdictions, timeline references, stated objectives, fee and commercial references, client-side constraints. Every item source-cited, confidence-labelled.

6. Assumptions candidate list For partner review and refinement. Each candidate with source, confidence level, and performance note where available. I'd suggest the partner takes ownership of the final list before the proposal is issued.

7. Suggested next steps Recommended sequence before the proposal can be issued, ordered by dependency.

Annex A: Source materials