coalesce-labs/impact-sizing
plugins/pm/skills/impact-sizing/SKILL.md
Quantify feature value with driver trees, confidence levels, and the 4-step sizing framework.
$ install --global
skillsauthnpx skillsauth add coalesce-labs/catalyst impact-sizingInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 4, 2026, 3:22 PM4.8s1 file scanned
SKILL.md
- name:
- impact-sizing
- description:
- Quantify feature value with driver trees, confidence levels, and the 4-step sizing framework.
- disable-model-invocation:
- false
- user-invocable:
- true
/impact-sizing - Quantify Feature Value
Systematically estimate the impact of a feature using the 4-step framework.
Context Routing Logic (Internal - for Claude)
Automatic Context Checks: When this skill is invoked, immediately check:
| Source | Files/Folders | Search Terms | What to Extract |
| --------------- | ---------------------------------------------- | ------------------------------------- | --------------------------------------- |
| Current PRD | thoughts/shared/pm/prds/*.md | feature name from chat | User impact, problem severity |
| User Research | thoughts/shared/pm/*.md | feature problem, user quotes | Addressable users, pain severity |
| Business Model | thoughts/shared/pm/context/business-info-template.md | pricing, revenue model, TAM | Revenue impact drivers |
| Historical Data | thoughts/shared/pm/metrics/*.md | similar features, baseline conversion | Reference adoption rates |
| Strategy | thoughts/shared/pm/frameworks/*.md | feature strategic fit | Resource availability, priority context |
Context Priority:
- Feature definition and user impact FIRST
- Business model and pricing SECOND
- User base size and addressable segment THIRD
- Historical precedent for similar features FOURTH
Cross-Skill Links:
- If sizing is unclear → Link to
/impact-sizing(this skill) - If comparing options → Use this to inform
/experiment-decision - If building business case → Reference in PRD and
/write-prod-strategy - If identifying leading metrics → Connect to
/feature-metricsand/metrics-framework
Step 0: Understanding What We're Sizing
Before we estimate impact, let me check what context exists...
Checking:
thoughts/shared/pm/prds/for the feature definitionthoughts/shared/pm/for user research on this problemthoughts/shared/pm/context/business-info-template.mdfor business model contextthoughts/shared/pm/metrics/for comparable feature data
Based on what I find, I'll show you:
What We Know About This Feature
Feature Definition:
- [What problem does it solve?]
- [Who does it affect? Total addressable users: X]
- [User segment: SMB / Enterprise / Consumer / etc.]
User Impact:
- [Problem severity: from user research]
- [Expected behavior change: what users do differently]
- [Current workaround cost: time/money users waste today]
Business Context:
- [Revenue model: how does this make money?]
- [Existing similar features: what was their adoption?]
- [Resource constraints: time/team availability]
PM-Specific Diagnosis Questions
- Addressability: Can you reach the entire user population, or only a segment?
- Adoption Curve: Will this be immediate adoption or gradual ramp?
- Monetization: Is this a direct revenue play or indirect (retention/expansion)?
- Confidence: What data do you have vs what are you assuming?
- Execution Risk: What could go wrong with adoption or implementation?
When to Use
- Prioritizing features in planning
- Justifying resource allocation
- Building business cases for executives
- Comparing multiple feature options
The 4-Step Framework
Step 1: Estimate Usage (Funnel)
Create a funnel from exposure to usage:
Total users who see feature: [number]
↓ (Drop-off: [reason])
Users eligible for feature: [number]
↓ (Drop-off: [reason])
Users who engage: [number]
↓ (Drop-off: [reason])
Users who complete action: [number]
Gotchas to consider:
- How many users are actually eligible?
- How often will users be exposed?
- What's the expected adoption curve?
Step 2: Calculate Impact
Progress through three levels:
Engagement Impact:
- DAU/MAU change
- Retention rate change
- Session frequency/duration
Top-Line Impact:
- Revenue change
- GMV change
- Conversion rate change
Bottom-Line Impact:
- Contribution margin
- Customer acquisition cost
- Lifetime value change
Step 3: Identify & De-Risk Assumptions
For each assumption, assess risk and plan mitigation:
| Assumption | Confidence | Risk | De-risking Action | | ------------ | ------------ | --------------- | ----------------- | | [Assumption] | High/Med/Low | [Risk if wrong] | [Action] |
Common de-risking actions:
- Old data → Work with analytics for fresh numbers
- Usability question → Test with prototype
- Similar to competitors → Benchmark research
- Industry standard → Collect benchmarks
Step 4: Define Takeaways
Three buckets:
- Planning: Use for prioritization decisions
- Experiment Execution: Determine experiment duration for stat sig
- Feature Design: Identify levers to increase impact
Quick Start Prompt
When PM types /impact-sizing, respond:
Let's size the impact of your feature. I'll walk you through the 4-step framework.
**Step 1: Estimate Usage**
- What feature are we sizing?
- Who sees this feature? (total addressable users)
- What are the steps from seeing → using?
Once you share this, I'll help build the funnel and calculate impact.
Output Template
# Impact Sizing: [Feature Name]
## Usage Funnel
| Stage | Users | Drop-off Rate | Reason |
| ----------- | ----- | ------------- | -------- |
| See feature | [X] | - | - |
| Eligible | [X] | [Y%] | [reason] |
| Engage | [X] | [Y%] | [reason] |
| Complete | [X] | [Y%] | [reason] |
## Impact Estimates
**Engagement Impact:**
- Metric: [metric]
- Current: [baseline]
- Expected change: [+/- X%]
- Confidence: [High/Med/Low]
**Top-Line Impact:**
- Metric: [revenue/GMV]
- Expected change: [$X / +Y%]
- Confidence: [High/Med/Low]
**Bottom-Line Impact:**
- Metric: [margin/LTV]
- Expected change: [$X / +Y%]
- Confidence: [High/Med/Low]
## Confidence Assessment
| Assumption | Confidence | De-risking Action |
| ------------ | ---------- | ----------------- |
| [assumption] | [level] | [action] |
## Recommendation
[Proceed / De-risk first / Deprioritize]
Rationale: [why]
Driver Tree Example
Connect feature to business metrics:
Feature: [Name]
↓
[Engagement metric] +X%
↓
[Conversion metric] +Y%
↓
[Revenue metric] +$Z
↓
[Profit metric] +$W
Output Integration
Where Files Go
Impact sizing analysis:
- Save to:
thoughts/shared/pm/analyses/impact-sizing-[feature-name]-[date].md - When finalized: Reference in PRD in
Strategic Fitsection
Link to Other Work
After sizing impact:
- Reference in PRD - "Users affected: X, revenue impact: $Y, confidence: [High/Med/Low]"
- Use in prioritization - Helps decide if this should be in Q# roadmap
- Support pitches - Share with executives when requesting resources
- Inform metrics - Use impact estimates to set success metric targets
Cross-Skill Integration
Feeds into:
/prd-draft- Impact sizing goes into "Strategic Fit" section/write-prod-strategy- Feature impact informs strategic pillar priorities/feature-metrics- Usage estimates inform what metrics can detect changes/experiment-decision- Impact size determines experiment duration/sample size
Pulls from:
thoughts/shared/pm/- User pain and adoption patterns/user-research-synthesis- Qualitative insights about addressable users- [[business-info-template]] - Business model and growth drivers
thoughts/shared/pm/metrics/- Historical data on similar features
Tips
- Do the amount that fits your world - Few weeks? Address top assumption. More time? Go deeper.
- Never done - You can always upgrade the model as you learn more
- Connect to what matters - Executives care about revenue/profit, not engagement metrics alone
- Validate assumptions - The biggest unknowns are usually adoption rate and addressable market
- De-risking matters - Knowing what you don't know is worth more than precise wrong estimates
Output Quality Self-Check
Before presenting output to the PM, verify:
- [ ] File saved to correct location: Output saved to
thoughts/shared/pm/analyses/impact-sizing-[feature-name]-[date].md - [ ] Context routing table was checked: Reviewed
thoughts/shared/pm/context/business-info-template.md,thoughts/shared/pm/frameworks/, andthoughts/shared/pm/metrics/for relevant context - [ ] Driver tree has specific numbers: Every node in the driver tree contains actual estimates (not placeholders like "[X]" or "[number]")
- [ ] Confidence levels assigned: Each assumption in the confidence assessment table has a High/Med/Low rating with justification
- [ ] Revenue/user impact calculated with clear methodology: Impact estimates show the math (e.g., "10,000 eligible users x 30% adoption x $5 ARPU = $15,000/month"), not just final numbers
- [ ] De-risking actions identified: Every Low-confidence assumption has a specific, actionable de-risking step (not generic "do more research")
- [ ] Impact tied to strategic goal: The recommendation section explicitly references a strategic goal or OKR from
thoughts/shared/pm/frameworks/ - [ ] Sensitivity analysis included: Output shows best-case, worst-case, and expected-case scenarios with the key variable that drives the range
Related Skills
coalesce-labs/phase-remediate
testing
VerifiedTrustedCommunity
Phase-agent that fixes a failing verify verdict so the pipeline self-heals instead of stalling to needs-human (CTL-653). Reads `${ORCH_DIR}/workers/<ticket>/verify.json`, fixes the `findings[]` (every severity:"high" plus the regression_risk drivers) directly via Edit/Write, commits the remediation, and emits `phase.remediate.complete.<ticket>`. The scheduler's router then re-dispatches `verify` to re-check (the verify⇄remediate cycle, cap 3). Dispatched as a `claude --bg` job by `phase-agent-dispatch`, which invokes it via slash command — hence `user-invocable: true`.
13SKILL.mdUpdated May 28, 2026
coalesce-labs/phase-verify
development
VerifiedTrustedCommunity
Phase agent for the verify step of the 9-phase orchestrator pipeline (CTL-450). NEW skill — has no canonical wrapper. Runs read-only adversarial verification against the implement-phase diff: tsc, tests, lint, security scan, reward-hacking scan, code review, test coverage, silent-failure hunt. Writes ${ORCH_DIR}/workers/<TICKET>/verify.json then emits phase.verify.complete.<ticket>. Reads phase-implement.json as its prior-phase artifact. NEVER writes application code — only test files allowed. Spawned via phase-agent-dispatch via slash command — hence `user-invocable: true`.
13SKILL.mdUpdated May 18, 2026
coalesce-labs/plugins/dev/skills/phase-triage
tools
VerifiedTrustedCommunity
--- name: phase-triage description: Phase agent that triages a Linear ticket — expands acronyms, classifies (feature/bug/docs/refactor/chore), identifies dependencies, estimates scope, writes triage.json, and posts a triage analysis comment to Linear. Triage completion is signaled by that comment plus the local triage.json — there is no `triaged` label. Emits phase.triage.complete.<TICKET> on success and phase.triage.failed.<TICKET> on error. Dispatched by the phase-agent orchestrator (CTL-452)
13SKILL.mdUpdated May 18, 2026
coalesce-labs/phase-review
testing
VerifiedTrustedCommunity
Phase agent for the review step of the 9-phase orchestrator pipeline (CTL-450). Wraps the /review skill (gstack) — explicitly skips /ultrareview per user decision. Reads verify.json from the prior phase, runs /review against the diff, writes ${ORCH_DIR}/workers/<TICKET>/review.json, and creates a remediation commit for any HIGH-severity finding that has a deterministic fix. Emits phase.review.complete.<ticket>. Spawned via phase-agent-dispatch via slash command — hence `user-invocable: true`.
13SKILL.mdUpdated May 18, 2026