> Headcount and delivery-capacity planning — effective capacity from raw headcount, hire/contract/defer scenarios, and capacity-vs-commitment gap reports. Use when planning a quarter, sizing a hiring ask, or testing whether a roadmap fits.
npx skills add https://github.com/borghei/Claude-Skills --skill capacity-planner
Turns headcount into hours you can actually commit. Most capacity plans fail the
same way: they count people instead of delivered hours, ignore ramp, and size
supply to fit the roadmap rather than the other way round. This skill computes
effective capacity independently, matches it against risk-adjusted demand, and
publishes the cut line.
Before generating, confirm these inputs. If any is unknown or vague, ASK — do not assume:
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
Establishes what the team can actually deliver, computed before anyone looks at
the roadmap. Run this first, always.
tenure_months for someone who has not started yet.meeting_load_pct from a calendar audit, not from memory — the gap is usually 5-10 points.references/capacity-benchmarks.md: below 45% is structurally broken, above 80% is fiction.python3 business-operations/capacity-planner/scripts/capacity_model.py \
--input business-operations/capacity-planner/assets/sample_team.json \
--format text
Matches risk-adjusted demand against capacity in priority order and reports what
does not fit.
"committed": true.committed: true item above the cut line this week — a promise you already know you will miss is a conversation, not a risk.python3 business-operations/capacity-planner/scripts/commitment_gap.py \
--input business-operations/capacity-planner/assets/sample_commitments.json \
--buffer-pct 20 --format text
Applies only to work below the cut line. Never use scenario analysis to justify
a plan that does not fit.
references/planning-methods.md. A four-quarter horizon is systematically biased toward contracting because the hire/contract crossover falls at month 9-14.python3 business-operations/capacity-planner/scripts/scenario_compare.py \
--input business-operations/capacity-planner/assets/sample_scenarios.json \
--format json
Planning figures for one fully-ramped IC over a 63-day quarter:
| Layer | Hours | Running total |
|-------|-------|---------------|
| Gross (63 d x 8 h) | 504 | 504 |
| Booked PTO (5 days) | -40 | 464 |
| On-call (2 weeks @ 40% loss) | -32 | 432 |
| Meetings + overhead (20%) | -86 | 346 |
| Unplanned-work buffer (20%) | -69 | 277 committable |
Use 270-300 committable hours per fully-ramped IC per quarter. A tech lead
delivers 120-160; an engineering manager delivers 0. A mid-level hire starting on
day one of the quarter delivers 90-110.
| Gap size | Persists beyond 4 quarters? | Lever | Time to relief |
|----------|----------------------------|-------|----------------|
| Any | — | Cut scope [PROVEN] | Immediate |
| Under 10% | No | Reduce overhead [PROVEN] | 2-4 weeks |
| 10-30% | No | Defer, with a named later slot | Immediate |
| 10-40% | No, work is separable | Contract [RECOMMENDED] | 1-3 weeks |
| Any | Yes | Hire [PROVEN for structural gaps] | 5-8 months |
| Large | Yes, needed within 2 quarters | Hire + contract bridge [RECOMMENDED] | 1-3 weeks, handover at Q+2 |
Consider them in this order. Reducing overhead is the highest-ROI lever and is
almost always skipped because it is nobody's job — recovering 8% of effective
hours on a ten-person team is worth most of an FTE and costs nothing.
The bridge pattern's failure mode is that the handover never happens and the
contractor becomes permanent at contractor rates. Put the handover date and the
knowledge-transfer artifact in the contract itself.
| Confidence | Definition | Multiplier |
|-----------|------------|-----------|
| High | Team has shipped something near-identical; design complete | 1.15x |
| Medium | Shape understood; unknowns are known | 1.40x |
| Low | New domain, new dependency, or design not started | 1.90x |
Recalibrate against your own actual / original estimate history after two
quarters. Most teams land between 1.3 and 1.6 for "medium". Never make an
external commitment at "low" confidence — either de-risk it to medium first, or
commit the date at the inflated number.
| Planned utilisation | Behaviour |
|--------------------|-----------|
| Below 60% | Under-committed; the space fills with low-value work |
| 70-80% | Target. Absorbs incidents without slipping commitments |
| 80-90% | Every surprise costs a commitment |
| Above 90% | Queueing effects dominate; cycle time rises non-linearly |
This is queueing theory, not motivation. Planning to 95% guarantees late
delivery even when every estimate is correct.
Mistake: Multiplying FTE count by working hours and calling it capacity — 8 engineers x 504 hours = 4,032 hours available.
Why it happens: It is the only number that is easy to get, and it is the number finance and leadership already track. Effective hours require measurement nobody has set up.
Instead: Run the gross-to-effective waterfall every time. The real figure is 50-70% of gross, and the gap is where every over-commitment lives. If you have no measured overhead data, use 60% and start measuring this quarter.
Mistake: Responding to a capacity gap by opening requisitions, then planning as if the new people contribute in the current period.
Why it happens: Hiring is the lever with the clearest approval path — a headcount ask is a familiar conversation in a way that "we are cutting three roadmap items" is not.
Instead: Hiring relieves the quarter after next at the earliest: 8-14 weeks to fill plus 3-6 months to ramp. Close the current gap by cutting scope or contracting, and trigger hiring on a three-quarter trend above 85% load rather than on one bad quarter. Onboarding into an overloaded team also ramps 20% slower, because nobody has time to onboard anyone.
Mistake: Presenting a capacity plan where demand lands within a few percent of supply, with nothing below the cut line.
Why it happens: Estimates get quietly adjusted downward during planning until the roadmap fits the team, or the demand list is truncated before the meeting so it never appears.
Instead: Treat a perfect fit as evidence of a process failure and go find which number moved. Every honest plan has a visible cut line, and the below-the-line list is the most useful artifact the exercise produces — it is what lets a stakeholder trade priorities rather than discover in week 10 that their item was never going to happen.
Mistake: Setting the unplanned-work reserve to whatever makes the plan work — dropping from 20% to 10% when the roadmap does not fit.
Why it happens: The buffer looks like slack, and slack looks like something to be negotiated away. It has no advocate in the room.
Instead: Set the buffer from the trailing three quarters of actual unplanned hours; it is a measurement, not a cushion. If unplanned work exceeded the buffer for two consecutive weeks last quarter, the correct move is to raise it. Cutting the buffer does not create capacity — it just relocates the shortfall to week 10, where it costs more.
| File | Purpose |
|------|---------|
| scripts/capacity_model.py | Converts roster + overhead + ramp into effective hours per person and per discipline |
| scripts/commitment_gap.py | Inflates estimates by confidence, fills capacity in priority order, reports the cut line |
| scripts/scenario_compare.py | Projects hire/contract/defer scenarios over a horizon with cost per delivered hour |
| references/capacity-benchmarks.md | Effective-hours ratios by role, ramp curves, on-call and meeting load, utilisation bands, hire-vs-contract economics |
| references/planning-methods.md | Planning sequence, demand forecasting, gap-closing levers, governance cadence, stakeholder pushback responses |
| assets/capacity-plan-template.md | Quarterly capacity plan with cut line, gap options, risks, and weekly tracking |
| assets/sample_team.json | Seven-person roster covering ramping hires, part-time, and multiple disciplines |
| assets/sample_commitments.json | Nine commitments against the capacity produced by capacity_model.py on the sample roster |
| assets/sample_scenarios.json | Four-quarter demand curve with hire, contract, and defer scenarios |
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Prepares and structurally reviews readiness evidence for ISO management-system and laboratory-competence standards - ISO 13485 medical device QMS, ISO 14971 device risk management, ISO/IEC 17025 testing and calibration laboratories, and ISO 15189 medical laboratories. Use when organizing declared scope, controlled documents, risk-management files, scope of accreditation, traceability, CAPA, external-provider controls, or bounded local evidence manifests, and when separating ISO certification from laboratory accreditation, FDA QMSR inspection, CLIA certification, MDSAP, and EU MDR/IVDR evidence boundaries. Not for legal applicability, compliance, certification, or accreditation decisions; contains no clause text.
Sample-size and statistical power calculations for planning studies. Use whenever someone asks "how many subjects/samples/replicates do I need", wants an a priori power analysis, a minimum detectable effect (MDE), a power curve, or needs to justify a sample size for a grant, IRB protocol, or pre-registration. Covers closed-form power for t-tests, ANOVA, proportions, correlations, chi-square, and regression, plus simulation-based (Monte Carlo) power for designs with no formula — logistic/Poisson regression, mixed models, cluster-randomized trials, survival, and interactions. Use this skill even when the request only mentions an effect size, alpha, or "80% power" without saying "power analysis" explicitly. For laying out the study (randomization, blocking, factorial/DOE, crossover, sequential designs) use experimental-design; for analyzing data already collected and reporting it use statistical-analysis.
Universal QA checklist for generated scientific plots: overlapping labels, clipped text, missing axes/legends, overcrowded data, and cross-journal resolution/format guidance.
Senior Elite Software Engineer (15+) and Senior Product Designer. Full workflow with planning, architecture, TDD, clean code, and pixel-perfect UX validation.
Run PinchBench benchmarks to evaluate OpenClaw agent performance across real-world tasks. Use when testing model capabilities, comparing models, submitting benchmark results to the leaderboard, or checking how well your OpenClaw setup handles calendar, email, research, coding, and multi-step workflows.
Use this skill when implementing tasks according to Conductor's TDD workflow, handling phase checkpoints, managing git commits for tasks, or understanding the verification protocol.
Verify PowerToys behavior end-to-end with the winapp CLI across two scenarios: (A) a module's release checklist against the installed build; (B) PR validation — derive each PR's checklist from its description + diff, then drive it against the installed build (a merged/shipped PR, or a whole release/hotfix set) or by building + sideloading the module when the PR isn't in the build yet (unmerged or not-yet-released). Drive each item via UIA invoke / Named Events / settings.json edits / clipboard / GPO / SendInput, and emit a structured PASS / FAIL / BLOCKED verdict per item with evidence (FAIL distinguishes product defects from stale/ambiguous checklist items). Use when asked to verify a module checklist, validate a PR, sign off a release/hotfix's PRs, or QA installed/sideloaded PowerToys bits. Combines generic winapp ui mechanics (references/winapp-ui-testing.md) with PT-specific recipes, per-scenario playbooks (references/scenarios/), and the helper .ps1 files shipped with this skill.
Take borghei/capacity-planner from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.