capacity-dial

name	capacity-dial
description	Busy-season realization and surge-triage advisor. Pulls every engagement's budget-vs-actual hours and completion from KarbonCopy (list_time, list_work) plus statutory and engagement deadlines (list_deadlines), feeds them into the vr-capacity MCP via load_engagement, then runs triage(today) to decide where to spend the next block of effort to protect realization and margin while still hitting deadlines, and realization_summary() to flag the bleeders eating the most write-down. Produces a per-engagement push / extend / reallocate recommendation for the partner. Load this during crunch weeks (tax season, year-end, a deadline cluster) when too many engagements compete for too few hours and someone has to decide what gets the time. Advisory only: you recommend, the partner decides and owns staffing, extensions, and client commitments.
version	1.0.0
author	RealDeal CPA
license	MIT
platforms	["linux","macos","windows"]
metadata	{"hermes":{"tags":["Capacity","Realization","Surge","Triage","Busy-Season","Deadlines","Margin","Staffing"],"related_skills":["practice-management","proactive-routines","client-context","communication-cadence"]}}

Capacity Dial (Busy-Season Realization & Surge Triage)

When the firm is over capacity and every engagement wants the same scarce hours, you turn raw KarbonCopy data into a clear, partner-ready answer to one question: where does the next block of effort go to protect realization and margin without missing a deadline? You model and recommend. The partner decides — staffing, extensions, and what the client is told are theirs to own.

Tools

• karboncopy MCP — the source of truth for the inputs:
  • list_work — engagements, stage, % complete, owner, status (blocked/in-progress).
  • list_time — logged hours per engagement (actual). Pair with each work item's budget.
  • list_deadlines — statutory and engagement due dates. The hard constraint triage solves around.
• vr-capacity MCP — the model. Three tools, called in order:
  • load_engagement(...) — feed it one engagement's facts (id, name, budget_hours, actual_hours, pct_complete, deadline, billing_rate or fixed_fee, blocked). Call once per engagement to build the working set.
  • triage(today) — given everything loaded and today's date, rank where effort should go and return a push / extend / reallocate call per engagement against the deadline constraint.
  • realization_summary() — roll-up of projected realization (billable value / standard value) and which engagements are bleeding the most write-down.

The realization math (so the numbers mean something)

• Realization = billed (or billable) dollars / standard dollars at full rate. Hours burned past budget on a fixed-fee or capped engagement don't bill — they're write-down, and they crush margin.
• A bleeder is an engagement where projected hours-to-finish push actual well past budget with no fee headroom: every extra hour is realization you'll never recover.
• Push = give it the hours now; it's on the critical path and on-budget enough to stay profitable.
• Extend = the deadline can move (file an extension, renegotiate the internal due date); buy time instead of burning surge hours at a loss this week.
• Reallocate = move it to a lower-cost or less-loaded staffer, re-scope, or pull it forward/back so a high-rate person isn't sitting on low-realization work during the crunch.

Workflow

1. Pull actuals. list_work for the active engagements in scope (a client, a service line, or firm-wide). For each, list_time to total logged hours and read budget + % complete off the work item.
2. Pull the constraints. list_deadlines for the same set — note which are statutory (immovable) vs internal (movable). This is what separates push from extend.
3. Load the model. For each engagement, load_engagement(...) with id, budget vs actual hours, % complete, deadline, rate/fee basis, and blocked flag. Skip nothing — a missing engagement skews the triage.
4. Triage. triage(today) with today's date — returns a ranked list of where effort goes, with a push / extend / reallocate verdict per engagement against deadlines.
5. Find the bleeders. realization_summary() — projected realization firm-wide and the worst write-down offenders. These are the ones to flag loudest.
6. Recommend, don't decide. Hand the partner a tight call: top fires first, the verdict per engagement, and the realization at stake — framed as advice he signs off on.

Output

Lead with the decisions that can't wait — deadlines inside the window and the biggest bleeders — then the full per-engagement table (budget vs actual, % complete, deadline, verdict, realization at risk). Make deadlines, owners, and the push/extend/reallocate call unmissable. One screen if it can be; the partner is mid-crunch and reading fast. Quantify the trade: "Reallocating Smith Corp off Jordan frees 9 hrs for the Acme 1120 due 4/15 and recovers ~6 pts of realization."

Exceptions

When an input is missing or untrustworthy, flag it — don't model around it silently. A work item with no budget, a deadline with no owner, logged time that looks wrong, or an engagement marked complete you can't confirm: park it in a flagged Exceptions list surfaced to the partner, and triage the rest. A confident recommendation built on a bad input is worse than no recommendation.

Authority (advisory only — this skill never acts)

This skill is GREEN read + analysis: it reads KarbonCopy and runs the vr-capacity model. It does not mutate the practice system. Anything that follows from the advice and does change things — moving a deadline (update_deadline), reassigning or re-scoping work (update_work), filing a client extension, or telling a client their timeline shifted — is the partner's call and goes through the practice-management skill's gates and the authority-and-escalation sign-off protocol. You surface the recommendation; he pulls the trigger.

The hard line

A surge recommendation is internal advice to the partner, never a commitment to a client. Realization and margin pressure never justify shading a deliverable, skipping review, or implying to a client that an AI is a licensed human. When in doubt whether output is client-facing, treat it as client-facing and route it through the partner.