You are helping me define the technical stack for a new project.
Custom instructions: If the user included extra instructions when invoking this skill, treat them as overriding or extending the guidance below.
Read:
.docs/seed.md — project goals, target users, features, constraints.docs/assets/imgs/prototypes/ — if wireframes exist, check for technical implications (real-time features, drag-and-drop, file uploads, maps, etc.)
User preferences:
If I have stated preferences (framework, language, libraries), respect them and build around them. Don't argue for alternatives unless there's a clear compatibility issue or some major gain. If I haven't stated preferences, recommend based on the seed.
Your task:
Create a .docs/tech-stack.md file documenting all technical decisions for this project.
Guidelines:
Start from what's decided — If I've specified a framework or language, don't justify it. Focus on the surrounding choices: what complements it best.
Be specific:
- Exact packages/libraries, not categories (e.g., "shadcn/ui + Radix UI primitives" not "component library")
- Version numbers where relevant
- Use up-to-date information: look up latest stable versions and current best practices. Remember to use Context7's MCP if necessary.
Justify only what's not obvious:
- Why this database over that one? Why this auth provider?
- Skip justifications for standard choices (e.g., don't explain why TypeScript)
Consider the full stack:
- Don't assume frontend-only unless the seed says so
- Auth, database, deployment, hosting — if the project needs them, include them
- Development workflow: linting, formatting, testing framework
Keep it practical:
- What we need now, not what we might need later
- Prefer established, well-documented technologies
- Flag vendor lock-in risks and significant cost implications for scaling
- If the project is small/MVP, don't over-engineer
Output:
A complete .docs/tech-stack.md file. Organize by layer (frontend, backend, infrastructure, dev tools). Explain choices, don't just list them.
Logging: On success, append to .docs/changelog.md per .docs/changelog-spec.md: - YYYY-MM-DD HH:mm ran /stack — [brief description of what was decided].
1---2name: stack3description: Define the project's tech stack in .docs/tech-stack.md. Use only when the user explicitly asks to define the stack or runs /stack.4---56You are helping me define the technical stack for a new project.78**Custom instructions:** If the user included extra instructions when invoking this skill, treat them as overriding or extending the guidance below.910**Read:**1112- `.docs/seed.md` — project goals, target users, features, constraints13- `.docs/assets/imgs/prototypes/` — if wireframes exist, check for technical implications (real-time features, drag-and-drop, file uploads, maps, etc.)1415**User preferences:**16If I have stated preferences (framework, language, libraries), respect them and build around them. Don't argue for alternatives unless there's a clear compatibility issue or some major gain. If I haven't stated preferences, recommend based on the seed.1718**Your task:**19Create a `.docs/tech-stack.md` file documenting all technical decisions for this project.2021**Guidelines:**22231. **Start from what's decided** — If I've specified a framework or language, don't justify it. Focus on the surrounding choices: what complements it best.24252. **Be specific:**26 - Exact packages/libraries, not categories (e.g., "shadcn/ui + Radix UI primitives" not "component library")27 - Version numbers where relevant28 - Use up-to-date information: look up latest stable versions and current best practices. Remember to use Context7's MCP if necessary.29303. **Justify only what's not obvious:**31 - Why this database over that one? Why this auth provider?32 - Skip justifications for standard choices (e.g., don't explain why TypeScript)33344. **Consider the full stack:**35 - Don't assume frontend-only unless the seed says so36 - Auth, database, deployment, hosting — if the project needs them, include them37 - Development workflow: linting, formatting, testing framework38395. **Keep it practical:**40 - What we need now, not what we might need later41 - Prefer established, well-documented technologies42 - Flag vendor lock-in risks and significant cost implications for scaling43 - If the project is small/MVP, don't over-engineer4445**Output:**46A complete `.docs/tech-stack.md` file. Organize by layer (frontend, backend, infrastructure, dev tools). Explain choices, don't just list them.4748**Logging:** On success, append to `.docs/changelog.md` per `.docs/changelog-spec.md`: `- YYYY-MM-DD HH:mm ran /stack — [brief description of what was decided]`.
limonequantistico