hit the ground
running.
your stack is the foundation.
Database, framework, test tooling: every choice in your stack shapes your developer experience and what you ship. stack-it takes you from an empty folder to a fully set-up stack. It brings you options and guidance at every step, and quietly handles the pesky install issues and incompatible choices along the way.
the first decisions are the heaviest
Everything you build stands on the stack you pick first. Get it right and the project flows; get it wrong and you feel the drag for months. But "getting it right" means clearing a gauntlet, before you've written a line of real code.
decision overload
Framework, database, ORM, test runner, linter, bundler, and a dozen more. Every slot is a fork, and they interact.
version churn
Last project's versions are already stale, and maybe there's a new framework you've been meaning to try. What's current, and is it actually stable yet?
compatibility traps
Two perfectly reasonable picks that simply will not run together, discovered three installs deep, after you've committed to both.
setup papercuts
Official install steps, interactive prompts, exact pins, peer ranges, secrets. None of it hard, all of it tedious, all of it easy to get subtly wrong.
you make the calls, stack-it does the legwork
stack-it leaves the decisions to you but helps you make them. First it works out the shape of the stack: a series of "slots," placeholders for the tools, frameworks, and languages your project needs. The foundation decision comes first, the language and framework that shape everything else; then it researches the remaining slots online in a sensible order and brings you the options. You choose, and it handles the pinning, vetting, installing, proving, and documenting in between. The orchestrator setup-stack runs the whole journey, commits a checkpoint after every stage, keeps a running task list so you can see what's left, and resumes from wherever you already are.
it brings you a short list, you decide
stack-it never picks behind your back. The keystone comes first: the language-and-framework choice that shapes every other slot, offered as a coupled pair so picking one never silently corners the other. Then it works through the rest in a sensible order. For each open slot it researches versions, maintenance, compatibility, and advisories, and surfaces two to four current options with the tradeoff that actually matters. You choose; then it pulls the install steps from the tool's official docs for that exact version, pins it, and re-checks for advisories. It honors your hard preferences from the start, and runs the heavy research on a leaner model to keep it fast and cheap.
It's the difference between a tool that decides for you and one that helps you decide well.
Relational, battle-tested, the safe default for almost any app with real data.
Zero-config and file-based. Great for local-first, small, or embedded apps.
Document store for flexible, evolving schemas and nested data.
researched per slot · tradeoffs surfaced · your choice pinned and re-vetted
the tedious, error-prone parts are the point
The setup work that's easy to get subtly wrong is exactly what stack-it takes off your plate. The riskiest part is the part you can't see: a dependency carrying a known CVE, or a version that was hijacked hours ago and pulled in before anyone noticed. So stack-it pins and security-vets every choice before anything touches your machine.
security, before it lands
Most setup risk is invisible until it isn't. stack-it does the security legwork on every dependency, so a vulnerable or compromised package doesn't ride into your project unnoticed.
CVE & advisory scan
stack-it checks every pick for CVEs, advisories, and significant open issues against GitHub Security Advisories and the language's advisory database, where one exists. Anything affecting your chosen version is flagged before you commit to it, not after it's in your lockfile.
exact pins, no loose ranges
Each tool is pinned to the exact version that was vetted, never a floating ^ or ~ range. A range is how one poisoned patch auto-installs across thousands of projects at once; pinning shuts that door and keeps every build reproducible.
fresh-release quarantine
A version published in the last couple of weeks gets an extra supply-chain pass. The classic attack is a hijacked maintainer account pushing a malicious release that's live for only hours, so stack-it prefers the last vetted version or waits out a quarantine window, npm's min-release-age and its equivalents elsewhere.
fresh releases wait their turn
incompatible choices, caught
When a check fails, stack-it works out whose fault it is. A wrong example it just fixes. A pin that won't resolve it bumps to the nearest patch and flags the drift. But two tools that fundamentally can't coexist is a stack fault, the only thing it stops on. It won't silently swap your choice; it surfaces the conflict and brings you back to re-decide that one slot.
from empty folder to running stack
Add the plugin, then let the orchestrator run the whole journey, or call any single stage on its own.
install
add the plugin
claude plugin marketplace add pricklywiggles/fractally-claude-marketplace claude plugin install stack-it@fractally-claude-marketplace
run
the whole journey, or one stage
/stack-it:setup-stack <input> // supports resume from last run > I'm making a colorful go cli with a great user experience, help me decide my stack > I'm starting a new editorial web project with cutting edge motion graphics for our company website, I need to decide my stack. > verify my installed stack works > document this project's stack
One resume-aware orchestrator, five stage skills you can call on their own, and a migrate utility for projects on an older layout.