skills/feasibility-assessor/SKILL.md
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".
npx skillsauth add mathews-tom/armory feasibility-assessorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Evaluate business ideas and features across two tracks: financial viability and technical feasibility. Produce an integrated verdict with actionable de-risking recommendations.
Determine the input type:
Extract from the input:
If critical inputs are missing, ask targeted clarifying questions before proceeding. Minimum viable inputs: value proposition and target customer.
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").
State every assumption explicitly. Flag assumptions with high sensitivity (small change flips the outcome).
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").
Classify complexity:
| Level | Description | Examples | | ------------ | ------------------------------------------------- | ---------------------------------------------------- | | 1 — Simple | Standard CRUD, single service | Landing page, basic CMS, form-based app | | 2 — Moderate | Multi-service integration, auth, payments | E-commerce, SaaS dashboard, API platform | | 3 — Complex | Distributed systems, real-time, high availability | Marketplace, streaming platform, fintech | | 4 — Novel | R&D required, unproven at scale | ML-driven product, novel protocol, hardware+software |
Evaluate:
Score each dimension 1-5 (1 = low risk, 5 = critical risk):
| Dimension | What It Measures | | ---------------------- | --------------------------------------------------------------------------------- | | Technical novelty | Proven tech (1) vs active R&D required (5) | | Integration complexity | Self-contained (1) vs many external APIs (5) | | Scale readiness | Architecture handles 100x with config changes (1) vs requires re-architecture (5) | | Data risk | Public/owned data, no regulation (1) vs restricted data, heavy compliance (5) | | Security/compliance | No 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.
| Financial | Technical | Verdict | | ---------- | ------------------ | ------------------------------------------------------ | | Viable | Straightforward | Green — proceed | | Viable | Challenging | Yellow — proceed with caution, mitigate tech risks | | Risky | Straightforward | Yellow — validate financial assumptions first | | Risky | Challenging | Yellow — high uncertainty, run cheap experiments | | Not viable | Any | Red — reconsider fundamentals | | Any | High-risk/Research | Red — reduce technical unknowns before committing |
Identify the top 3-5 assumptions that most influence the verdict. For each, state:
Rank experiments by cost-to-run vs information-value. Prioritize experiments that validate the riskiest assumptions at the lowest cost.
Structure the output as:
testing
Create, review, and restyle data visualizations using Edward Tufte principles: high data-ink ratio, direct labels, range-frame axes, small multiples, accessible color, responsive charts, and honest comparisons. Triggers on: "create a chart", "style this chart", "review this graph", "Tufte chart", "data visualization", "Recharts", "Plotly", "matplotlib", "Chart.js", "ECharts", "D3". Use when generating or critiquing charts, dashboards, sparklines, and data tables.
testing
Manages dependent branch stacks and stacked pull requests using safe Git topology rules. Triggers on: "create stacked PRs", "publish this stack", "sync my PR stack", "rebase this stack", "merge the stack", "retarget child PRs", "split this branch into stacked PRs", "validate this stack", "cleanup stacked branches". Use when local branches or one source branch need to become a dependency-ordered PR stack with correct parent bases, validation, synchronization, merge order, and cleanup.
development
Scaffolds per-repository agent context so coding agents share the same issue tracker rules, triage label vocabulary, domain glossary, ADR layout, and handoff conventions. Triggers on: "set up project context", "configure agent docs", "create CONTEXT.md", "setup agent workflow", "agent issue tracker setup", "triage labels", "domain glossary for agents". Use when a repo needs durable context files before planning, triage, debugging, TDD, architecture review, or multi-agent implementation.
testing
Produces phased task boards from feature requests: dependency-mapped work items, parallelization flags, risk flags, edge cases, test matrices. Triggers on: "decompose this feature", "task breakdown with dependencies", "phased implementation plan", "work breakdown structure". NOT for effort estimates, use estimate-calibrator.