---
title: "feasibility"
description: "<objective> Assess feasibility of $ARGUMENTS (or the current topic if no arguments provided)."
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/feasibility
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:24:31.408Z
license: CC-BY-4.0
attribution: "feasibility — Claudary (https://claudary.paisolsolutions.com/skills/feasibility)"
---

# feasibility
<objective> Assess feasibility of $ARGUMENTS (or the current topic if no arguments provided).

## Overview

---
description: Reality check - can we actually do this with our constraints?
argument-hint: [idea/project or leave blank for current context]
---

<objective>
Assess feasibility of $ARGUMENTS (or the current topic if no arguments provided).

Honest reality check: can we actually do this given technical, resource, and external constraints?
</objective>

<intake_gate>

<context_analysis>
First, analyze $ARGUMENTS to extract what's already provided:
- What's being assessed
- Known constraints (budget, API limits, external dependencies)
- Technical requirements
- Risk tolerance

Only ask about genuine gaps - don't re-ask what's already stated.
</context_analysis>

<initial_questions>
Use AskUserQuestion to ask 2-4 questions based on actual gaps:

**If constraints unclear:**
- "Any hard constraints?" with options: Budget limits, API/service restrictions, Must use specific tech, No major constraints, Other

**If complexity unclear:**
- "How complex is this?" with options: Small (few components), Medium (multiple systems), Large (significant architecture), Not sure, Other

**If dependencies unclear:**
- "External dependencies?" with options: Third-party APIs, External services, Other projects, None significant, Other

**If risk tolerance unclear:**
- "How certain do you need to be?" with options: High confidence required, Moderate risk OK, Willing to experiment, Other

Skip questions where $ARGUMENTS already provides the answer.
</initial_questions>

<decision_gate>
After receiving answers, use AskUserQuestion:

Question: "Ready to assess feasibility, or would you like me to ask more questions?"

Options:
1. **Start assessment** - I have enough context
2. **Ask more questions** - There are details to clarify
3. **Let me add context** - I want to provide additional information

If "Ask more questions" → generate 2-3 contextual follow-ups, then present decision gate again
If "Let me add context" → receive input, then present decision gate again
If "Start assessment" → proceed to research
</decision_gate>

</intake_gate>

<process>
After intake complete:

1. Define what we're assessing
2. Evaluate technical feasibility
3. Evaluate resource feasibility
4. Evaluate external dependency feasibility
5. Identify blockers and de-risking strategies
6. Make go/no-go recommendation
</process>

<output_format>
## Feasibility Assessment: [Project/Idea]

### Strategic Summary
[2-3 sentences: verdict, main concern, key condition for success]

### What we're assessing
[Clear description of the proposed project/feature]

### Technical Feasibility
**Can we build it?**
- Known approaches: [Yes/Partial/No] - [details]
- Technology maturity: [Proven/Emerging/Experimental]
- Technical risks: [List with severity]
- **Technical verdict:** Feasible / Risky / Not feasible

### Resource Feasibility
**Do we have what we need?**
- Skills: [Have/Need to learn]
- Budget: [Sufficient/Tight/Insufficient]
- Tools/infrastructure: [Have/Need to acquire]
- **Resource verdict:** Feasible / Risky / Not feasible

### External Dependency Feasibility
**Are external factors reliable?**
- APIs/services: [Available/Reliable/Rate limits]
- Third-party integrations: [Stable/Risky]
- External data: [Accessible/Restricted]
- **External verdict:** Feasible / Risky / Not feasible

### Blockers
| Blocker | Severity | Mitigation |
|---------|----------|------------|
| [Blocker] | High/Med/Low | [How to address] |

### De-risking Options
- [Option]: [How it reduces risk, what it costs]
- [Option]: [How it reduces risk, what it costs]

### Overall Verdict
**[Go / Go with conditions / No-go]**

[Reasoning and key conditions]

### Implementation Context
<claude_context>
<if_go>
- approach: [recommended technical approach]
- start_with: [first thing to build/validate]
- critical_path: [what must work for this to succeed]
</if_go>
<risks>
- technical: [main technical risks]
- external: [main dependency risks]
- mitigation: [how to address each]
</risks>
<alternatives>
- if_blocked: [fallback approaches if primary fails]
- simpler_version: [reduced scope that's definitely feasible]
</alternatives>
</claude_context>

**Next Action:** Address blockers, reduce scope, prototype critical path, or proceed to /plan/project

### Sources
- [Source name]: [URL] - [date accessed]
- [Source name]: [URL] - [date accessed]
</output_format>

<artifact_output>
Save the research to a file:

1. Create directory structure if it doesn't exist:
   - `[current-working-directory]/artifacts/research/`

2. Generate filename from topic:
   - Get current date in YYYY-MM-DD format
   - Slugify the topic (lowercase, hyphens for spaces)
   - Format: `YYYY-MM-DD-[topic]-feasibility.md`
   - Example: `2025-01-15-native-app-migration-feasibility.md`

3. Write the complete research to the file

4. Report to user: "Saved to `artifacts/research/[filename]`"
</artifact_output>

<success_criteria>
- Assessment is honest (not optimistic or pessimistic)
- All dimensions evaluated (technical, resource, external)
- Blockers are specific and addressable
- De-risking options are actionable
- Verdict is clear with reasoning
- Implementation context gives Claude clear path forward
- Enables informed go/no-go decision
- Output saved to artifacts/research/ directory
</success_criteria>

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/feasibility) · https://claudary.paisolsolutions.com