Tech Analysis
Skill for analyzing product features and mapping them to concrete technical solutions.
Input
- A product vision document or list of features to implement
Output
- Complete
TECH_STRATEGY.md document (use template in templates/)
[!CAUTION]
STRICT FILENAME ENFORCEMENT: You MUST name the output file exactly TECH_STRATEGY.md. Never deviate.
Process
Phase 1: Extract Features
- Read the input document
- List ALL mentioned features
- Identify required external integrations
Phase 2: Context Interview (Proactive)
Before mapping features to tech, ask the user:
- Do you (or your team) have experience with [platform] development?
- Is there existing code or a codebase we need to integrate with or follow?
- Do you have preferences for architecture patterns? (e.g., MVC, MVVM, Clean Arch — depends on platform)
- How many users/records do you expect? (scale hint for infra decisions)
- Do you have CI/CD set up already? (GitHub Actions, Bitrise, Jenkins, etc.)
Phase 3: Map Feature → Tech
For each feature, answer:
| Question |
Example |
| What component implements it? |
(e.g., Screen, Page, Controller, API endpoint, Service) |
| What library/framework does it need? |
(e.g., ORM, HTTP client, auth provider, UI framework) |
| Does it need persistence? |
(e.g., local DB, key-value store, cloud storage) |
| Does it need networking? |
REST API, WebSocket, GraphQL |
| Does it have UI? |
Yes → (e.g., Screen/Page/Component). No → (e.g., Background job/Service) |
Phase 4: Analyze Existing Code (if applicable)
If there is existing code:
- Identify patterns already in use (architecture, state management)
- List libraries/dependencies already included
- Document conventions to follow (naming, packaging, module structure)
- Note any tech debt or known issues
Phase 5: Evaluate Stack
Decide the tech stack based on:
- Platform defined in the input
- Team experience (from Phase 2 interview)
- Project complexity (don't over-engineer an MVP)
- Existing code patterns (if any, follow them)
Phase 6: Document Trade-offs
For each non-obvious technical decision:
- Why this option and not another?
- What risks does it have?
- What alternative exists if it fails?
Completeness Checklist
- □ Every feature has an assigned technical solution?
- □ Team experience assessed?
- □ Existing code analyzed (if any)?
- □ Architecture pattern chosen and justified?
- □ Stack is viable for the team and project?
- □ Trade-offs documented?
- □ Technical risks identified?
- □ Scale/performance considered?
Rules
- NEVER configure repos, IDEs, or write code — analysis only
- NEVER choose technology without justification
- ALWAYS consider at least 1 alternative per important decision
- If there's technical doubt → ask the user, don't assume
- STRICT FILENAME: Always output as
TECH_STRATEGY.md
1---2name: tech-analysis3description: How to map product features to technical solutions and define a tech strategy4---56# Tech Analysis78Skill for analyzing product features and mapping them to concrete technical solutions.910## Input11- A product vision document or list of features to implement1213## Output14- Complete `TECH_STRATEGY.md` document (use template in `templates/`)1516> [!CAUTION]17> **STRICT FILENAME ENFORCEMENT:** You MUST name the output file exactly `TECH_STRATEGY.md`. Never deviate.1819## Process2021### Phase 1: Extract Features221. Read the input document232. List ALL mentioned features243. Identify required external integrations2526### Phase 2: Context Interview (Proactive)27Before mapping features to tech, ask the user:28291. Do you (or your team) have experience with [platform] development?302. Is there existing code or a codebase we need to integrate with or follow?313. Do you have preferences for architecture patterns? (e.g., MVC, MVVM, Clean Arch — depends on platform)324. How many users/records do you expect? (scale hint for infra decisions)335. Do you have CI/CD set up already? (GitHub Actions, Bitrise, Jenkins, etc.)3435### Phase 3: Map Feature → Tech36For each feature, answer:3738| Question | Example |39|----------|---------|40| What component implements it? | (e.g., Screen, Page, Controller, API endpoint, Service) |41| What library/framework does it need? | (e.g., ORM, HTTP client, auth provider, UI framework) |42| Does it need persistence? | (e.g., local DB, key-value store, cloud storage) |43| Does it need networking? | REST API, WebSocket, GraphQL |44| Does it have UI? | Yes → (e.g., Screen/Page/Component). No → (e.g., Background job/Service) |4546### Phase 4: Analyze Existing Code (if applicable)47If there is existing code:481. Identify patterns already in use (architecture, state management)492. List libraries/dependencies already included503. Document conventions to follow (naming, packaging, module structure)514. Note any tech debt or known issues5253### Phase 5: Evaluate Stack54Decide the tech stack based on:551. **Platform** defined in the input562. **Team experience** (from Phase 2 interview)573. **Project complexity** (don't over-engineer an MVP)584. **Existing code patterns** (if any, follow them)5960### Phase 6: Document Trade-offs61For each non-obvious technical decision:62- Why this option and not another?63- What risks does it have?64- What alternative exists if it fails?6566## Completeness Checklist67- □ Every feature has an assigned technical solution?68- □ Team experience assessed?69- □ Existing code analyzed (if any)?70- □ Architecture pattern chosen and justified?71- □ Stack is viable for the team and project?72- □ Trade-offs documented?73- □ Technical risks identified?74- □ Scale/performance considered?7576## Rules771. **NEVER** configure repos, IDEs, or write code — analysis only782. **NEVER** choose technology without justification793. **ALWAYS** consider at least 1 alternative per important decision804. If there's technical doubt → ask the user, don't assume815. **STRICT FILENAME:** Always output as `TECH_STRATEGY.md`
gapfDev