[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QB4800EMDAQ5SD9DQHT5SR":3,"skill-same:01M6QB4800EMDAQ5SD9DQHT5SR":89},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":14,"repositoryHtmlUrl":69,"repositoryHomepageUrl":70,"ownerHtmlUrl":71,"ownerBlogUrl":72,"ownerDescription":73,"updatedAt":74,"install":75,"resources":88},"01M6QB4800EMDAQ5SD9DQHT5SR","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).","Tashima-Tarsh\u002FDisha6.6","Tashima-Tarsh","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F269906498?v=4","01M6PBH98X03XERH0HFT4PFB1P","NITISH KUMAR","01M6PBH9DA0M6KM3Z12P848F0K",0,"MIT","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcapacity-planner\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000040","财务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"capacity","planner","capacity planner","apply","gemini","for","manager","strategic","fte","erlang","director","time","use","coverage","plan","leader","team","Budget","engineering","run","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":49,"author":57,"license":15,"version":58,"description":7,"compatible_tools":59},[50,24,51,52,53,54,55,56],"bizops","headcount","utilization","queueing-theory","ops-planning","little-law","workforce","claude-code-skills","2.8.0",[60,61,62,63,64,65],"claude-code","codex-cli","cursor","antigravity","opencode","gemini-cli","main","0da4485785ee599388900be50db1635489d53056",".agents\u002Fskills\u002Fcapacity-planner","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6","https:\u002F\u002Fdisha6.6.thenitishkr.in\u002F","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh","www.thenitishkr","thenitishkr | AI • Cyber-security • Research\r\n","2026-11-08 03:33:25",{"source":8,"skillName":5,"commands":76,"prompt":86,"zipAvailable":87},[77,80,83],{"tool":78,"command":79},"npx","npx skills add Tashima-Tarsh\u002FDisha6.6 --skill capacity-planner",{"tool":81,"command":82},"bunx","bunx skills add Tashima-Tarsh\u002FDisha6.6 --skill capacity-planner",{"tool":84,"command":85},"pnpm","pnpm dlx skills add Tashima-Tarsh\u002FDisha6.6 --skill capacity-planner","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcapacity-planner\u002FSKILL.md",true,[],[90,121,143,170,193,217],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":101,"publishedAt":44},"01M6QRD07D4TGNDK6VJ4EHF8BV","youtube-full","Use when the user needs YouTube transcripts, video search, channel browsing, playlist extraction, or content monitoring. Trigger phrases: 'get the transcript for', 'search YouTube for', 'what are the latest videos on', 'list this playlist', 'monitor this channel', or any request involving a YouTube URL, video ID, or @handle. Do NOT use for downloading video or audio files, YouTube engagement data (likes, comments), or private\u002Fage-restricted videos.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fyoutube-full\u002FSKILL.md",[96],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,29,118,119,120],"youtube full","youtube","full","transcript","search","monitoring","data","Video","Audio","list","files","do","get","age","trigger","URL","browsing","request","youtube transcripts",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":44},"01M6QRCJ3112VYPA97YG7KGMC2","x-twitter-growth","X\u002FTwitter growth engine for building audience, crafting viral content, and analyzing engagement. Use when the user wants to grow on X\u002FTwitter, write tweets or threads, analyze their X profile, research competitors on X, plan a posting strategy, or optimize engagement. Complements social-content (generic multi-platform) with X-specific depth: algorithm mechanics, thread engineering, reply strategy, profile optimization, and competitive intelligence via web search.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fx-twitter-growth\u002FSKILL.md",[],[128,129,130,131,106,132,42,38,133,134,135,136,137,138,36,139,140,141,142,29],"twitter","x twitter growth","growth","research","content","web search","competitors","analyze","engine","write","strategy","platform","grow","posting","competitive",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":152,"publishedAt":44},"01M6QRBN3EHQNJY42RERP7A149","write-a-skill","Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, build, or author a new skill.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwrite-a-skill\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000023","Skill与智能体开发",[153,137,154,155,156,157,158,159,36,160,161,66,162,163,164,165,166,167,168,169],"write a skill","github","create","https","productivity","matt pocock","direct","example","build","new skill","structure","new agent","resources","with","tree","progressive disclosure","author",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":44},"01M6QRB6G8P33PNGAF9Y69EJ9T","wrap-up","Close out a launched Claude Managed Agent — recap every primitive the founder now owns, regenerate the single-file overview page, and suggest the next 1-2 upgrades. Use when the user says \"wrap up\", \"close this out\", \"what do I own now\", \"give me the summary\", \"recap the agent\", or when the orchestrator routes phase=wrap-up. primitives_inventory.py tables everything owned (agent, environment, session, memory, outcome, deployment); overview_page.py regenerates a self-contained .\u002Fmy-agent\u002Fagent-overview.html; upgrade_suggester.py ranks the next moves from recorded deferrals plus standing hardening steps. Companion to run-without-you; the last stop before phase=done.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fwrap-up\u002FSKILL.md",[],[177,178,179,28,180,43,181,182,183,36,184,113,185,186,187,188,189,190,191,192],"wrap up","up","wrap","deployment","file","hardening","closeout","stop","upgrade","founder","close","companion","you","tables","directions","phase",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":44},"01M6QRA5AYC1RBFZ39GTWGS3N8","workflow-builder","Design and write deterministic multi-agent workflow scripts (.js files in .claude\u002Fworkflows\u002F) for Claude Code's Workflow tool. Use when a user wants to build, create, author, scaffold, or run a custom Claude Code workflow, orchestrate sub-agents (fan-out, pipeline, loop, judge-panel), or automate a repeatable multi-step task across fresh-context agents.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fworkflow-builder\u002FSKILL.md",[199],{"categoryNo":150,"categoryName":151,"taxonomyType":99,"taxonomyTypeDesc":100},[201,202,203,204,205,155,43,206,207,208,209,210,137,211,112,212,213,214,215,216],"workflow","workflow builder","builder","design","workflows","code","orchestrate","pipeline","loop","multi-agent","context","across","fresh","scripts","judge","claude code workflow",{"skillNo":218,"name":219,"nameZh":6,"description":220,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":221,"categories":222,"keywords":223,"publishedAt":44},"01M6QR7QMCZESKQA0ERW1E657M","weekly-review","Use when someone wants to run a weekly review, close open loops, audit stalled projects and commitments, get their system back to trusted, restart a lapsed review habit, or says \"\u002Fcs:weekly-review\". Walks David Allen's three-phase loop — GET CLEAR, GET CURRENT, GET CREATIVE — with deterministic scripts that inventory open loops, gate the checklist with named gaps, and score commitment health 0-100.","https:\u002F\u002Fgithub.com\u002FTashima-Tarsh\u002FDisha6.6\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[224,225,226,227,228,229,230,231,40,209,232,233,234,235,236,237,114,238,239,192],"review","weekly review","weekly","deterministic scripts","reflect","feeds","inventory","open","projects","project-management","scanner","conversation","back","project","sprint","cadence"]