hit the ground
running.
your stack is the foundation.
From the database to the framework to the test tooling, every choice in your stack shapes your developer experience, your performance, and your results. stack-it takes you from an empty folder to a fully set-up stack, giving you options and guidance at every step and quietly handling 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. Then it settles the foundation decision first (the language and framework that shape everything else) and researches the remaining slots online in a sensible order, bringing 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. It settles the keystone 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 works through the rest in a sensible order. For each open slot it researches the field (versions, maintenance, compatibility, advisories) and surfaces two to four current options with the tradeoff that actually matters. You choose; then it pulls the exact install steps from the tool's official docs for that exact version, pins it, and re-checks for advisories. Hard preferences are honored from the start, and the heavy research runs 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 before anything touches your machine, every choice is pinned and security-vetted.
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
Every pick is checked 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. Those ranges are 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 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 records. 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 plus five standalone, individually callable stage skills.