agentleFS
Mathews-TomMathews-Tom/armory/skills/feasibility-assessor/SKILL.md

feasibility-assessor

Skill340 starsChanged 7 months agoMITView on GitHub

Evaluates whether a business idea is technically buildable and financially viable. Covers unit economics (CAC, LTV), revenue modeling, break-even, and go/no-go verdicts. Triggers on: "feasibility assessment", "viability analysis", "unit economics", "build vs buy", "go/no-go decision", "ROI projection".

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If critical inputs are missing, ask targeted clarifying questions before proceeding.

    line 33
  2. Distinctive:

    Run build vs buy vs partner analysis for each major component

    line 105

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Feasibility Assessor

Evaluate business ideas and features across two tracks: financial viability and technical feasibility. Produce an integrated verdict with actionable de-risking recommendations.

Phase 1: Input Classification

Determine the input type:

  • Idea pitch: informal description of a concept
  • Feature spec: defined requirements for a product addition
  • Repo/codebase: existing code to evaluate for extension or pivot
  • Business plan: structured document with financials

Extract from the input:

  1. Value proposition (what problem it solves, for whom)
  2. Target customer segment
  3. Pricing intent or revenue model
  4. Technology stack (stated or implied)
  5. Competitive landscape awareness

If critical inputs are missing, ask targeted clarifying questions before proceeding. Minimum viable inputs: value proposition and target customer.

Phase 2: Financial Analysis

Reference: references/unit-economics.md, references/financial-viability.md

Skip this phase only when the request is purely technical (e.g., "can we build X with Y stack").

Unit Economics

  1. Calculate Customer Acquisition Cost (CAC) — fully loaded: marketing spend + sales cost + overhead allocation per acquired customer
  2. Calculate Customer Lifetime Value (LTV) — ARPU multiplied by average customer lifetime, adjusted for gross margin
  3. Compute LTV:CAC ratio — minimum viable: 3:1
  4. Determine contribution margin per unit sold or per customer served
  5. Calculate payback period — months until cumulative gross profit from a customer exceeds CAC

State every assumption explicitly. Flag assumptions with high sensitivity (small change flips the outcome).

Revenue Modeling

  1. Identify all revenue streams and size each one
  2. Assess pricing strategy fit: cost-plus, value-based, competitive, freemium-to-paid
  3. Apply conversion rate assumptions — use industry benchmarks from reference material
  4. Model churn and retention — apply cohort decay curves where possible

Break-Even Analysis

  1. Separate fixed costs (rent, salaries, infrastructure baseline) from variable costs (COGS, transaction fees, support per user)
  2. Calculate break-even point in units, customers, or revenue
  3. Model three scenarios:
    • Pessimistic: 50th percentile conversion, high churn, slow growth
    • Base: industry-average assumptions
    • Optimistic: top-quartile performance

Path to Profitability

  1. Project gross margin trajectory over 12-24 months
  2. Model operating expense scaling (linear vs step-function vs economies of scale)
  3. Estimate funding requirements and runway at current burn
  4. Compare against industry benchmarks for time-to-profitability

Phase 3: Technical Analysis

Reference: references/technical-risk.md

Skip this phase only when the request is purely financial (e.g., "are the unit economics viable for a SaaS at $29/mo").

Architecture Assessment

Classify complexity:

LevelDescriptionExamples
1 — SimpleStandard CRUD, single serviceLanding page, basic CMS, form-based app
2 — ModerateMulti-service integration, auth, paymentsE-commerce, SaaS dashboard, API platform
3 — ComplexDistributed systems, real-time, high availabilityMarketplace, streaming platform, fintech
4 — NovelR&D required, unproven at scaleML-driven product, novel protocol, hardware+software

Evaluate:

  • Technology stack maturity and ecosystem support
  • Infrastructure requirements and cost scaling curve
  • Third-party dependency count and criticality

Build Estimation

  1. Define MVP scope — the minimum feature set that tests the core value proposition
  2. Estimate development timelines:
    • Optimistic: experienced team, known stack, minimal unknowns
    • Realistic: standard team, some learning curve, normal blockers
    • Pessimistic: new domain, integration challenges, regulatory overhead
  3. Identify required team skills and availability
  4. Run build vs buy vs partner analysis for each major component

Risk Scoring

Score each dimension 1-5 (1 = low risk, 5 = critical risk):

DimensionWhat It Measures
Technical noveltyProven tech (1) vs active R&D required (5)
Integration complexitySelf-contained (1) vs many external APIs (5)
Scale readinessArchitecture handles 100x with config changes (1) vs requires re-architecture (5)
Data riskPublic/owned data, no regulation (1) vs restricted data, heavy compliance (5)
Security/complianceNo sensitive data (1) vs PCI/HIPAA/SOC2 required (5)

Composite technical risk = weighted average. Flag any dimension scoring 4+ as a blocker requiring mitigation plan.

Phase 4: Integrated Feasibility Score

Financial Viability

  • Viable: LTV:CAC > 3:1, payback < 18 months, clear path to positive unit economics
  • Risky: LTV:CAC 1.5-3:1, payback 18-36 months, unit economics depend on scale
  • Not viable: LTV:CAC < 1.5:1, payback > 36 months, negative contribution margin

Technical Feasibility

  • Straightforward: complexity level 1-2, all risk dimensions < 3
  • Challenging: complexity level 2-3, one or two dimensions at 3-4
  • High-risk: complexity level 3-4, multiple dimensions at 4+
  • Research-grade: complexity level 4, any dimension at 5

Overall Verdict

FinancialTechnicalVerdict
ViableStraightforwardGreen — proceed
ViableChallengingYellow — proceed with caution, mitigate tech risks
RiskyStraightforwardYellow — validate financial assumptions first
RiskyChallengingYellow — high uncertainty, run cheap experiments
Not viableAnyRed — reconsider fundamentals
AnyHigh-risk/ResearchRed — reduce technical unknowns before committing

Assumption Sensitivity

Identify the top 3-5 assumptions that most influence the verdict. For each, state:

  • Current assumed value
  • Threshold value that would flip the assessment
  • How to validate cheaply

De-risking Recommendations

Rank experiments by cost-to-run vs information-value. Prioritize experiments that validate the riskiest assumptions at the lowest cost.

Phase 5: Report Generation

Structure the output as:

Executive Summary

  • One-paragraph verdict with go/no-go signal
  • Top 3 risks and top 3 strengths

Financial Dashboard (if applicable)

  • Unit economics table: CAC, LTV, LTV:CAC, contribution margin, payback period
  • Revenue projection under 3 scenarios (table or description)
  • Break-even point and timeline

Technical Scorecard (if applicable)

  • Complexity classification
  • Risk dimension scores (table)
  • MVP scope and timeline estimate
  • Critical dependencies and mitigation

Sensitivity Analysis

  • Which assumptions, if wrong, flip the verdict
  • Threshold values for each critical assumption

Recommended Next Steps

  • Ordered list of actions, cheapest validation first
  • Clear owners or skill requirements for each step
  • Decision gates: what evidence triggers proceed vs pivot vs stop

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.