choosing-a-stacklisted
Install: claude install-skill rkaliev/eng-kit
# Choosing a stack
Pick for **reliability in this domain**, not novelty. The best stack is the one that will still be supported, hireable and secure in five years, and that fits the platform and compliance constraints. **A stack choice is a fork: present options and ask the user.**
In an existing codebase the stack is already chosen. Use what is there (changing-legacy-code) unless the user explicitly asks for a migration.
## Process
1. **Collect constraints:**
- target platforms and OS floors;
- domain (payments, POS or regulated work raises the bar);
- team skills and existing company stacks;
- hosting and deployment target;
- offline needs, latency and scale;
- licensing and compliance (PCI DSS, personal-data law, fiscal law);
- integration SDKs that exist only for some platforms. Payment terminals, fiscal devices and vendor SDKs often decide it.
2. **Score 2–3 candidates** against these criteria:
- maturity and a supported LTS line;
- breadth of the ecosystem for the needed integrations;
- type safety;
- testability;
- security track record;
- team fit;
- operational cost;
- lock-in.
3. **Verify facts at the source.** Check the current LTS or stable versions, support windows and SDK requirements in the official docs or release pages. Never state them from memory.
4. **Recommend one**, with its trade-offs and what would change the decision. Record the decision (an ADR, see writing-documentation, or the spec) with the date and