sdlc

⭐ If this saves you a sprint, star the repo. It's how other builders find it.

The problem

You don't lose time writing code. You lose it in the connective tissue around it: turning a vague ticket into a real spec, breaking that spec into a plan, keeping the plan honest while you implement, then reviewing it without rubber-stamping your own work.

AI coding assistants are great at the middle 20%. nightshift automates the other 80% — the process — by giving Claude Code a team of specialized agents that each own one stage of the lifecycle and hand off cleanly to the next.

What it is

nightshift is a Claude Code plugin marketplace. Its flagship plugin, sdlc, installs a repo-agnostic software-delivery team:

• 11 specialized agents — one per role, each with a tight charter and clean handoff protocol.
• 10 slash commands — the whole lifecycle, one verb at a time: /spec, /plan, /impl, /review, plus a one-shot /auto.
• Issue-tracker native — reads a ticket, derives the branch, the plan path, the PR. Closes the loop back to Jira/GitHub.
• Zero hardcoding — every project-specific fact (stack, paths, Jira key, base branch) lives in one config file per repo. The agents are 100% generic. Install once, use everywhere.

It is not a wrapper that "writes code for you." It's a process engine that makes a senior team's discipline the default — spec before plan, plan before code, review before merge, tests as the gate.

⚡ Install in 60 seconds

In any Claude Code session:

/plugin marketplace add whimzyLive/nightshift-ai
/plugin install sdlc@nightshift

That's it. The shared workflow skills it depends on (superpowers) install automatically — nightshift declares them as a cross-marketplace dependency, so an existing install is reused and a missing one is pulled in for you. No duplicate copies, no version juggling.

Prerequisites: Claude Code, plus the acli (Jira) and gh (GitHub) CLIs for the ticket/PR integrations. Both are optional if you only want the spec/plan/impl/review flow locally.

🚀 60-second demo

You:           /auto ET-142

product-manager      → reads the ticket, writes a PRD (problem, users, acceptance criteria)
solutions-architect  → turns the PRD into a technical spec
tech-lead            → breaks the spec into an ordered, verifiable plan
principal-engineer   → dispatches domain engineers in dependency order
   platform-engineer →   implements, tests, commits on a feature branch
qa-engineer          → reviews against the spec, runs the quality gate, verifies ACs
                     → opens the PR, comments back on the ticket

You went from a ticket key to a reviewed PR — with a paper trail at every stage — without leaving the terminal.

📹 [Add a 30-second screencast here] — the single highest-leverage thing you can do for this README. Show /auto running end to end.

🧠 How it works

Three ideas do all the heavy lifting:

1. A team, not a megaprompt. Each role is a separate agent with its own system prompt, tools, and memory. The Product Manager can't touch infrastructure; the Platform Engineer can't invent acceptance criteria. Narrow charters mean fewer hallucinations and cleaner handoffs — the same reason real teams specialize.

2. Generic agents, per-repo config. The agents carry zero project specifics. Everything that changes between repos — tech stack, owned paths, Jira project key, base branch, quality-gate commands — lives in a single .claude/project/project-context.md the plugin auto-loads every session. Write that one file and the entire team adapts to your codebase.