feasibility-check

Generates a GO, CONDITIONAL GO, or DEFER feasibility verdict for feature specs before planning.

Updated Jul 9, 2026
One-click install
npx skills add https://github.com/ByronWilliamsCPA/plugin --skill feasibility-check-byronwilliamscpa
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: feasibility-check
Source: https://github.com/ByronWilliamsCPA/plugin/tree/main/plugins/wff-code/skills/feasibility-check
Command: npx skills add https://github.com/ByronWilliamsCPA/plugin --skill feasibility-check-byronwilliamscpa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often jump from brainstorming straight into implementation planning without validating whether a feature is actually buildable, leading to wasted planning effort on blocked or premature work. This Skill inserts a lightweight feasibility gate that produces a clear verdict in under five minutes. ## Core Features & Use Cases - Single-agent feasibility assessment: Dispatches one Sonnet agent with the feature spec to answer four targeted questions about assumptions, dependencies, MVP scope, and verdict. - Structured decision output: Saves a standardized Markdown report with a GO, CONDITIONAL GO, or DEFER verdict to docs/superpowers/feasibility/. - Clear next-step routing: Each verdict maps to an explicit action, such as proceeding to writing-plans or resolving blocking dependencies first. - Use Case: After brainstorming a new API integration feature, run this gate to discover that a third-party OAuth permission is missing, yielding a DEFER verdict before any planning time is spent. ## Quick Start Run a feasibility check on the feature spec we just brainstormed and tell me whether to proceed to planning.

Frequently Asked Questions about feasibility-check

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if a feature is feasible before planning?▼

Run a feasibility check that dispatches one agent with the feature spec to answer four questions about core assumptions, blocking dependencies, minimum buildable version, and verdict. The result is a GO, CONDITIONAL GO, or DEFER decision saved as a Markdown report.

When should I run a feasibility check in a development workflow?▼

Run it after brainstorming produces a spec and before writing implementation plans. Skip it for pure documentation changes, configuration updates, bug fixes with a clear root cause, or features estimated under two hours of work.

What is the difference between GO, CONDITIONAL GO, and DEFER verdicts?▼

GO means build as scoped and proceed to planning. CONDITIONAL GO means build only the MVP with documented conditions. DEFER means a prerequisite is missing and blocking dependencies must be resolved before re-running the check.

When should I skip a feasibility check?▼

Skip it for pure documentation or configuration changes, bug fixes with an identified root cause, and features estimated under two hours of work. The gate is designed for new features where assumptions and dependencies are unverified.

Where is the feasibility report saved?▼

The report is saved as a Markdown file at docs/superpowers/feasibility/<feature-slug>-feasibility.md. It includes the date, verdict, analysis of assumptions and dependencies, and a brief verdict rationale.