[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MFB90EPJD45DYNX2WFTFZF":3,"skill-same:01M6MFB90EPJD45DYNX2WFTFZF":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":13,"repositoryHtmlUrl":67,"repositoryHomepageUrl":6,"ownerHtmlUrl":68,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":69,"install":70,"resources":83},"01M6MFB90EPJD45DYNX2WFTFZF","capacity-planner",null,"Use when an ops leader (Director of CX, Head of Support, VP Ops, Head of BizOps, Head of IT ops, Head of Finance ops) is sizing ops capacity, building a headcount plan, modeling utilization risk, planning Q3 capacity or annual support capacity, or designing CS coverage — and needs Erlang-C queueing math, P90 demand sizing, shrinkage-adjusted FTE, manager-trigger thresholds, and a quarterly hiring sequence with ramp + attrition. Apply when sustained team utilization is above 80% or when the team is growing >50% in 12 months. Run before committing the headcount budget. This is NOT engineering capacity (see vpe-advisor for DORA + cycle time) and NOT strategic 3-year workforce planning (see chro-advisor).","JiayiV\u002Fquestion_mixing","JiayiV","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54466889?v=4","01M6JFJYYMRZ3QRGP9339JNQ2K","01M6JFJZ35KB0QVT50NAHPJA7G",0,"MIT","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fpublic-02-claude-skills-main-gemini-skills-capacity-planner-skill-329aa88b\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"capacity","planner","capacity planner","math","sequence","modeling","director","time","cycle","advisor","opencode","coverage","cli","plan","leader","team","Budget","code","run","support","2026-11-10 10:12:30",false,"---\nname: capacity-planner\ndescription: \"Use when an ops leader (Director of CX, Head of Support, VP Ops, Head of BizOps, Head of IT ops, Head of Finance ops) is sizing ops capacity, building a headcount plan, modeling utilization risk, planning Q3 capacity or annual support capacity, or designing CS coverage — and needs Erlang-C queueing math, P90 demand sizing, shrinkage-adjusted FTE, manager-trigger thresholds, and a quarterly hiring sequence with ramp + attrition. Apply when sustained team utilization is above 80% or when the team is growing >50% in 12 months. Run before committing the headcount budget. This is NOT engineering capacity (see vpe-advisor for DORA + cycle time) and NOT strategic 3-year workforce planning (see chro-advisor).\"\nversion: 2.8.0\nauthor: claude-code-skills\nlicense: MIT\ntags: [bizops, capacity, headcount, utilization, queueing-theory, ops-planning, little-law, workforce]\ncompatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]\n---\n\n# capacity-planner\n\nSizing tool for **ops teams that handle queued work** — Support, CX,\nCustomer Success, BizOps, IT ops, Finance ops. Built on Erlang-C\nqueueing theory, Little's Law, and the operational-leadership canon\n(Fournier, Larson, Cleveland, Reinertsen). Deterministic, stdlib-only,\nno LLM calls.\n\n## Purpose\n\nYou are an ops leader sized 15 → 35 with no idea how the 35-person org\nwill actually behave at peak load. Or you are at 88% utilization and\nSLA is starting to slip. Or you have a hiring budget approved and need\nto sequence it across four quarters without burning out the existing\nteam. This skill answers those questions with arithmetic, not vibes.\n\nIt produces three artifacts:\n\n1. **Capacity sizing** at 70\u002F80\u002F90% utilization against P50\u002FP90\u002FP99\n   demand, with P(SLA breach) at each point and a SAFE\u002FWATCH\u002FAT_RISK\u002FCRITICAL\n   risk band.\n2. **Utilization health** at the per-member traffic-light level plus a\n   team verdict (HEALTHY\u002FSQUEEZED\u002FOVERLOADED\u002FUNBALANCED).\n3. **12-month quarterly hiring plan** accounting for ramp curves,\n   attrition, QoQ demand growth, and span-of-control manager triggers.\n\n## When to use\n\n- **Annual ops capacity planning** (October-November for the following\n  fiscal year).\n- **Quarterly re-sizing** if demand changed >15% or attrition spiked.\n- **Pre-budget defense** — the math that justifies the headcount ask\n  to your CFO.\n- **Diagnostic** when an ops team is missing SLA and you need to know\n  whether it's a sizing problem, a process problem, or a bottleneck\n  problem.\n- **M&A \u002F new-segment launch** modeling — sizing a new team or\n  combined org.\n\n## Workflow\n\n1. **Intake demand**. Pull P50\u002FP90\u002FP99 daily ticket\u002Fcase volume from\n   your work system (Zendesk, Intercom, JSM, ServiceNow, Salesforce).\n   If you only have averages, stop and pull the distribution. Single-\n   point demand estimates are the most expensive anti-pattern in ops.\n2. **Model throughput**. Run `capacity_modeler.py` with your demand,\n   AHT, SLA target, current FTE, and shrinkage. Use `--profile` for\n   your function (support \u002F cx \u002F bizops \u002F finance-ops \u002F it-ops). Read\n   the 80%-utilization row — that's your sizing point.\n3. **Flag utilization risk**. Run `utilization_analyzer.py` against\n   your current team's actual utilization data. Anyone >85% sustained\n   is a throughput-collapse risk per Reinertsen. Spread >30 percentage\n   points across team means UNBALANCED — fix that before hiring.\n4. **Sequence hiring**. Run `hiring_sequencer.py` with current FTE,\n   target EOY, ramp time, attrition, and growth. It will front-load\n   hires (Q1 35%, Q4 15%), apply ramp curves, and trigger a manager\n   hire when span of control crosses 7 ICs\u002Fmanager.\n5. **Walk the Forcing-question library** (see below). One question at\n   a time. Do not skip ahead. Answers must be written down before\n   you commit the plan.\n\n## Scripts\n\n- `scripts\u002Fcapacity_modeler.py` — Erlang-C sizing with shrinkage\n  adjustment and P50\u002FP90\u002FP99 breach probabilities. `--profile`\n  for industry defaults.\n- `scripts\u002Futilization_analyzer.py` — per-member traffic-light +\n  team-level health verdict with variance detection.\n- `scripts\u002Fhiring_sequencer.py` — 12-month quarterly plan with ramp,\n  attrition, growth, max-hires-per-quarter constraint, and\n  manager-trigger logic.\n\nAll three accept `--input \u003Cpath>` (JSON), `--output {markdown,json}`,\n`--sample` (built-in example), and `--help`. Stdlib only.\n\n## Quick example\n\n```bash\n# Emits an Erlang-C capacity model (required headcount + P50\u002FP90\u002FP99 breach probabilities) for the built-in example\ncd business-operations\u002Fskills\u002Fcapacity-planner && python3 scripts\u002Fcapacity_modeler.py --sample\n```\n\n## References\n\n- `references\u002Fqueueing_theory_canon.md` — Erlang, Little, Hopp &\n  Spearman, Reinertsen, Kingman, Cleveland, ITIL, Armony et al. (8\n  sources). The math.\n- `references\u002Fops_workforce_planning_canon.md` — Fournier, Larson,\n  Google SRE Workbook, Frei, Lawler, Bersin, Gartner, Grove (8\n  sources). The people factors.\n- `references\u002Fcapacity_anti_patterns.md` — 11 named anti-patterns\n  with cited sources, tool guards, and the meta-discipline that\n  Lencioni + Goldratt + Christensen impose. (8+ named sources.)\n\n## Assets\n\n- `assets\u002Fcapacity_brief_template.md` — 20-minute fill-out template\n  with JSON skeletons for all three tools and an output checklist.\n\n## Assumptions\n\nThis skill assumes:\n\n- Work is **queued** (tickets, cases, work items) — not project-style.\n  If your team's work isn't queued, this is the wrong skill.\n- Demand has a **stationary-enough distribution** within a quarter.\n  Step-changes (new product launch, M&A, regulatory shift) require\n  re-running mid-quarter.\n- You have **at least 90 days of historical demand data** to compute\n  P50\u002FP90\u002FP99. If not, generate the distribution from your sales \u002F\n  user-base forecast first.\n- Service is **single-class** within a queue. If you have hard\n  priority tiers (P1\u002FP2\u002FP3 with class-specific SLAs), model each as\n  a separate queue and sum.\n- **Channels are modeled coherently.** Multi-channel teams use the\n  appropriate `--profile` with built-in shrinkage premium.\n\n## Anti-patterns\n\nSee `references\u002Fcapacity_anti_patterns.md` for the full taxonomy with\nsources. Top eight:\n\n1. Plan-to-100%-utilization (Reinertsen Principle 12)\n2. Treat-ramp-as-instant (Larson)\n3. Ignore-attrition-in-12-month-plan (Bersin)\n4. Hire-ICs-forever-with-no-manager-trigger (Fournier)\n5. Size-to-P50-demand-only (Cleveland)\n6. No-shrinkage-adjustment (Cleveland, SRE Workbook)\n7. Single-channel-model-for-multi-channel-work (Gartner, Kingman)\n8. No-surge-plan-for-P99-events (Hopp & Spearman, Reinertsen)\n\n## Distinct from\n\n- **`c-level-advisor\u002Fvpe-advisor`** measures *engineering* throughput\n  via DORA 4 metrics, story points, deployment frequency, and cycle\n  time bottlenecks. It is for engineering teams shipping code. This\n  skill is for ops teams handling tickets\u002Fcases. Different unit of\n  work, different math (Erlang-C vs. DORA), different bottleneck\n  (queueing-blind staffing vs. WIP + lead time).\n- **`c-level-advisor\u002Fchro-advisor`** does *strategic* workforce\n  planning (1-5 year capability portfolios, talent supply, leadership\n  succession). This skill does *operational* 0-12 month capacity\n  sizing against demand. Per Lawler: conflating them gets you hired\n  into the wrong jobs.\n- **`project-management\u002F*`** tracks delivery throughput on projects\n  (Jira velocity, sprint capacity). This skill sizes around steady-\n  state queued work.\n- **Sibling `process-mapper`** *finds* the bottleneck. This skill\n  *sizes the team around* a known bottleneck. Order of operations:\n  process-mapper first → capacity-planner second. Hiring around the\n  wrong constraint wastes the hires.\n- **`business-growth\u002Fcs-coverage`** (if it exists) sizes Customer\n  Success coverage by ARR\u002FCSM ratio and segment. This skill sizes by\n  queued work volume (tickets, cases, escalations). For a CS team\n  that handles both relationship work AND a ticket queue, run both.\n\n## Forcing-question library (Matt Pocock grill discipline)\n\n**Discipline**: walk these one at a time. Do not skip ahead. Answers must\nbe written down. If you can't answer one, that is your next investigation.\n\n### Q1 — \"What is your bottleneck, and have you confirmed it empirically?\"\n\n**Recommended answer**: a named, measured stage in the workflow with\nqueue-time data showing where work waits. Not a vibe. Not \"escalations\ntake too long\". An actual measured queue.\n\n**Why it's the first question**: Goldratt (*The Goal*, 1984) — every\nsystem has exactly one binding constraint at a time. Sizing around the\nwrong constraint wastes hires entirely. If you do not know your\nbottleneck, run `process-mapper` BEFORE this skill.\n\n**Canon**: Eli Goldratt, *The Goal* (1984); Reinertsen, *Principles of\nProduct Development Flow* (2009).\n\n### Q2 — \"What service trade-off are you accepting?\"\n\n**Recommended answer**: a written, explicit choice — fast vs. empathetic,\nbroad vs. deep, low-cost vs. high-quality. Frances Frei is unambiguous:\nyou cannot win all four. The team that tries wins zero.\n\n**Why it matters**: AHT, SLA, and shrinkage inputs are the operational\nexpression of this trade-off. If they don't agree (e.g., you set AHT for\n\"empathy\" but SLA for \"speed\"), the plan is internally inconsistent.\n\n**Canon**: Frances Frei & Anne Morriss, *Uncommon Service* (HBR Press,\n2012).\n\n### Q3 — \"What's your demand P90, and what's the gap to your P99?\"\n\n**Recommended answer**: two specific numbers from the last 90 days of\ndata, with the calendar context of each (e.g., \"P90 was 480 tickets\u002Fday\non normal Tuesdays; P99 was 720 on the day after the November release\").\nA team sized to P50 misses SLA half the time. A team sized to P99\noverstaffs by 30-50%. P90 is the right operating sizing point per\nCleveland.\n\n**Canon**: Brad Cleveland, *Call Center Management on Fast Forward* (4th\ned., 2019); A.K. Erlang, *The Theory of Probabilities and Telephone\nConversations* (1909).\n\n### Q4 — \"At your planned utilization, what is P(SLA breach) at P90 and at P99?\"\n\n**Recommended answer**: two probabilities, computed (not guessed) from\nErlang-C with your specific N, AHT, and SLA target. If P(breach at P90)\n> 10% you are understaffed at the sizing point. If P(breach at P99) >\n50% you have no surge plan and the next peak event will be visible to\nthe CEO.\n\n**Canon**: Erlang (1909); Hopp & Spearman, *Factory Physics* (3rd ed.,\n2008), VUT equation.\n\n### Q5 — \"Have you budgeted replacement hires for the attrition you'll see this year?\"\n\n**Recommended answer**: yes, with a specific number. At 30% annual\nattrition (Bersin BPO midpoint), a 20-FTE team loses ~6 people this year.\nIf your \"add 5 net\" plan is actually a \"hire 11\" plan, the recruiting\nvolume changes drastically. Anti-pattern #3.\n\n**Canon**: Bersin\u002FDeloitte talent benchmarks (2015-2023); Edward Lawler,\n*Strategic Workforce Planning* (USC CEO, 2008).\n\n### Q6 — \"When does span of control trigger a manager hire, and who is the candidate?\"\n\n**Recommended answer**: a specific quarter (from `hiring_sequencer.py`)\nand at least one identified candidate (internal lead or external hire).\nPast 7 ICs\u002Fmanager, 1:1s degrade, feedback cycles slip, attrition\nclimbs. Past 10 you have a coverage crisis. Hire the manager BEFORE\ncrossing 10, not after.\n\n**Canon**: Camille Fournier, *The Manager's Path* (O'Reilly, 2017),\nch. 5; Andy Grove, *High Output Management* (1983).\n\n### Q7 — \"What is your surge plan for the P99 day?\"\n\n**Recommended answer**: an explicit, documented plan — overflow tier,\nBPO contracted capacity, on-call rotation, executive escalation tree,\nOR a written degradation contract that says \"on P99 days we extend SLA\nto X minutes and notify customers proactively\". If the answer is \"we'll\nfigure it out\", the P99 day is a fire visible to the board.\n\n**Canon**: Hopp & Spearman, *Factory Physics* (2008); Reinertsen (2009)\non capacity-margin discipline.\n\n---\n\n**Walk these seven in order. One at a time. Write the answers down. The\nplan you submit is only as defensible as your answers to these seven\nquestions.**\n","# capacity-planner\n\nSizing tool for **ops teams that handle queued work** — Support, CX,\nCustomer Success, BizOps, IT ops, Finance ops. Built on Erlang-C\nqueueing theory, Little's Law, and the operational-leadership canon\n(Fournier, Larson, Cleveland, Reinertsen). Deterministic, stdlib-only,\nno LLM calls.\n\n## Purpose\n\nYou are an ops leader sized 15 → 35 with no idea how the 35-person org\nwill actually behave at peak load. Or you are at 88% utilization and\nSLA is starting to slip. Or you have a hiring budget approved and need\nto sequence it across four quarters without burning out the existing\nteam. This skill answers those questions with arithmetic, not vibes.\n\nIt produces three artifacts:\n\n1. **Capacity sizing** at 70\u002F80\u002F90% utilization against P50\u002FP90\u002FP99\n   demand, with P(SLA breach) at each point and a SAFE\u002FWATCH\u002FAT_RISK\u002FCRITICAL\n   risk band.\n2. **Utilization health** at the per-member traffic-light level plus a\n   team verdict (HEALTHY\u002FSQUEEZED\u002FOVERLOADED\u002FUNBALANCED).\n3. **12-month quarterly hiring plan** accounting for ramp curves,\n   attrition, QoQ demand growth, and span-of-control manager triggers.\n\n## When to use\n\n- **Annual ops capacity planning** (October-November for the following\n  fiscal year).\n- **Quarterly re-sizing** if demand changed >15% or attrition spiked.\n- **Pre-budget defense** — the math that justifies the headcount ask\n  to your CFO.\n- **Diagnostic** when an ops team is missing SLA and you need to know\n  whether it's a sizing problem, a process problem, or a bottleneck\n  problem.\n- **M&A \u002F new-segment launch** modeling — sizing a new team or\n  combined org.\n\n## Workflow\n\n1. **Intake demand**. Pull P50\u002FP90\u002FP99 daily ticket\u002Fcase volume from\n   your work system (Zendesk, Intercom, JSM, ServiceNow, Salesforce).\n   If you only have averages, stop and pull the distribution. Single-\n   point demand estimates are the most expensive anti-pattern in ops.\n2. **Model throughput**. Run `capacity_modeler.py` with your demand,\n   AHT, SLA target, current FTE, and shrinkage. Use `--profile` for\n   your function (support \u002F cx \u002F bizops \u002F finance-ops \u002F it-ops). Read\n   the 80%-utilization row — that's your sizing point.\n3. **Flag utilization risk**. Run `utilization_analyzer.py` against\n   your current team's actual utilization data. Anyone >85% sustained\n   is a throughput-collapse risk per Reinertsen. Spread >30 percentage\n   points across team means UNBALANCED — fix that before hiring.\n4. **Sequence hiring**. Run `hiring_sequencer.py` with current FTE,\n   target EOY, ramp time, attrition, and growth. It will front-load\n   hires (Q1 35%, Q4 15%), apply ramp curves, and trigger a manager\n   hire when span of control crosses 7 ICs\u002Fmanager.\n5. **Walk the Forcing-question library** (see below). One question at\n   a time. Do not skip ahead. Answers must be written down before\n   you commit the plan.\n\n## Scripts\n\n- `scripts\u002Fcapacity_modeler.py` — Erlang-C sizing with shrinkage\n  adjustment and P50\u002FP90\u002FP99 breach probabilities. `--profile`\n  for industry defaults.\n- `scripts\u002Futilization_analyzer.py` — per-member traffic-light +\n  team-level health verdict with variance detection.\n- `scripts\u002Fhiring_sequencer.py` — 12-month quarterly plan with ramp,\n  attrition, growth, max-hires-per-quarter constraint, and\n  manager-trigger logic.\n\nAll three accept `--input \u003Cpath>` (JSON), `--output {markdown,json}`,\n`--sample` (built-in example), and `--help`. Stdlib only.\n\n## Quick example\n\n```bash\n# Emits an Erlang-C capacity model (required headcount + P50\u002FP90\u002FP99 breach probabilities) for the built-in example\ncd business-operations\u002Fskills\u002Fcapacity-planner && python3 scripts\u002Fcapacity_modeler.py --sample\n```\n\n## References\n\n- `references\u002Fqueueing_theory_canon.md` — Erlang, Little, Hopp &\n  Spearman, Reinertsen, Kingman, Cleveland, ITIL, Armony et al. (8\n  sources). The math.\n- `references\u002Fops_workforce_planning_canon.md` — Fournier, Larson,\n  Google SRE Workbook, Frei, Lawler, Bersin, Gartner, Grove (8\n  sources). The people factors.\n- `references\u002Fcapacity_anti_patterns.md` — 11 named anti-patterns\n  with cited sources, tool guards, and the meta-discipline that\n  Lencioni + Goldratt + Christensen impose. (8+ named sources.)\n\n## Assets\n\n- `assets\u002Fcapacity_brief_template.md` — 20-minute fill-out template\n  with JSON skeletons for all three tools and an output checklist.\n\n## Assumptions\n\nThis skill assumes:\n\n- Work is **queued** (tickets, cases, work items) — not project-style.\n  If your team's work isn't queued, this is the wrong skill.\n- Demand has a **stationary-enough distribution** within a quarter.\n  Step-changes (new product launch, M&A, regulatory shift) require\n  re-running mid-quarter.\n- You have **at least 90 days of historical demand data** to compute\n  P50\u002FP90\u002FP99. If not, generate the distribution from your sales \u002F\n  user-base forecast first.\n- Service is **single-class** within a queue. If you have hard\n  priority tiers (P1\u002FP2\u002FP3 with class-specific SLAs), model each as\n  a separate queue and sum.\n- **Channels are modeled coherently.** Multi-channel teams use the\n  appropriate `--profile` with built-in shrinkage premium.\n\n## Anti-patterns\n\nSee `references\u002Fcapacity_anti_patterns.md` for the full taxonomy with\nsources. Top eight:\n\n1. Plan-to-100%-utilization (Reinertsen Principle 12)\n2. Treat-ramp-as-instant (Larson)\n3. Ignore-attrition-in-12-month-plan (Bersin)\n4. Hire-ICs-forever-with-no-manager-trigger (Fournier)\n5. Size-to-P50-demand-only (Cleveland)\n6. No-shrinkage-adjustment (Cleveland, SRE Workbook)\n7. Single-channel-model-for-multi-channel-work (Gartner, Kingman)\n8. No-surge-plan-for-P99-events (Hopp & Spearman, Reinertsen)\n\n## Distinct from\n\n- **`c-level-advisor\u002Fvpe-advisor`** measures *engineering* throughput\n  via DORA 4 metrics, story points, deployment frequency, and cycle\n  time bottlenecks. It is for engineering teams shipping code. This\n  skill is for ops teams handling tickets\u002Fcases. Different unit of\n  work, different math (Erlang-C vs. DORA), different bottleneck\n  (queueing-blind staffing vs. WIP + lead time).\n- **`c-level-advisor\u002Fchro-advisor`** does *strategic* workforce\n  planning (1-5 year capability portfolios, talent supply, leadership\n  succession). This skill does *operational* 0-12 month capacity\n  sizing against demand. Per Lawler: conflating them gets you hired\n  into the wrong jobs.\n- **`project-management\u002F*`** tracks delivery throughput on projects\n  (Jira velocity, sprint capacity). This skill sizes around steady-\n  state queued work.\n- **Sibling `process-mapper`** *finds* the bottleneck. This skill\n  *sizes the team around* a known bottleneck. Order of operations:\n  process-mapper first → capacity-planner second. Hiring around the\n  wrong constraint wastes the hires.\n- **`business-growth\u002Fcs-coverage`** (if it exists) sizes Customer\n  Success coverage by ARR\u002FCSM ratio and segment. This skill sizes by\n  queued work volume (tickets, cases, escalations). For a CS team\n  that handles both relationship work AND a ticket queue, run both.\n\n## Forcing-question library (Matt Pocock grill discipline)\n\n**Discipline**: walk these one at a time. Do not skip ahead. Answers must\nbe written down. If you can't answer one, that is your next investigation.\n\n### Q1 — \"What is your bottleneck, and have you confirmed it empirically?\"\n\n**Recommended answer**: a named, measured stage in the workflow with\nqueue-time data showing where work waits. Not a vibe. Not \"escalations\ntake too long\". An actual measured queue.\n\n**Why it's the first question**: Goldratt (*The Goal*, 1984) — every\nsystem has exactly one binding constraint at a time. Sizing around the\nwrong constraint wastes hires entirely. If you do not know your\nbottleneck, run `process-mapper` BEFORE this skill.\n\n**Canon**: Eli Goldratt, *The Goal* (1984); Reinertsen, *Principles of\nProduct Development Flow* (2009).\n\n### Q2 — \"What service trade-off are you accepting?\"\n\n**Recommended answer**: a written, explicit choice — fast vs. empathetic,\nbroad vs. deep, low-cost vs. high-quality. Frances Frei is unambiguous:\nyou cannot win all four. The team that tries wins zero.\n\n**Why it matters**: AHT, SLA, and shrinkage inputs are the operational\nexpression of this trade-off. If they don't agree (e.g., you set AHT for\n\"empathy\" but SLA for \"speed\"), the plan is internally inconsistent.\n\n**Canon**: Frances Frei & Anne Morriss, *Uncommon Service* (HBR Press,\n2012).\n\n### Q3 — \"What's your demand P90, and what's the gap to your P99?\"\n\n**Recommended answer**: two specific numbers from the last 90 days of\ndata, with the calendar context of each (e.g., \"P90 was 480 tickets\u002Fday\non normal Tuesdays; P99 was 720 on the day after the November release\").\nA team sized to P50 misses SLA half the time. A team sized to P99\noverstaffs by 30-50%. P90 is the right operating sizing point per\nCleveland.\n\n**Canon**: Brad Cleveland, *Call Center Management on Fast Forward* (4th\ned., 2019); A.K. Erlang, *The Theory of Probabilities and Telephone\nConversations* (1909).\n\n### Q4 — \"At your planned utilization, what is P(SLA breach) at P90 and at P99?\"\n\n**Recommended answer**: two probabilities, computed (not guessed) from\nErlang-C with your specific N, AHT, and SLA target. If P(breach at P90)\n> 10% you are understaffed at the sizing point. If P(breach at P99) >\n50% you have no surge plan and the next peak event will be visible to\nthe CEO.\n\n**Canon**: Erlang (1909); Hopp & Spearman, *Factory Physics* (3rd ed.,\n2008), VUT equation.\n\n### Q5 — \"Have you budgeted replacement hires for the attrition you'll see this year?\"\n\n**Recommended answer**: yes, with a specific number. At 30% annual\nattrition (Bersin BPO midpoint), a 20-FTE team loses ~6 people this year.\nIf your \"add 5 net\" plan is actually a \"hire 11\" plan, the recruiting\nvolume changes drastically. Anti-pattern #3.\n\n**Canon**: Bersin\u002FDeloitte talent benchmarks (2015-2023); Edward Lawler,\n*Strategic Workforce Planning* (USC CEO, 2008).\n\n### Q6 — \"When does span of control trigger a manager hire, and who is the candidate?\"\n\n**Recommended answer**: a specific quarter (from `hiring_sequencer.py`)\nand at least one identified candidate (internal lead or external hire).\nPast 7 ICs\u002Fmanager, 1:1s degrade, feedback cycles slip, attrition\nclimbs. Past 10 you have a coverage crisis. Hire the manager BEFORE\ncrossing 10, not after.\n\n**Canon**: Camille Fournier, *The Manager's Path* (O'Reilly, 2017),\nch. 5; Andy Grove, *High Output Management* (1983).\n\n### Q7 — \"What is your surge plan for the P99 day?\"\n\n**Recommended answer**: an explicit, documented plan — overflow tier,\nBPO contracted capacity, on-call rotation, executive escalation tree,\nOR a written degradation contract that says \"on P99 days we extend SLA\nto X minutes and notify customers proactively\". If the answer is \"we'll\nfigure it out\", the P99 day is a fire visible to the board.\n\n**Canon**: Hopp & Spearman, *Factory Physics* (2008); Reinertsen (2009)\non capacity-margin discipline.\n\n---\n\n**Walk these seven in order. One at a time. Write the answers down. The\nplan you submit is only as defensible as your answers to these seven\nquestions.**\n",{"name":5,"tags":48,"author":56,"license":14,"version":57,"description":7,"compatible_tools":58},[49,23,50,51,52,53,54,55],"bizops","headcount","utilization","queueing-theory","ops-planning","little-law","workforce","claude-code-skills","2.8.0",[59,60,61,62,33,63],"claude-code","codex-cli","cursor","antigravity","gemini-cli","main","068c2486ccc0f8d200a3db4d21ec137064eda3b4","skills\u002Fpublic-02-claude-skills-main-gemini-skills-capacity-planner-skill-329aa88b","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing","https:\u002F\u002Fgithub.com\u002FJiayiV","2026-08-25 16:30:52",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add JiayiV\u002Fquestion_mixing --skill capacity-planner",{"tool":76,"command":77},"bunx","bunx skills add JiayiV\u002Fquestion_mixing --skill capacity-planner",{"tool":79,"command":80},"pnpm","pnpm dlx skills add JiayiV\u002Fquestion_mixing --skill capacity-planner","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fpublic-02-claude-skills-main-gemini-skills-capacity-planner-skill-329aa88b\u002FSKILL.md",true,[],[85,110,136,169,197,230],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":43},"01M6NN9PJS9NHWPDG4QP93BP8F","webmcpify","Make a web app agent-ready — propose a WebMCP tool manifest, integrate, verify in a real browser, heal; unrelated code stays untouched. Use for \"webmcpify\", \"add WebMCP\", or \"expose app actions to AI agents\".","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fwebmcpify\u002FSKILL.md",[],[87,92,93,94,95,40,96,97,98,99,100,101,102,103,104,105,106,107,108,109],"github","ai agents","web","notes","browser","https","actions","manifest","inventory","verify","tool","use","ready","unrelated","app","scope","for","webmcp",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":114,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":43},"01M6NN6KZE5RBN6NGHN2WXV1RE","vardoger-analyze","Use when the user asks to personalize the GitHub Copilot CLI assistant, adapt Copilot to their style, use vardoger, or analyze their Copilot CLI conversation history. Reads the local session directory at `~\u002F.copilot\u002Fsession-state\u002F`, extracts recurring preferences and conventions, and writes a fenced personalization block into `~\u002F.copilot\u002Fcopilot-instructions.md`. Runs entirely on the user's machine via the local `vardoger` CLI (`pipx install vardoger`); no network calls and no uploads. Triggers: 'personalize my copilot', 'analyze my copilot history', 'tailor copilot to me', 'run vardoger', 'update my copilot instructions from history', 'make copilot learn my style'.","Apache-2.0","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fvardoger-analyze\u002FSKILL.md",[],[118,119,120,35,121,122,41,123,124,125,126,127,128,129,130,131,132,133,134,135],"vardoger analyze","analyze","directory","github copilot","copilot","update","learn","network","my style","install","conversation","me","local","github copilot cli","pipx","my","at","copilot instructions",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":150,"publishedAt":43},"01M6NN3CZGQP3XAJ04BM1NNYGT","transloadit-media-processing","Process media files (video, audio, images, documents) using Transloadit. Use when asked to encode video to HLS\u002FMP4, generate thumbnails, resize or watermark images, extract audio, concatenate clips, add subtitles, OCR documents, or run any media processing pipeline. Covers 86+ processing robots for file transformation at scale.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Ftransloadit-media-processing\u002FSKILL.md",[142,147],{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":148,"categoryName":149,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000023","Skill与智能体开发",[151,152,153,154,155,156,157,158,159,160,161,162,163,103,164,165,166,167,108,168],"transloadit media processing","Media","media processing","processing","MCP","mcp server","documents","subtitles","pipeline","ocr","Video","Audio","mp4","images","files","transformation","free","hls",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":178,"publishedAt":43},"01M6NN28E92F9GH4WFYQ2H1Y15","terraform-azurerm-set-diff-analyzer","Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes. Use when reviewing terraform plan output for Azure resources like Application Gateway, Load Balancer, Firewall, Front Door, NSG, and other resources with Set-type attributes that cause spurious diffs due to internal ordering changes.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fterraform-azurerm-set-diff-analyzer\u002FSKILL.md",[175],{"categoryNo":176,"categoryName":177,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000011","运维与部署",[179,180,181,182,183,184,185,186,187,103,188,189,190,191,192,193,194,195,196,108],"terraform","SET","terraform azurerm set diff analyzer","diff","analyzer","diffs","azure","gateway","firewall","only","resource changes","provider","resources","load balancer","attributes","front","load","balancer",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":212,"publishedAt":43},"01M6NN1QMH2TDYWTH3XY3N5XPV","technical-job-search","Use this skill when a software engineer asks for help with job search tasks: parsing or analyzing a job description, tailoring a CV\u002Fresume, writing a cover letter, evaluating a job offer, or drafting a post-interview follow-up email. Do not activate for general career advice unrelated to an active job search action.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Ftechnical-job-search\u002FSKILL.md",[203,206,209],{"categoryNo":204,"categoryName":205,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":207,"categoryName":208,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":210,"categoryName":211,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000038","人力资源",[213,214,215,216,217,218,219,220,119,221,103,222,223,224,225,226,227,228,108,229],"search","Job Search","technical job search","technical","writing","tasks","email","parsing","interview","up","engineer","general","activate","do","task","cv","letter",{"skillNo":231,"name":232,"nameZh":6,"description":233,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":234,"categories":235,"keywords":236,"publishedAt":43},"01M6NMZFA67XYS1GS09WT42235","steno-mode","Shorthand-first response compression that cuts ~40% of response tokens while preserving technical precision and exact literals. Use when the user says \"steno mode\", \"shorthand mode\", \"compressed responses\", \"token reduction\", \"brief structured output\", or invokes \u002Fsteno. Supports four compression levels: lite, brief, court, machine. Do not trigger for requests needing polished prose such as onboarding\u002Ftutorial content, stakeholder or customer-facing copy, or teaching-focused explanations.","https:\u002F\u002Fgithub.com\u002FJiayiV\u002Fquestion_mixing\u002Fblob\u002Fmain\u002Fskills\u002Fsteno-mode\u002FSKILL.md",[],[237,238,239,240,241,216,242,103,226,243,244,245,246,247,248,249,250,251,108,252],"steno mode","mode","customer","brief","first","tutorial","teaching","tokens","as","trigger","structured output","machine","output","court","requests","response compression"]