/project-sizing-guide
Software project effort estimation assistant. Outputs three-point estimates (optimistic/most-likely/pessimistic values with confidence intervals), T-shirt sizes, or Function Point Analysis (FPA) counts. Triggered when users ask 'how long will this feature take,' need to assess
$ npx -y skills add zebbern/claude-code-guide --skill project-sizing-guide --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/project-sizing-guide
Context preview
The summary Claude sees to decide when to auto-load this skill.
Software project effort estimation assistant. Outputs three-point estimates (optimistic/most-likely/pessimistic values with confidence intervals), T-shirt sizes, or Function Point Analysis (FPA) counts. Triggered when users ask 'how long will this feature take,' need to assess
SKILL.md
project-sizing-guide.SKILL.mdname: project-sizing-guide
description: "Software project effort estimation assistant. Outputs three-point estimates (optimistic/most-likely/pessimistic values with confidence intervals), T-shirt sizes, or Function Point Analysis (FPA) counts. Triggered when users ask 'how long will this feature take,' need to assess project workload, perform PERT estimation, T-shirt sizing, FPA, sprint planning, or quote-based effort breakdowns."
license: MIT
Project Sizing Guide — Software Project Effort Estimation
Helps teams produce scientifically grounded effort estimates for software projects, based on three major methodologies: Three-Point Estimation (PERT), T-shirt Sizing, and Function Point Analysis (FPA). Outputs optimistic, most-likely, and pessimistic values along with risk intervals.
Quick Start
1. **User provides a requirements description** → Agent identifies functional modules and breaks them into a Work Breakdown Structure (WBS) 2. **Select an estimation method** → Choose the best-fit approach based on project stage and available information 3. **Estimate each item** → Assign O/M/P (Optimistic / Most Likely / Pessimistic) values to every work package 4. **Aggregate and report** → Generate an estimation report with risk analysis and confidence intervals
A calculation helper is available:
python3 scripts/estimate_calculator.py --method pert --tasks '[{"name":"User Login","O":2,"M":3,"P":8}]'---
Method Selection Guide
| Scenario | Recommended Method | Rationale | |----------|-------------------|-----------| | Early feasibility study, rough budgeting | T-shirt Sizing | Little information available; quickly align on order of magnitude | | Sprint planning, iteration estimation | Three-Point Estimation (PERT) | Good granularity with confidence intervals | | Contract bidding, large-project RFPs | Function Point Analysis (FPA) | Most rigorous; industry-comparable | | Team has historical data | PERT + historical calibration | Combines empirical correction with data |
---
Method 1: Three-Point Estimation (PERT)
Core Formulas
| Metric | Formula | Meaning | |--------|---------|---------| | Expected Value E | (O + 4M + P) / 6 | Weighted average effort | | Standard Deviation σ | (P − O) / 6 | Estimation uncertainty | | Variance V | σ² | Used to aggregate across tasks | | Project Total Expected | ΣE | Sum of individual expected values | | Project Total Std Dev | √(ΣV) | Square root of summed variances |
Where:
- **O** (Optimistic): Shortest duration assuming everything goes smoothly
- **M** (Most Likely): Duration under normal circumstances
- **P** (Pessimistic): Longest duration when significant difficulties arise
Confidence Intervals
| Confidence Level | Interval | Use Case | |-----------------|----------|----------| | 68.3% | E ± 1σ | Internal rough estimates | | 90% | E ± 1.645σ | Project planning | | 95% | E ± 2σ | External quotes | | 99.7% | E ± 3σ | Contractual commitments |
Steps
1. **Build the WBS**: Decompose requirements into the smallest independently estimable units (recommended ≤ 5 person-days each) 2. **Three-point estimation**: For each work package, provide O / M / P values (use consistent units: person-hours or person-days) 3. **Calculate per-task expected value and standard deviation** 4. **Aggregate project-level metrics**: Total Expected = ΣE, Total Std Dev = √(Σσ²) 5. **Output confidence intervals**: Choose a confidence level based on risk appetite
O/M/P Estimation Rules of Thumb
- O should not be less than 30% of M (overly optimistic suggests essential steps were overlooked)
- P should not exceed 5× M (overly pessimistic suggests unclear requirements that need clarification first)
- If O ≈ M ≈ P, the task is either extremely well-understood or the estimator hasn't seriously considered risks
- The P/O ratio (spread ratio) reflects uncertainty: < 2 = low risk, 2–4 = medium risk, > 4 = high risk
---
Method 2: T-shirt Sizing
Size Reference Table
| Size | Typical Range (person-days) | Typical Story Points | Suitable For | |------|----------------------------|---------------------|--------------| | XS | 0.25 – 0.5 | 1 | Config changes, copy edits, simple bug fixes | | S | 0.5 – 2 | 2 – 3 | Single-component development, simple API, minor UI tweaks | | M | 2 – 5 | 5 – 8 | Complete feature module, moderately complex API | | L | 5 – 15 | 13 – 21 | Cross-module features requiring integration | | XL | 15 – 40 | 34 – 55 | Subsystem-level development requiring architecture design | | XXL | 40+ | 89+ | Should be split across multiple iterations; not recommended as a single estimation unit |
Converting T-shirt Sizes to Three-Point Estimates
When more precise numbers are needed, T-shirt sizes can be converted to three-point estimates:
| Size | O (person-days) | M (person-days) | P (person-days) | |------|-----------------|-----------------|-----------------| | XS | 0.25 | 0.5 | 1 | | S | 0.5 | 1 | 2.5 | | M | 2 | 3.5 | 7 | | L | 5 | 10 | 20 | | XL | 15 | 25 | 50 | | XXL | 40 | 70 | 150 |
Steps
1. **Team alignment**: Confirm what each size means (the table above is a reference; teams may customize) 2. **Independent assessment**: Each person assigns a size independently to avoid anchoring bias 3. **Discuss discrepancies**: When estimates differ by more than 2 sizes, a discussion is mandatory 4. **Reach consensus**: Adopt the team consensus value 5. **Convert to numbers** (optional): Use the table above to derive O/M/P values
---
Method 3: Function Point Analysis (FPA)
Five Function Component Types
| Component Type | Abbreviation | Definition | Example | |---------------|-------------|-----------|---------| | Internal Logical File | ILF | Logical data group maintained by the application | Users table, Orders table | | External Interface File | EIF | Data group referenced but not maintained by the application | Third-party exchange rate data | | External Input | EI | Data processing entering the syste
Read more
name: project-sizing-guide description: "Software project effort estimation assistant. Outputs three-point estimates (optimistic/most-likely/pessimistic values with confidence intervals), T-shirt sizes, or Function Point Analysis (FPA) counts. Triggered when users ask 'how long will this feature take,' need to assess project workload, perform PERT estimation, T-shirt sizing, FPA, sprint planning, or quote-based effort breakdowns." license: MIT
Project Sizing Guide — Software Project Effort Estimation
Helps teams produce scientifically grounded effort estimates for software projects, based on three major methodologies: Three-Point Estimation (PERT), T-shirt Sizing, and Function Point Analysis (FPA). Outputs optimistic, most-likely, and pessimistic values along with risk intervals.
Quick Start
1. **User provides a requirements description** → Agent identifies functional modules and breaks them into a Work Breakdown Structure (WBS) 2. **Select an estimation method** → Choose the best-fit approach based on project stage and available information 3. **Estimate each item** → Assign O/M/P (Optimistic / Most Likely / Pessimistic) values to every work package 4. **Aggregate and report** → Generate an estimation report with risk analysis and confidence intervals
A calculation helper is available:
python3 scripts/estimate_calculator.py --method pert --tasks '[{"name":"User Login","O":2,"M":3,"P":8}]'---
Method Selection Guide
| Scenario | Recommended Method | Rationale | |----------|-------------------|-----------| | Early feasibility study, rough budgeting | T-shirt Sizing | Little information available; quickly align on order of magnitude | | Sprint planning, iteration estimation | Three-Point Estimation (PERT) | Good granularity with confidence intervals | | Contract bidding, large-project RFPs | Function Point Analysis (FPA) | Most rigorous; industry-comparable | | Team has historical data | PERT + historical calibration | Combines empirical correction with data |
---
Method 1: Three-Point Estimation (PERT)
Core Formulas
| Metric | Formula | Meaning | |--------|---------|---------| | Expected Value E | (O + 4M + P) / 6 | Weighted average effort | | Standard Deviation σ | (P − O) / 6 | Estimation uncertainty | | Variance V | σ² | Used to aggregate across tasks | | Project Total Expected | ΣE | Sum of individual expected values | | Project Total Std Dev | √(ΣV) | Square root of summed variances |
Where:
- **O** (Optimistic): Shortest duration assuming everything goes smoothly
- **M** (Most Likely): Duration under normal circumstances
- **P** (Pessimistic): Longest duration when significant difficulties arise
Confidence Intervals
| Confidence Level | Interval | Use Case | |-----------------|----------|----------| | 68.3% | E ± 1σ | Internal rough estimates | | 90% | E ± 1.645σ | Project planning | | 95% | E ± 2σ | External quotes | | 99.7% | E ± 3σ | Contractual commitments |
Steps
1. **Build the WBS**: Decompose requirements into the smallest independently estimable units (recommended ≤ 5 person-days each) 2. **Three-point estimation**: For each work package, provide O / M / P values (use consistent units: person-hours or person-days) 3. **Calculate per-task expected value and standard deviation** 4. **Aggregate project-level metrics**: Total Expected = ΣE, Total Std Dev = √(Σσ²) 5. **Output confidence intervals**: Choose a confidence level based on risk appetite
O/M/P Estimation Rules of Thumb
- O should not be less than 30% of M (overly optimistic suggests essential steps were overlooked)
- P should not exceed 5× M (overly pessimistic suggests unclear requirements that need clarification first)
- If O ≈ M ≈ P, the task is either extremely well-understood or the estimator hasn't seriously considered risks
- The P/O ratio (spread ratio) reflects uncertainty: < 2 = low risk, 2–4 = medium risk, > 4 = high risk
---
Method 2: T-shirt Sizing
Size Reference Table
| Size | Typical Range (person-days) | Typical Story Points | Suitable For | |------|----------------------------|---------------------|--------------| | XS | 0.25 – 0.5 | 1 | Config changes, copy edits, simple bug fixes | | S | 0.5 – 2 | 2 – 3 | Single-component development, simple API, minor UI tweaks | | M | 2 – 5 | 5 – 8 | Complete feature module, moderately complex API | | L | 5 – 15 | 13 – 21 | Cross-module features requiring integration | | XL | 15 – 40 | 34 – 55 | Subsystem-level development requiring architecture design | | XXL | 40+ | 89+ | Should be split across multiple iterations; not recommended as a single estimation unit |
Converting T-shirt Sizes to Three-Point Estimates
When more precise numbers are needed, T-shirt sizes can be converted to three-point estimates:
| Size | O (person-days) | M (person-days) | P (person-days) | |------|-----------------|-----------------|-----------------| | XS | 0.25 | 0.5 | 1 | | S | 0.5 | 1 | 2.5 | | M | 2 | 3.5 | 7 | | L | 5 | 10 | 20 | | XL | 15 | 25 | 50 | | XXL | 40 | 70 | 150 |
Steps
1. **Team alignment**: Confirm what each size means (the table above is a reference; teams may customize) 2. **Independent assessment**: Each person assigns a size independently to avoid anchoring bias 3. **Discuss discrepancies**: When estimates differ by more than 2 sizes, a discussion is mandatory 4. **Reach consensus**: Adopt the team consensus value 5. **Convert to numbers** (optional): Use the table above to derive O/M/P values
---
Method 3: Function Point Analysis (FPA)
Five Function Component Types
| Component Type | Abbreviation | Definition | Example | |---------------|-------------|-----------|---------| | Internal Logical File | ILF | Logical data group maintained by the application | Users table, Orders table | | External Interface File | EIF | Data group referenced but not maintained by the application | Third-party exchange rate data | | External Input | EI | Data processing entering the syste
Claude Code Guide - Setup, Commands, workflows, agents, skills & tips-n-tricks from beginner to power user!
Repo: zebbern/claude-code-guide
Other skills on claude-code-guide.
- /academic-paper-reviewer
Simulates academic peer review, evaluating papers across Originality, Methodology, Results, and Writing to provide Major/Minor Revision recommendations with actionable feedback. Triggers when a user asks to \"review my paper,\" \"simulate peer review,\" or \"give my paper a peer
Open skill - /active-directory-attacks
This skill should be used when the user asks to "attack Active Directory", "exploit AD", "Kerberoasting", "DCSync", "pass-the-hash", "BloodHound enumeration", "Golden Ticket", "Silver Ticket", "AS-REP roasting", "NTLM relay", or needs guidance on Windows domain penetration
Open skill - /api-fuzzing-bug-bounty
This skill should be used when the user asks to "test API security", "fuzz APIs", "find IDOR vulnerabilities", "test REST API", "test GraphQL", "API penetration testing", "bug bounty API testing", or needs guidance on API security assessment techniques.
Open skill - /api-shape-explorer
Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
Open skill - /audit-flow
Interactive system flow tracing across CODE, API, AUTH, DATA, NETWORK layers with SQLite persistence and Mermaid export. Use for security audits, compliance documentation, flow tracing, feature ideation, brainstorming, debugging, architecture reviews, or incident post-mortems.
Open skill - /authentication-patterns
Authentication patterns: session vs JWT vs OAuth comparison, provider selection (NextAuth, Clerk, Supabase Auth), security checklist, and common mistakes. Use when implementing auth, reviewing auth flows, or choosing auth providers.
Open skill

