Matter Plan Builder

Matter Plan Builder

Purpose

Convert agreed scope into a structured matter plan the team can execute against. A plan that exists only in the partner's head is not a plan — it is an intention. The function of this skill is to make the plan explicit, assign ownership, sequence the work, and produce an output that every other LPM discipline can reference.

This skill takes the output of matter-intake-scoping (or an equivalent scope description) and produces the planning layer. scope-change-controller manages that plan as the baseline throughout the matter. status-report-drafter reports progress against it. timeline-generator adds dependency logic and critical path visualisation.

The matter setup decision is part of this skill. How the matter is configured in the billing system — single matter vs phased structure, task codes, matter numbers — directly affects whether the data collected is useful for reporting, billing, and future scoping. Getting it wrong at setup costs the project throughout its lifetime. This is not a billing admin task. It is a strategic planning decision that must be made before time starts being recorded.

---

Operating Modes

Mode 1 — Full plan (most matters)

Scope to complete plan. Matter plan (phases, workstreams, milestones, key dependencies, owners) plus workstream plans for each workstream. Produces matter setup recommendations alongside the plan. Default mode for matters of moderate complexity with a defined team.

Mode 1 produces a workstream plan for every workstream without exception. If there are five workstreams, five workstream plans are produced. Do not produce the first workstream and note that others "follow the same format" — produce them all. Mode 2 is the correct mode when a matter plan without workstream detail is needed. If a user invokes Mode 1 on a matter with many workstreams and full workstream plans would be disproportionate, ask whether Mode 2 is more appropriate before proceeding.

Mode 2 — Matter plan only (large programmes)

Phases, workstreams, high-level milestones, and owners only. Workstream plans are the responsibility of workstream leads — this skill produces the matter plan and the template workstream leads should follow. Produces the dependency-flagged plan for timeline-generator.

Mode 3 — Workstream plan (workstream detail)

A single workstream or jurisdiction plan built in detail. Input: the matter plan (or equivalent) plus the workstream scope. Output: task-level plan with sequencing, dependencies, durations, and owners. Designed for the workstream lead to own and maintain.

Mode 4 — Rolling wave

For matters where full scope is not yet defined. Plan the current phase in full detail. Produce a stub plan for subsequent phases — milestones only, no task detail. Flag the trigger points at which the next phase needs to be planned in detail. The stub is a placeholder, not a commitment — mark it as such.

Mode 5 — Plan update from correspondence

The most frequently needed mode in practice. Accepts emails, call notes, or meeting notes and proposes updates to the existing plan — status changes, progress notes, due date revisions, new blockers, completed tasks. The LPM reviews and confirms; they do not create the updates manually.

This mode exists because the alternative — asking lawyers to update the plan directly — does not work. Lawyers do not update plans. The information exists in their emails and in their heads. The LPM's job is to extract it from those sources without creating a manual data-entry burden that takes longer than the matter itself.

Input: existing plan (uploaded as file or pasted) + correspondence since last update. Output: proposed plan changes, presented as a confirmation list. The LPM confirms, dismisses, or edits each proposed change. The updated plan is produced as a new version (.docx and structured export) on confirmation.

In connected mode, this mode can be triggered automatically — Claude monitors matter correspondence and surfaces proposed updates without waiting for the LPM to initiate.

---

Step-by-Step Process

Step 1: Confirm the scope baseline

Read all provided materials. Identify whether a structured scope summary exists (from matter-intake-scoping Mode 2/3) or whether scope must be reconstructed from the input. If reconstructing: identify matter type, client objectives, key deliverables, jurisdictions involved, and known constraints. Flag scope gaps before proceeding — a plan built on incomplete scope will need rebuilding.

If scope is thin, surface the gaps: what do we need to know before we can build this plan? List them explicitly. Do not produce a plan that buries assumptions without flagging them.

Before producing any plan output, confirm owner names. A plan distributed at kickoff with "[SA name]" placeholders throughout is not a usable plan — it is a draft. If owner names have not been provided in the input, stop and ask before producing any output: "To assign ownership correctly, I need the names of the leads for each workstream. Please confirm: [list workstreams identified from scope]. If names are not yet confirmed, say so and I will produce the plan with [TBC — confirm before distributing] placeholders and flag it as DRAFT."

Do not proceed to plan output until the user has responded — either with names, or with an explicit instruction to proceed with TBC placeholders. Do not silently infer that placeholders are acceptable because the user said they don't know who's doing what. The user must make that call explicitly.

Consuming matter-intake-scoping Mode 2 output: When a Mode 2 scope summary from matter-intake-scoping is provided, map its fields directly to plan inputs — do not treat it as generic prose to be reinterpreted:

| matter-intake-scoping field | Maps to plan input | |---|---| | Inclusions | Workstream scope and deliverables — what each workstream must produce | | Exclusions | Explicit out-of-scope items — flag in plan notes to prevent drift | | Assumptions | RAID log A-entries on matter opening; also populate dependency register where assumptions are information dependencies | | Constraints | Phase duration limits, resource constraints, fixed external dates | | Milestones | Matter plan milestone list starting point — validate against phase pattern before finalising | | Fee basis | Matter setup recommendations — phased vs single matter, whether fee structure requires phase-level tracking | | LPM involvement definition | Communication schedule and plan maintenance responsibilities |

If any of these fields are absent from the scope summary, flag the gap before producing the plan.

Step 2: Identify phases and workstreams

Break the matter into phases (sequential stages with defined entry/exit criteria) and workstreams (parallel lines of work that run across phases). These are different dimensions of the same plan.

Phases are time-based and sequential. Movement between phases should be a deliberate decision — a phase gate — not just elapsed time. Phase gates are moments where the partner (and sometimes the client) confirms: the prior phase work is complete to the required standard, the conditions for the next phase are met, and the team is authorised to proceed. Common phase patterns by matter type are in the domain knowledge section below.

Workstreams are function-based and often parallel: Corporate, Tax, Employment, Real Estate, Regulatory, Finance. On multi-jurisdiction matters, workstreams may be replicated per jurisdiction (Germany Corporate, Netherlands Corporate) or structured as a single cross-border workstream with jurisdiction leads beneath it. The right structure depends on whether jurisdictions are executing the same work in parallel or different work that converges.

The matter plan is the intersection: which workstreams are active in which phases, what each produces, and who owns it.

Step 3: Identify milestones and dependencies

Milestones are binary — done or not done. Not "75% complete." Not "progressing well." A milestone marks the completion of something significant: regulatory filing submitted, DD report issued, transaction documents agreed, execution complete. Every milestone must have a named owner and a target date.

Flag dependencies explicitly. Three types matter in legal work:

Predecessor dependencies — X cannot start until Y is complete. These are the critical path candidates. Tag them by type for timeline-generator: FS (Finish-to-Start), FF (Finish-to-Finish), SS (Start-to-Start), SF (Start-to-Finish). The most common in legal work is FS — one thing must finish before the next can start. FF and SS arise most often in multi-jurisdiction matters where parallel workstreams must reach a milestone together before converging.

Shared resource dependencies — X and Y both require the same person at the same time. Surface these at planning stage. Resource-planner handles the detailed analysis; this skill flags the conflict.

Information dependencies — X cannot proceed without confirmation from an external party: a regulatory body, the counterparty, a tax authority, a client internal team. These are the most dangerous because their duration is outside the firm's control. For every information dependency: who is providing it, what is the expected lead time, and what is the downstream impact if delayed by two weeks / four weeks.

Step 4: Assign owners

Every workstream needs a single named owner. Not "the London team" — a person. Not "local counsel" — a named firm and, where known, a named individual. Ownership without accountability is a workstream that will drift.

Below the workstream owner: identify whether each workstream has sufficient resource at the right level. Gearing matters — a workstream staffed only with senior associates will be expensive and slow on routine tasks; a workstream with no senior resource will escalate everything. Flag gearing concerns; resource-planner handles the detailed analysis.

Step 5: Build matter setup recommendations

Document the matter configuration before the plan is finalised. This is easiest to get right at setup and hardest to fix once the matter is running.

Single matter or phased structure? A single matter with one code simplifies billing for straightforward work. Phased matters allow phase-level financial tracking and phase-gate cost controls — essential where client approval is required before proceeding, or where the fee arrangement changes between phases.

Task code design: Task codes determine what data you can extract. Design them to match the reporting the matter will require:

• If status reports have a row per workstream, each workstream needs a code
• If the budget was built by jurisdiction, each jurisdiction needs a code
• If there will be a phase-gate cost discussion with the client, each phase needs a code
• If there will be a local counsel cost comparison at close, each external firm needs a code

The most common failure: generic codes (e.g. "Corporate," "Tax") when the matter has identifiable sub-workstreams. The data becomes too aggregated to be useful for anything except the total figure.

Billing instruction: Once task codes are agreed, produce a one-paragraph billing instruction specifying which code covers which work. Distribute at kickoff. Without it, each timekeeper guesses, and data quality degrades within the first billing cycle.

Step 6: Produce the plan

Produce outputs in sequence: matter plan first, workstream plans per workstream, then matter setup recommendations. Each is a standalone output for the relevant audience.

Matter plan format:

• Phase summary: phase name, entry criteria, exit criteria, duration estimate, owner, key milestones
• Workstream summary: workstream, owner, active phases, key deliverables, dependencies flagged by type
• Dependency register: dependency, type (predecessor / resource / information), dependent task, blocking task, owner, impact if delayed

Workstream plan format (per workstream):

Task table — required columns in this order. Do not omit any column, even if a field is empty:

| Unique ID | Task ID | Task Summary | Task Description | Owner | Due Date | Duration (days) | Predecessor(s) | Dep Type | Milestone | Status | Progress Notes | Task Code |

• Unique ID: [MatterCode]-T-[sequential number, matter-scoped, never reused] — e.g. 88234-T-001, 88234-T-002. Continues across all workstreams — Corporate tasks might be 88234-T-001 to 88234-T-012, Employment 88234-T-013 to 88234-T-019. Do not restart numbering per workstream.
• Task ID: Human-readable within-plan reference (e.g. WS1-T01) — used in the document for readability and predecessor references.
• Due Date: Specific calendar date. Not a phase reference. Not "Week 3." A date.
• Predecessor(s): Task ID (human-readable) or "None" — never leave blank.
• Progress Notes: Leave blank if not started — but the column must be present.

Milestone list: Unique ID | Milestone ID | Milestone Description | Owner | Target Date | Predecessor Task(s) | Phase Gate? | RAG

Open items: assumptions, outstanding information requests, external confirmations needed.

Kickoff agenda (produce on request): Draft from the matter plan: scope confirmation, workstream introductions, milestone walk-through, dependency flags, matter setup briefing (task codes and billing instruction), escalation path, next review date.

---

Domain Knowledge — Matter Type Phase Patterns

Starting points, not prescriptions. The value is in documenting how this matter's phases differ from the standard pattern and why.

Corporate transaction (M&A, carve-out, disposal): Preparation → Due Diligence → Negotiation → Signing → Regulatory / Conditions Precedent → Completion → Post-Completion

Phase gates: DD report sign-off before negotiation commences; board/client approval before signing; CP satisfaction confirmation before completion is scheduled. Post-completion actions (filings, registrations, notifications) are frequently under-planned — they have no revenue attached and get de-prioritised. Plan them explicitly.

Corporate reorganisation (multi-jurisdiction): Scoping / Structure Design → Sequencing → Jurisdiction-Level Execution → Completion / Registration Confirmations → Post-Completion (strike-offs, deregistrations, final filings)

Key dependency pattern: jurisdictions that must complete before others can begin are the structural critical path. This is not a scheduling preference — it is a legal sequencing requirement. Identify the dependency chain early and pass it to timeline-generator as hard FS dependencies. The reorg-step-plan-builder skill in the LPM for M&A plugin provides detailed methodology for this matter type.

Phase gates: structure design sign-off before execution commences; prerequisite jurisdiction completions before dependent jurisdictions begin; final registration confirmations before post-completion actions start.

Litigation / arbitration: Pleadings → Disclosure / Discovery → Evidence → Hearing → Post-Hearing / Enforcement

Information dependency pattern: third-party disclosure, expert availability, and hearing dates are all outside the firm's control. Plan what is within the firm's control in detail; flag the external dependencies explicitly with duration ranges.

Phase gates: strategy confirmation before pleadings filed; disclosure strategy agreed before document review commences; evidence strategy confirmed before witness statements prepared.

Regulatory (licensing, authorisation): Assessment → Application Preparation → Submission → Regulatory Review Period → Determination → Implementation

The regulatory review period is an information dependency of unknown duration. It blocks some downstream activities entirely and others only partially. At planning stage: identify what can run in parallel during review, what is blocked until determination, and the minimum / expected / maximum duration

…

Source & license

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

• Author: legalopsconsulting
• Source: legalopsconsulting/lpm-skills
• License: Apache-2.0

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