# Matter Intake Scoping > Matter scoping across the full pre-execution arc — organise client data into a structured brief, capture the agreed baseline, or reconstruct scope mid-flight. Use when making sense of client information before a proposal, scoping a new matter, running a kickoff, defining scope, mapping stakeholders, or inheriting a matter mid-flight. Trigger on: 'make sense of this', 'structure this for the propo… - **Type:** Skill - **Install:** `agentstack add skill-legalopsconsulting-lpm-skills-matter-intake-scoping` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [legalopsconsulting](https://agentstack.voostack.com/s/legalopsconsulting) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** Apache-2.0 - **Upstream author:** [legalopsconsulting](https://github.com/legalopsconsulting) - **Source:** https://github.com/legalopsconsulting/lpm-skills/tree/main/skills/matter-intake-scoping ## Install ```sh agentstack add skill-legalopsconsulting-lpm-skills-matter-intake-scoping ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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** | Ref | Document / communication | Type | Date | Key content extracted | |-----|--------------------------|------|------|-----------------------| | [S1] | [Title / subject line] | [Email / Docx / Call notes] | [Date] | [What was used] | *This brief organises client-provided inputs and flags conflicts, gaps, and external knowledge considerations for partner review. It does not contain proposed scope, fees, or legal advice. All judgments on what the firm proposes to do belong to the partner.* --- ### If the partner asks for a draft proposal or scope sections Produce them. A well-flagged draft the partner edits is better than nothing. But apply all of the following without exception: **DRAFT labelling — mandatory:** - Document header block (before the DRAFT warning): ``` Client: [Name] | Client number: [Number] Matter: [Name] | Matter number: [Number] Prepared by: [LPM name] | Date: [Date] ``` - Document header must read: `DRAFT — FOR PARTNER REVIEW AND EDITING. NOT FOR CLIENT CIRCULATION IN THIS FORM.` - Repeat `[DRAFT]` at the start of every substantive section heading - Any section requiring legal or commercial judgment that the LPM cannot supply must be left as an explicit stub: `[PARTNER TO COMPLETE — requires your judgment on [specific issue]]` - PARTNER NOTE flags (see the Summary section above) go at the top of the document, not the end **The brief comes first.** If scope is requested before the brief has been produced, produce the brief first. The scope draft is built from the brief's extracted data points — without the brief, the scope draft has no traceable basis. **Confidence labels carry through.** Every scope item in the draft that derives from an Inferred or Unknown data point carries its label inline. The partner can see at a glance what is solid and what they need to validate. **The draft proposal does not replace the brief.** Both are needed — the brief is the internal working document; the draft proposal is what goes to the partner for editing before client issue. --- ## Mode 2: Quick intake Runs immediately after engagement is confirmed. 30 minutes. Produces the scope baseline that scope-change-controller manages for the life of the matter. **Input:** Engagement letter, fee proposal, or confirmed scope email. If nothing exists in writing, work from the verbal agreement and flag the absence — I'd suggest logging an undocumented scope baseline as an A-entry in the RAID log from day one. **Output:** Matter scope summary, stakeholder register, initial assumptions log, LPM involvement definition, open items list. **Matter scope summary format:** ``` MATTER SCOPE SUMMARY Client: [Name] Client number: [Number] Matter: [Name] Matter number: [Number] Date: [Date] Version: 1.0 Partner: [Name] Fee basis: [Fixed/Capped/Hourly/AFA] Cap: [If applicable] BUSINESS OBJECTIVE [One sentence. Why the client is doing this.] SCOPE INCLUSIONS [Bullet list. Every quantifiable parameter: X entities, Y jurisdictions.] SCOPE EXCLUSIONS [Explicit. If none documented, flag as risk.] ASSUMPTIONS [Numbered. Quantified where possible. Owner and validation method for each.] 1. [Statement] — Owner: [Name] — Validate by: [Method / deadline] CONSTRAINTS [Timeline, resource, regulatory.] KEY MILESTONES [Date — Milestone — Hard / Soft] FEE BASIS NOTES [How the fee basis affects scope sensitivity on this matter.] ``` **LPM involvement definition:** I'd suggest agreeing this with the partner at matter setup rather than leaving it assumed. What the LPM owns, facilitates, monitors, and does not do. Framed as a service proposal — not contractual, a shared understanding. The alternative is months of both sides discovering by accident what the other expected. This is a named output of Mode 2, not optional. Prompt the partner explicitly if the inputs don't already confirm it. If the partner defers the conversation, log it as an open item and flag it again at the first puls … ## 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. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** yes - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-legalopsconsulting-lpm-skills-matter-intake-scoping - Seller: https://agentstack.voostack.com/s/legalopsconsulting - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.