Feasibility Study Skill
Supplementary Agent
For each solution option, dispatch background exploration:
Agent({
description: "Explore feasibility of solution option",
subagent_type: "feasibility-analyst",
prompt: Research the feasibility of: <solution description> Evaluate technical feasibility, effort, risk, extensibility, and maintenance cost.
})
Trigger
- Keywords: feasibility, is this possible, can we, should we, explore options, before tech spec
When NOT to Use
- Already have a tech spec (use
/deep-analyze) - Need implementation, not analysis (use
/codex-implement) - Quick question (use
/codex-explainor/codex-architect)
Workflow
Decompose → Constraints → Code research → Solutions → Codex discussion → Decision → Report
Phase 1: Requirement Decomposition
Input source priority:
- If
canonical_docs.requirementsis non-null → consume as authoritative requirement source, validate via 5-Why - Otherwise → extract requirements from user input via 5-Why analysis
Use "5 Why" to uncover essence:
- Surface requirement (what user asks for)
- Underlying problem (why they need it)
- Success criteria (quantifiable acceptance)
Phase 2: Constraint Analysis
Inventory constraints by type (Technical, Business, Resource, Compatibility) with flexibility rating.
Phase 3: Code Research
Research existing codebase:
- Related modules and reusable logic
- Existing design patterns
- Tech debt to work around
Phase 4: Solution Exploration
Brainstorm 2-3+ solutions, each with:
- Core idea (one sentence)
- Implementation path
- Quantified feasibility (see
references/analysis-phases.md) - Cost and trade-offs
Phase 5: In-Depth Codex Discussion
⚠️ Core step — not optional (unless --no-codex) ⚠️
See references/codex-discussion-guide.md for full rules and examples.
| Tool | Purpose | When |
|---|---|---|
/codex-brainstorm | Enumerate all options | At start |
/codex-architect | Evaluate design | After proposal forms |
mcp__codex__codex-reply | Ask details | Anytime |
Phase 6: Comparative Decision
Side-by-side comparison → recommendation + backup + open questions.
Evaluation Dimensions
| Dimension | Green | Yellow | Red |
|---|---|---|---|
| Technical Feasibility | Has existing patterns | Needs adaptation | Major innovation |
| Effort | < 3 person-days | 3-10 person-days | > 10 person-days |
| Risk | Small scope | Some uncertainty | Many unknowns |
| Extensibility | Easy to extend | Needs refactoring | Hard to extend |
| Maintenance Cost | Clean, easy | Some complexity | Complex |
Output
## Feasibility Study: <title>
### Quantitative Comparison
| Criterion | Option A | Option B | Option C |
|-----------|----------|----------|----------|
### Recommendation
<selected option with rationale>
Verification
- 5 Why decomposition completed
- Constraints inventoried with flexibility
- Existing code researched (grep/read)
- 2-3+ solutions explored with quantified assessment
- Codex discussion documented (unless
--no-codex) - Comparison table + recommendation + open questions
References
- Analysis phases:
references/analysis-phases.md - Codex discussion:
references/codex-discussion-guide.md - Output template:
references/output-template.md
Relationship with Other Commands
/feasibility-study → /tech-spec → /deep-analyze → /codex-implement
Examples
Input: /feasibility-study "Add user quota management"
Action: 5 Why → constraints → code research → 3 solutions → Codex discussion → recommendation
Input: /feasibility-study "Optimize cache" --context src/service/cache.ts
Action: Read cache code → constraints → solutions → Codex brainstorm → comparison → report