Technical Feasibility

1. Collect inputs (documents, code, conversations, existing systems). [EXPLICIT]
2. Parse for requirements, constraints, and context. [EXPLICIT]

Phase 2: Analyze

1. Apply domain-specific analysis methodology. [EXPLICIT]
2. Tag all findings with evidence tags. [EXPLICIT]
3. Score/evaluate using the skill's specific metrics. [EXPLICIT]

Phase 3: Document

1. Produce the analysis deliverable in markdown. [EXPLICIT]
2. Include evidence tag summary (% by tag type). [EXPLICIT]
3. If >30% [ASSUMPTION], add WARNING banner. [EXPLICIT]

3. Inputs / Outputs

Validation Gate

• All findings have evidence tags
• Firebase feasibility assessed
• Deliverable follows R-008 output standards
• No implementation details (phase separation)
• Actionable recommendations included

5. Self-Correction Triggers

[!WARNING] IF >30% claims are [ASSUMPTION] THEN add prominent WARNING banner. IF analysis contains implementation details THEN move to plan (Art. 1.5 phase separation).

Usage

Example invocations:

• "/technical-feasibility" — Run the full technical feasibility workflow
• "technical feasibility on this project" — Apply to current context

Assumptions & Limits

• Assumes access to project artifacts (code, docs, configs) [EXPLICIT]
• Requires English-language output unless otherwise specified [EXPLICIT]
• Does not replace domain expert judgment for final decisions [EXPLICIT]

Edge Cases