legalopsconsulting/lpm-skills/matter-plan-builder

Claude Code and agent skill by legalopsconsulting/lpm-skills

Trust tier 2
  • community
LLM review pending
Source check pending

Checking that the SKILL.md file is still in the repository.

Convert agreed scope into a structured matter plan — phases, workstreams, milestones, dependencies, owner assignments, and matter setup decisions. Use when planning a new matter, running a kickoff, building a workstream plan, structuring phases, setting up task codes, or producing a plan to drive status reporting. Trigger on: 'build a plan', 'matter plan', 'project plan', 'what are the phases', 'workstream plan', 'how do we sequence this', 'who owns what', 'task codes', 'matter setup', 'workstr…

Install

npx vskill@latest install legalopsconsulting/lpm-skills/matter-plan-builder

SKILL.md

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 fieldMaps to plan input
InclusionsWorkstream scope and deliverables — what each workstream must produce
ExclusionsExplicit out-of-scope items — flag in plan notes to prevent drift
AssumptionsRAID log A-entries on matter opening; also populate dependency register where assumptions are information dependencies
ConstraintsPhase duration limits, resource constraints, fixed external dates
MilestonesMatter plan milestone list starting point — validate against phase pattern before finalising
Fee basisMatter setup recommendations — phased vs single matter, whether fee structure requires phase-level tracking
LPM involvement definitionCommunication 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.

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 100 of 100Pattern checks on the skill's files.
  • Model reviewNot runA model review is scheduled for the next rescan.

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

7-day trend score
0

Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/legalopsconsulting/lpm-skills/matter-plan-builder/badge)](https://verified-skill.com/skills/legalopsconsulting/lpm-skills/matter-plan-builder)

Something wrong with this skill or its page? Tell us.