Stackkit

Stackkit is a TypeScript CLI for generating and maintaining multi-language monorepos. Most boilerplate generators stop after the first write; Stackkit is built around the longer lifecycle. It creates a managed Turborepo project from modules, presets, stack-axis flags (web, API, database, auth) or an offline recipe code, and records what it owns in .stackkit/project.json. Later commands (doctor, diff, info, add, remove, update, migrate and skills sync) read that manifest instead of guessing. The repo is a pnpm workspace of small packages with one direction of dependency: schemas, templates, core, registry and cli, plus a client-side Next.js customizer app that builds the create command visually.

• –Create from modules, presets, stack-axis flags such as --web next --api fastapi --db postgres --auth auth0, or an offline recipe code (stackkit recipe encode / create --recipe sk_...)
• –Dry-run mode that previews the plan and any planned file (--dry-run --view <path>) without writing anything
• –Managed projects: ownership is recorded in .stackkit/project.json with canonical module IDs, so stackkit doctor and stackkit diff --file can check generated files against what Stackkit wrote
• –Deterministic output: README.md, .env.example, root dev/build/test/typecheck/lint/format scripts and starter files are rendered from typed inputs, and the generated auth tests use a local mock JWT/JWKS adapter so no Auth0 tenant is needed
• –Module discovery and registry listing: module list, module search, module inspect --json, preset list and preset inspect
• –Lifecycle commands (add, remove, update, migrate), still alpha, plus resumable create (--resume, with --retry-initializers before re-running a step that may have left partial output)
• –AI skills for generated projects: project-local skill targets for Codex (.agents/skills) and Claude Code (.claude/skills), installed, planned, copied or symlinked with --skills and --skill-link
• –Client-side visual customizer that maps friendly technology choices to canonical modules, validates them with the core resolver, and outputs the copy-ready recipe command

• –Generators usually stop after the first write, which leaves nothing to check the project against later
• –One customizer and one CLI must agree on what is a valid stack, without duplicating module or preset logic in two places
• –Being honest about maturity: one preset is supported, runnable alternatives are marked preview, and declaration-only modules cannot be created yet
• –Multi-language output (a Next.js frontend and a FastAPI backend with Postgres and auth) has to be validated as a whole, not per template

Packages depend in one direction: schemas define the public data shapes, templates render file operations from typed inputs, core resolves modules, plans changes, checks safety, writes files and records manifests, registry declares modules and presets without writing anything, and cli owns commands, prompts and output. The create flow resolves, validates capabilities and conflicts, builds a plan, renders files, checks conflicts, writes, installs skills, writes the manifest and runs doctor. The customizer reads presets and support levels from the registry and uses the shared recipe and resolver code, so it only owns labels, icons and the mapping from choices to modules. CI runs a smoke test and a golden-path job that packs the CLI, generates the supported preset and runs the generated project's own test, typecheck, lint and build steps.

An early-alpha generator platform in a public monorepo, with one supported preset (Next.js, ShadCN, FastAPI, Postgres, SQLAlchemy, Auth0 and Docker), runnable preview alternatives, five runtime packages under the @berkayorhan npm scope, and a deployed customizer at stackkit-customizer.vercel.app that produces offline recipe commands. The goal is not a single fixed starter but a way to generate, check and evolve customizable monorepo boilerplates.