feasibility-study
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
More from sd0xdev/sd0x-dev-flow
statusline-config
Customize Claude Code statusline. Use when: user says 'statusline', 'status line', 'customize statusline', 'modify statusline', 'statusline settings', 'statusline theme', 'change theme', 'color scheme', wants to add/remove/change segments (cost, git, model, context), switch color themes (catppuccin, dracula, nord), or asks what can be shown in the statusline.
52tech-spec
Tech spec generation and review. Use when: designing features, writing specs, spec review. Not for: requirements analysis (use req-analyze), implementation (use feature-dev), architecture advice (use codex-architect). Output: numbered tech spec document.
45codex-brainstorm
Adversarial brainstorming via Claude+Codex debate. Use when: exploring solutions, feasibility analysis, exhaustive enumeration. Not for: implementation (use feature-dev), architecture only (use codex-architect). Output: Nash equilibrium consensus + action items.
7security-review
Security review via Codex MCP. Use when: OWASP Top 10 audit, dependency vulnerability check, security-sensitive changes. Not for: code review (use codex-code-review), test review (use test-review). Output: security findings + audit report.
7test-review
Test coverage review via Codex MCP. Use when: reviewing test sufficiency, identifying coverage gaps, test quality audit. Not for: generating tests (use codex-test-gen), code review (use codex-code-review). Output: coverage analysis + gap report.
7post-dev-test
Post-development test completion. Use when: checking test coverage after feature-dev, writing missing integration/e2e tests. Not for: unit test generation (use codex-test-gen), test review (use test-review). Output: test files + coverage report.
6