---
name: rd-feasibility
description: >-
  Evaluate whether a project, product, open-source component, AI tool,
  infrastructure change, or candidate option is viable, and produce a
  decision-ready feasibility conclusion. Use when technical, economic, schedule,
  operational, security, compliance, and risk evidence must be compared before
  commitment. Route requirements, design, independent review, and execution to
  their owning workflows.
---

# rd-feasibility

Produce **decision-ready feasibility studies** that distinguish confirmed facts, assumptions, estimates, and unresolved verification needs.

## Deliverables

- Feasibility study / feasibility analysis report
- Feasibility comparison matrix
- Recommended conclusion: feasible / conditionally feasible / not feasible
- Risk register with mitigation and verification actions

## Execution Steps

### 1. Study Scope Confirmation

- Clarify the decision question: what needs to be judged feasible or infeasible
- Identify the decision stage when it changes the evidence needed: exploration, a bounded pilot, wider adoption, or production commitment
- Identify the target audience: decision-makers, project approval committee, client reviewers, technical leadership
- Confirm input sources: PRD, meeting notes, existing system documents, standards, policies, budgets, schedules
- Separate facts from assumptions before evaluating feasibility

**Completion criterion:** the decision question, relevant decision stage, comparison scope, audience, source set, facts, assumptions, and evidence gaps are explicit.

### 2. Feasibility Dimensions

Evaluate the option or project across these dimensions:

| Dimension | Check Content |
|-----------|---------------|
| Necessity and opportunity | problem value, policy/business driver, stakeholder demand, potential gains, and the cost of delaying or retaining the current approach |
| Technical feasibility | maturity, compatibility, integration constraints, data availability, architecture fit |
| Economic feasibility | budget, lifecycle cost, licensing, staffing, procurement |
| Schedule feasibility | milestones, dependencies, review cycles, delivery risks |
| Operational feasibility | installability, maintainability, staffing model, process fit, training, support and rollback |
| Security and compliance | regulations, standards, privacy, supply-chain exposure, security controls, auditability |
| Sustainability | upstream maintenance, release cadence, licensing, vendor or community dependency, future evolution, learning value, and exit path |
| Risk feasibility | high-risk assumptions, external dependencies, failure modes, fallback options |

**Completion criterion:** every material dimension is assessed against evidence or explicitly excluded with a reason; no missing dimension is silently treated as favorable.

### 3. Candidate Options

- Compare at least two options when a real choice exists
- Include the baseline option, such as maintaining the current process, when relevant
- Assess the baseline's costs and risks on the same basis as new options; distinguish promising hypotheses from options already supported for the proposed stage
- Explain why any option is excluded before detailed comparison
- Do not present a single preferred option as if alternatives do not exist

**Completion criterion:** every real option and relevant current-state baseline is either compared on common criteria or excluded with a documented basis.

### 4. Evidence and Estimation Discipline

- Cite source material for factual claims, version-sensitive facts, standards, and market or cost data
- Separate retrievable facts from owner-made decisions and record the authority for each accepted condition or risk
- Mark estimates as estimates and state the estimation basis
- If exact data is unavailable, use ranges and sensitivity analysis instead of false precision
- Clearly label unsupported assumptions and list how to verify them
- For open-source or AI-tool choices, distinguish repository activity from maintainability, demos from reproducible capability, and model capability from product or system capability

**Completion criterion:** every decision-material fact, estimate, and assumption is traceable to a source or estimation basis, or carries a verification action and an explicit effect on confidence.

### 5. Conclusion and Decision Advice

- Provide a clear verdict: feasible / conditionally feasible / not feasible
- State confidence level: high / medium / low
- Explain the minimum conditions required to proceed
- Recommend a bounded experiment or staged adoption when the evidence supports that step, with scope, resource limits, success and stop criteria, recovery, and evidence needed before expansion. Missing production evidence alone does not rule out a supported pilot; an unmet pilot-critical condition remains a condition or blocker
- List blocking issues, open questions, and recommended next actions

**Completion criterion:** the verdict is tied to the stated decision stage; confidence, proceed conditions, blockers, residual risks, and the next verification or adoption action follow from the comparison rather than from preference. A recommendation does not claim approval or execution.

## Context and Baseline Check

Pre-execution checks:

- Project feasibility report template or approval format
- Required financial, compliance, security, or standards review dimensions
- Existing PRD, project background, or stakeholder decision records
- Required terminology, glossary, or document numbering conventions

## Tool Selection

- Use `rd-research` only when material policy, standards, market, vendor, cost, or technical-maturity evidence gaps need focused research; reuse inspected evidence that remains current and applicable, and keep routine source checks within feasibility work
- Prefer primary sources and the narrowest configured retrieval capability
- Use library/API documentation retrieval only when current interface or compatibility facts affect feasibility
- Separate unavailable evidence from analysis and make the verification action explicit

## Quality Gates

Pre-delivery checklist:

- [ ] Decision question and scope are explicit
- [ ] Facts, assumptions, estimates, and unresolved questions are separated
- [ ] Material decisions and accepted risks identify their authority
- [ ] Core feasibility dimensions are covered or exclusions are justified
- [ ] At least two options are compared when a choice exists
- [ ] Key data and standards claims have source attribution
- [ ] Verdict, confidence, conditions, risks, and next actions match the decision stage; material opportunity costs and the evidence needed for expansion are visible
- [ ] Compatibility, lifecycle, security, support, and exit-path concerns are covered when technology adoption is in scope
- [ ] No fabricated cost, schedule, benchmark, policy, or standards claims

## Out of Scope

- Do not write detailed design or implementation instructions
- Do not invent financial figures, policy requirements, or standards clauses
- Do not hide infeasibility behind vague phrasing such as "basically feasible"
- Do not turn a feasibility conclusion into a commitment without listing conditions