Ignite
A tech-lead workflow for Claude Code
2026–Present
What it does
Claude Code ships /plan, /review, /security-review, and /init. Ignite does not wrap any of them. It fills the gaps around them:
| Gap | Ignite's answer |
|---|---|
/plan output does not persist |
/ignite:save-plan writes it to .ignite/milestones/<version>/ |
/review findings stay in the chat |
/ignite:post-review --pr 42 posts them through gh or glab |
| No warning before the context window runs out | A context-monitor hook injects WARNING at 35% and CRITICAL at 25% remaining |
| Nothing discourages batched commits during long runs | atomic-commit-guard nudges when a staged commit exceeds 5 files or 200 changed lines — advisory, never blocking |
| No end-to-end milestone execution | /ignite:autonomous iterates every phase in the main thread |
| No release notes from the work that was just done | /ignite:release detects the forge, writes notes from the milestone folder and git log, archives, cleans up |
| No architecture docs for an inherited repository | /ignite:onboard runs three parallel explore agents and drafts ARCHITECTURE.md and STANDARDS.md |
| No pre-release gate | /ignite:pre-release runs five parallel audits and returns a single GO / NO-GO |
No pipeline
Most spec-driven tools for AI coding chain specialised agents through a linear pipeline: planner → spec → tasks → executor → verifier, each stage starting with a fresh context window that reads only the artefact the previous stage wrote.
That works when the spec is the deliverable. It works badly when the code is the deliverable, because the original reasoning is compressed at every hop. By the time anything verifies, the executor's trade-offs are invisible.
Ignite has one agent. The main thread holds the full context from plan through release. Subagents fire only for genuinely parallel work — scans, research, isolated audits — never for a hand-off.
Install
npx @dev-mn/ignite@latest --claude --global --hooks
| Flag | Meaning |
|---|---|
--claude / --copilot |
Target runtime |
--global / --local |
Install to ~/.claude/ or the current project |
--hooks |
Register the session-start, stop, status-line, and tool-use hooks |
--uninstall |
Remove installed files, preserving each project's .ignite/ |
Hooks are where roughly forty percent of the value lives, so the installer recommends them by default.
The command surface
Nineteen commands in two tiers. Tier 1 writes state, orchestrates multiple steps, or drives gh/glab; Tier 2 is pure markdown, free to fork and free to extend.
| Tier 1 | What it does |
|---|---|
save-plan |
Persist the most recent /plan output as a milestone or a phase |
post-review |
Post /review findings to a pull request |
onboard |
Scan the codebase, draft ARCHITECTURE.md and STANDARDS.md |
week |
Weekly cadence — shipped, closed, planned |
pre-release |
Five parallel audits into one GO / NO-GO report |
release |
Create the release, archive the milestone, clean up |
autonomous |
End-to-end milestone execution |
sleep |
Unattended overnight execution of a written plan |
Tier 2 covers mentor, critique, tradeoff, compare, research, audit, deps, day, friction, friction-review, and value-review. When hooks are enabled a conventions file loads at session start, so several of these work as protocols in plain language without a slash command at all.
Autonomous and sleep modes
/ignite:autonomous iterates every incomplete phase: it reads the phase spec alongside the architecture, standards, and trade-off files, enters native plan mode, executes, commits each task atomically with a conventional prefix, logs non-obvious decisions to checkpoints.md for asynchronous review, and stops after two consecutive reworks on the same phase. Context warnings let it abort cleanly rather than cascade.
/ignite:sleep is the deliberate opposite. Given a plan written in advance, it pushes through test failures — three edit-test cycles per task, then a wip(...) commit and onward — and resolves ambiguity by picking the standards-aligned option and documenting the choice. It halts on three conditions only: every task processed, context critical, or a .ignite/halt file touched from another terminal.
Hard guardrails override the push-through behaviour in both modes: never push, never merge to main, never tag, never release, never remove dependencies, never edit .env.
What lives in the .ignite directory
Durable state is deliberately small: architecture and standards, an append-only trade-off log, milestone and phase files, rolling context, and checkpoints for decisions and rework. Chat stays execution context; files hold only what has to survive it.
A new command is justified when it writes useful project state or automates a real multi-step gap — never to put a prefix on something the runtime already does.