Everything builders ask
The full set, grouped by topic. Click any question — one answer open at a time.
// positioning
No. It's a process engine. The wedge is the SDLC, not the code. Assistants do the middle 20%; nightshift runs the other 80% — spec, plan, review, and the handoffs between them.
Guardrail tools constrain the output at the edges. nightshift changes the process: each phase ends at a hard gate that returns control to you, so you approve the direction before code is written, not after.
// workflow & control
Only where you configure it. approval_mode is per-repo: assisted waits for you at every gate, auto waits only at spec and review, full-auto runs the whole pipeline on your standing config. The gates exist for you — not the other way around.
/auto triages by type and size. Bugs never get a spec or plan — straight to implementation. Stories at or under the lightweight threshold (default ≤3 points) skip the ceremony the same way. Only larger stories earn the full spec → plan → review path.
Only work you already approved. You refine and sign off stories by day; /auto picks them up, routes each by your config, and implements on its own branch. You wake up to PRs that answer acceptance criteria you agreed to — a result you set up, not a surprise.
Small stories skip the ceremony entirely, and the gates exist so you catch a wrong turn before it is built — which is faster than redoing it. No tokens spent building code you would have thrown away.
// setup & stack
The agents are fully generic. Every project-specific fact lives in one project-context.md file, plus optional per-agent override files. The same plugin runs across a Node monorepo, a Python service, or a mobile app — you configure it once per repo.
It's issue-tracker native: stories are read from Jira (via acli) and results are commented back to the ticket and the GitHub PR (via gh). Your tracker stays the source of truth — the paper trail lands where your team already works.
// trust & quality
Review is done by a different agent than the author, tests are the merge gate, and every stage leaves an artifact you can read — PRD, spec, plan, review. Nothing merges on vibes.
One readable document per phase: a PRD in docs/features/, a spec and plan in docs/superpowers/, review learnings in team memory, and a PR linked back to the ticket. Every decision is diffable.
// cost & license
Nothing. It's free and MIT-licensed. Adoption is the only metric we track.
It's built on open Claude Code primitives and MIT-licensed. Fork it, extend it, or swap out a role. There's no proprietary runtime to get stuck in.