Ignite 🔥

Personalized, observable, multi-agent development for Claude Code, OpenCode, Gemini CLI, Codex, Copilot, and Antigravity.

A light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code, OpenCode, Gemini CLI, Codex, Copilot, and Antigravity.

Solves context rot — the quality degradation that happens as Claude fills its context window.

English | 简体中文

npx @dev-mn/ignite@latest

Why Ignite?

Most AI coding tools are stateless, opaque, prompt-driven, and easy to derail.

Ignite is:

• Lifecycle-aware — Manages discovery through verification, not just code generation
• Multi-agent — 16 specialized agents orchestrated across 41 workflows
• Observable — Context monitoring, agent tracking, self-checks at every step
• Personalized — Learns your work style, tech preferences, and architectural decisions
• Deterministic — Structured execution that produces consistent, auditable results

You describe what you want — from complex architectures to specific features — and Ignite handles the rest: researching, planning, building, and verifying your system.

No vibe coding. No black boxes. Just structured execution that improves over time.

How It Works

Ignite fixes that. It's the context engineering layer that makes Claude Code reliable. Describe your idea, let the system extract everything it needs to know, and let Claude Code get to work.

Core Capabilities

Full Development Lifecycle

Ignite manages the entire journey — not just code generation:

| Stage | What happens | Agents involved | | ---------------- | ------------------------------------------------------------------ | ---------------------------------------------------- | | Discovery | Questions until your idea is fully understood | Project researcher (4 parallel domain investigators) | | Discussion | Captures your architectural decisions and preferences | Orchestrator with adaptive questioning | | Planning | Research → Plan → Verify loop (max 3 iterations) | Phase researcher → Planner → Plan checker | | Execution | Wave-based parallel execution with fresh 200k context per plan | Executor agents (parallel within waves) | | Verification | Goal-backward check: did the code deliver what the phase promised? | Verifier agent + optional debugger |

Every stage produces explicit, inspectable artifacts.

Multi-Agent Orchestration

Ignite uses 16 specialized agents, each with a focused role:

| Agent | Responsibility | | ----------------------------- | ------------------------------------------------------ | | ignite-project-researcher | Domain and ecosystem research | | ignite-phase-researcher | Deep-dive research per phase | | ignite-planner | Deterministic, testable plans with XML structure | | ignite-plan-checker | Goal-backward verification of plans before execution | | ignite-executor | Implementation with atomic commits per task | | ignite-verifier | Post-execution validation against phase goals | | ignite-debugger | Systematic debugging with persistent state | | ignite-research-synthesizer | Consolidates multi-research findings | | ignite-roadmapper | Creates phased roadmaps from project requirements | | ignite-codebase-mapper | Extracts codebase structure and conventions | | ignite-integration-checker | Validates cross-phase integration | | ignite-nyquist-auditor | Gap detection and validation coverage | | ignite-user-profiler | Developer behavioral profiling | | ignite-ui-researcher | UI pattern research for frontend phases | | ignite-ui-checker | UI spec completeness verification |

The orchestrator never does heavy lifting. It spawns agents, waits, integrates results. Your main context window stays at 30-40% while agents work in fresh 200k contexts.

Model profiles control which Claude model each agent uses:

| Profile | Planning | Execution | Verification | | -------------------- | -------- | --------- | ------------ | | quality | Opus | Opus | Sonnet | | balanced (default) | Opus | Sonnet | Sonnet | | budget | Sonnet | Sonnet | Haiku | | inherit | Inherit | Inherit | Inherit |

Wave-Based Parallel Execution

Plans are grouped into waves based on dependencies. Within each wave, plans run in parallel. Waves run sequentially.

┌────────────────────────────────────────────────────────────────────┐
│  PHASE EXECUTION                                                   │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  WAVE 1 (parallel)          WAVE 2 (parallel)          WAVE 3      │
│  ┌─────────┐ ┌─────────┐    ┌─────────┐ ┌─────────┐    ┌─────────┐ │
│  │ Plan 01 │ │ Plan 02 │ →  │ Plan 03 │ │ Plan 04 │ →  │ Plan 05 │ │
│  │ User    │ │ Product │    │ Orders  │ │ Cart    │    │ Checkout│ │
│  │ Model   │ │ Model   │    │ API     │ │ API     │    │ UI      │ │
│  └─────────┘ └─────────┘    └─────────┘ └─────────┘    └─────────┘ │
│       │           │              ↑           ↑              ↑      │
│       └───────────┴──────────────┴───────────┘              │      │
│                    Dependencies flow forward                │      │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Each executor agent gets a fresh 200k context — zero accumulated garbage, peak quality throughout. Walk away, come back to completed work with clean git history.

Persistent State & Personalization

Ignite continuously tracks and remembers across sessions:

| What's tracked | Where | How it's used | | ----------------------- | -------------------------- | ------------------------------------------------------------ | | Architectural decisions | STATE.md | Injected into agent prompts to enforce consistency | | Your tech preferences | CONTEXT.md | Locks decisions so planner and researcher follow your vision | | Trade-offs and blockers | STATE.md | Surfaced when resuming work or planning next phases | | Successful patterns | SUMMARY.md + git history | Future agents read what worked and what didn't | | Your work style | USER-PROFILE.md | Adapts communication, detail level, and workflow speed |

Developer profiling (/ignite:profile-user) analyzes your session patterns to generate a behavioral profile — work style, communication preferences, testing approach, architectural tendencies. This profile shapes how agents interact with you.

The deeper you go with /ignite:discuss-phase, the more the system builds what you actually want. Skip it and you get reasonable defaults. Use it and you get your vision.

Observability

Ignite is not a black box. At every step, you can see what's happening:

Context monitoring — Real-time statusline shows context window usage. Agents receive warnings at 35% remaining and critical alerts at 25%.

Agent tracking — Every spawned agent is logged in .ignite/agent-history.json with timestamps, phase, plan, and completion status. Interrupted agents are detected on resume.

Self-checks — Every plan execution verifies its own output: files exist on disk, git commits present, acceptance criteria met. Results appended as ## Self-Check: PASSED/FAILED to each SUMMARY.

Goal-backward verification — The verifier agent checks whether the codebase actually delivers what the phase promised, not just that tasks completed. Gaps trigger automatic fix-plan generation.

Auditable artifacts — Everything Ignite produces is a plain file you can read, diff, and version:

.ignite/
  ├── phases/
  │   ├── 01-auth/
  │   │   ├── 01-01-PLAN.md
  │   │   ├── 01-01-SUMMARY.md
  │   │   ├── 01-RESEARCH.md
  │   │   ├── 01-CONTEXT.md
  │   │   └── 01-VERIFICATION.md
  │   └── 02-products/
  │       └── ...
  ├── research/
  ├── config.json
  ├── agent-history.json
  └── STATE.md

PROJECT.md
ROADMAP.md
REQUIREMENTS.md

No hidden state. No magic. Everything is inspectable and version-controlled.

Atomic Git Integration

Each task gets its own commit immediately after completion:

abc123f docs: complete user registration plan
def456g feat: add email confirmation flow
hij789k feat: implement password hashing
lmn012o feat: create registration endpoint

Why this matters:

• git bisect finds the exact failing task
• Each task is independently revertable
• Future Claude sessions read git history for context
• Clean history for debugging in AI-automated workflows

Optional branching strategies: per-phase branches, per-milestone branches, or commit directly to current branch.

Getting Started

npx @dev-mn/ignite@latest

The installer prompts you to choose:

1. Runtime — Claude Code, OpenCode, Gemini, Codex, Copilot, Cursor, Antigravity, or all
2. Location — Global (all projects) or local (current project only)

Verify with:

• Claude Code / Gemini: /ignite:help
• OpenCode: /ignite-help
• Codex: $ignite-help
• Copilot: /ignite:help
• Antigravity: /ignite:help

[!NOTE] Codex installation uses skills (skills/ignite-*/SKILL.md) rather than custom prompts.

Staying Updated

Ignite evolves fast. Update periodically:

npx @dev-mn/ignite@latest

# Claude Code
npx @dev-mn/ignite --claude --global   # Install to ~/.claude/
npx @dev-mn/ignite --claude --local    # Install to ./.claude/

# OpenCode (open source, free models)
npx @dev-mn/ignite --opencode --global # Install to ~/.config/opencode/

# Gemini CLI
npx @dev-mn/ignite --gemini --global   # Install to ~/.gemini/

# Codex (skills-first)
npx @dev-mn/ignite --codex --global    # Install to ~/.codex/
npx @dev-mn/ignite --codex --local     # Install to ./.codex/

# Copilot (GitHub Copilot CLI)
npx @dev-mn/ignite --copilot --global  # Install to ~/.github/
npx @dev-mn/ignite --copilot --local   # Install to ./.github/

# Cursor CLI
npx @dev-mn/ignite --cursor --global      # Install to ~/.cursor/
npx @dev-mn/ignite --cursor --local       # Install to ./.cursor/

# Antigravity (Google, skills-first, Gemini-based)
npx @dev-mn/ignite --antigravity --global # Install to ~/.gemini/antigravity/
npx @dev-mn/ignite --antigravity --local  # Install to ./.agent/

# All runtimes
npx @dev-mn/ignite --all --global      # Install to all directories

Use --global (-g) or --local (-l) to skip the location prompt. Use --claude, --opencode, --gemini, --codex, --copilot, --cursor, --antigravity, or --all to skip the runtime prompt.

Clone the repository and run the installer locally:

git clone https://github.com/glittercowboy/ignite.git
cd ignite
node bin/install.js --claude --local

Installs to ./.claude/ for testing modifications before contributing.

Recommended: Skip Permissions Mode

Ignite is designed for frictionless automation. Run Claude Code with:

claude --dangerously-skip-permissions

[!TIP] This is how Ignite is intended to be used — stopping to approve date and git commit 50 times defeats the purpose.

Add to .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(date:*)",
      "Bash(echo:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(wc:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(sort:*)",
      "Bash(grep:*)",
      "Bash(tr:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git tag:*)"
    ]
  }
}

How It Works

Already have code? Run /ignite:map-codebase first. It spawns parallel agents to analyze your stack, architecture, conventions, and concerns. Then /ignite:new-project knows your codebase — questions focus on what you're adding, and planning automatically loads your patterns.

1. Initialize Project

/ignite:new-project

One command, one flow. The system:

1. Questions — Asks until it understands your idea completely (goals, constraints, tech preferences, edge cases)
2. Research — Spawns parallel agents to investigate the domain (optional but recommended)
3. Requirements — Extracts what's v1, v2, and out of scope
4. Roadmap — Creates phases mapped to requirements

You approve the roadmap. Now you're ready to build.

Creates: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, .ignite/research/

2. Discuss Phase

/ignite:discuss-phase 1

This is where you shape the implementation.

Your roadmap has a sentence or two per phase. That's not enough context to build something the way you imagine it. This step captures your preferences before anything gets researched or planned.

The system analyzes the phase and identifies gray areas based on what's being built:

• Visual features → Layout, density, interactions, empty states
• APIs/CLIs → Response format, flags, error handling, verbosity
• Content systems → Structure, tone, depth, flow
• Organization tasks → Grouping criteria, naming, duplicates, exceptions

For each area you select, it asks until you're satisfied. The output — CONTEXT.md — feeds directly into the next two steps:

1. Researcher reads it — Knows what patterns to investigate ("user wants card layout" → research card component libraries)
2. Planner reads it — Knows what decisions are locked ("infinite scroll decided" → plan includes scroll handling)

The deeper you go here, the more the system builds what you actually want. Skip it and you get reasonable defaults. Use it and you get your vision.

Creates: {phase_num}-CONTEXT.md

3. Plan Phase

/ignite:plan-phase 1

The system:

1. Researches — Investigates how to implement this phase, guided by your CONTEXT.md decisions
2. Plans — Creates 2-3 atomic task plans with XML structure
3. Verifies — Checks plans against requirements, loops until they pass

Each plan is small enough to execute in a fresh context window. No degradation, no "I'll be more concise now."

Creates: {phase_num}-RESEARCH.md, {phase_num}-{N}-PLAN.md

4. Execute Phase

/ignite:execute-phase 1

The system:

1. Runs plans in waves — Parallel where possible, sequential when dependent
2. Fresh context per plan — 200k tokens purely for implementation, zero accumulated garbage
3. Commits per task — Every task gets its own atomic commit
4. Verifies against goals — Checks the codebase delivers what the phase promised

Walk away, come back to completed work with clean git history.

How Wave Execution Works:

Plans are grouped into "waves" based on dependencies. Within each wave, plans run in parallel. Waves run sequentially.

┌────────────────────────────────────────────────────────────────────┐
│  PHASE EXECUTION                                                   │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  WAVE 1 (parallel)          WAVE 2 (parallel)          WAVE 3      │
│  ┌─────────┐ ┌─────────┐    ┌─────────┐ ┌─────────┐    ┌─────────┐ │
│  │ Plan 01 │ │ Plan 02 │ →  │ Plan 03 │ │ Plan 04 │ →  │ Plan 05 │ │
│  │         │ │         │    │         │ │         │    │         │ │
│  │ User    │ │ Product │    │ Orders  │ │ Cart    │    │ Checkout│ │
│  │ Model   │ │ Model   │    │ API     │ │ API     │    │ UI      │ │
│  └─────────┘ └─────────┘    └─────────┘ └─────────┘    └─────────┘ │
│       │           │              ↑           ↑              ↑      │
│       └───────────┴──────────────┴───────────┘              │      │
│              Dependencies: Plan 03 needs Plan 01            │      │
│                          Plan 04 needs Plan 02              │      │
│                          Plan 05 needs Plans 03 + 04        │      │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Why waves matter:

• Independent plans → Same wave → Run in parallel
• Dependent plans → Later wave → Wait for dependencies
• File conflicts → Sequential plans or same plan

This is why "vertical slices" (Plan 01: User feature end-to-end) parallelize better than "horizontal layers" (Plan 01: All models, Plan 02: All APIs).

Creates: {phase_num}-{N}-SUMMARY.md, {phase_num}-VERIFICATION.md

5. Verify Work

/ignite:verify-work 1

This is where you confirm it actually works.

Automated verification checks that code exists and tests pass. But does the feature work the way you expected? This is your chance to use it.

The system:

1. Extracts testable deliverables — What you should be able to do now
2. Walks you through one at a time — "Can you log in with email?" Yes/no, or describe what's wrong
3. Diagnoses failures automatically — Spawns debug agents to find root causes
4. Creates verified fix plans — Ready for immediate re-execution

If everything passes, you move on. If something's broken, you don't manually debug — you just run /ignite:execute-phase again with the fix plans it created.

Creates: {phase_num}-UAT.md, fix plans if issues found

6. Repeat → Ship → Complete → Next Milestone

/ignite:discuss-phase 2
/ignite:plan-phase 2
/ignite:execute-phase 2
/ignite:verify-work 2
/ignite:ship 2                  # Create PR from verified work
...
/ignite:complete-milestone
/ignite:new-milestone

Or let Ignite figure out the next step automatically:

/ignite:next                    # Auto-detect and run next step

Loop discuss → plan → execute → verify → ship until milestone complete.

If you want faster intake during discussion, use /ignite:discuss-phase <n> --batch to answer a small grouped set of questions at once instead of one-by-one.

Each phase gets your input (discuss), proper research (plan), clean execution (execute), and human verification (verify). Context stays fresh. Quality stays high.

When all phases are done, /ignite:complete-milestone archives the milestone and tags the release.

Then /ignite:new-milestone starts the next version — same flow as new-project but for your existing codebase. You describe what you want to build next, the system researches the domain, you scope requirements, and it creates a fresh roadmap. Each milestone is a clean cycle: define → build → ship.

Quick Mode

/ignite:quick

For ad-hoc tasks that don't need full planning.

Quick mode gives you Ignite guarantees (atomic commits, state tracking) with a faster path:

• Same agents — Planner + executor, same quality
• Skips optional steps — No research, no plan checker, no verifier by default
• Separate tracking — Lives in .ignite/quick/, not phases

--discuss flag: Lightweight discussion to surface gray areas before planning.

--research flag: Spawns a focused researcher before planning. Investigates implementation approaches, library options, and pitfalls. Use when you're unsure how to approach a task.

--full flag: Enables plan-checking (max 2 iterations) and post-execution verification.

Flags are composable: --discuss --research --full gives discussion + research + plan-checking + verification.

/ignite:quick
> What do you want to do? "Add dark mode toggle to settings"

Creates: .ignite/quick/001-add-dark-mode-toggle/PLAN.md, SUMMARY.md

Why It Works

Context Engineering

Claude Code is incredibly powerful if you give it the context it needs. Most people don't.

Ignite handles it for you:

| File | What it does | |------|--------------| | PROJECT.md | Project vision, always loaded | | research/ | Ecosystem knowledge (stack, features, architecture, pitfalls) | | REQUIREMENTS.md | Scoped v1/v2 requirements with phase traceability | | ROADMAP.md | Where you're going, what's done | | STATE.md | Decisions, blockers, position — memory across sessions | | PLAN.md | Atomic task with XML structure, verification steps | | SUMMARY.md | What happened, what changed, committed to history | | todos/ | Captured ideas and tasks for later work | | threads/ | Persistent context threads for cross-session work | | seeds/ | Forward-looking ideas that surface at the right milestone |

Size limits based on where Claude's quality degrades. Stay under, get consistent excellence.

XML Prompt Formatting

Every plan is structured XML optimized for Claude:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Precise instructions. No guessing. Verification built in.

Multi-Agent Orchestration

Every stage uses the same pattern: a thin orchestrator spawns specialized agents, collects results, and routes to the next step.

| Stage | Orchestrator does | Agents do | |-------|------------------|-----------| | Research | Coordinates, presents findings | 4 parallel researchers investigate stack, features, architecture, pitfalls | | Planning | Validates, manages iteration | Planner creates plans, checker verifies, loop until pass | | Execution | Groups into waves, tracks progress | Executors implement in parallel, each with fresh 200k context | | Verification | Presents results, routes next | Verifier checks codebase against goals, debuggers diagnose failures |

The orchestrator never does heavy lifting. It spawns agents, waits, integrates results.

The result: You can run an entire phase — deep research, multiple plans created and verified, thousands of lines of code written across parallel executors, automated verification against goals — and your main context window stays at 30-40%. The work happens in fresh subagent contexts. Your session stays fast and responsive.

Atomic Git Commits

Each task gets its own commit immediately after completion:

npx @dev-mn/ignite --claude --global    # ~/.claude/
npx @dev-mn/ignite --claude --local     # ./.claude/
npx @dev-mn/ignite --opencode --global  # ~/.config/opencode/
npx @dev-mn/ignite --gemini --global    # ~/.gemini/
npx @dev-mn/ignite --codex --global     # ~/.codex/
npx @dev-mn/ignite --copilot --global   # ~/.github/
npx @dev-mn/ignite --antigravity --global # ~/.gemini/antigravity/
npx @dev-mn/ignite --all --global       # All runtimes

Use --global (-g) or --local (-l) to skip the location prompt.

git clone https://github.com/intelligo-mn/ignite.git
cd ignite
node bin/install.js --claude --local

Already have code? Run /ignite:map-codebase first. It spawns parallel agents to analyze your stack, architecture, conventions, and concerns. Then /ignite:new-project knows your codebase — questions focus on what you're adding.

Commands

Core Workflow

| Command | What it does | |---------|--------------| | /ignite:new-project [--auto] | Full initialization: questions → research → requirements → roadmap | | /ignite:discuss-phase [N] [--auto] [--analyze] | Capture implementation decisions before planning (--analyze adds trade-off analysis) | | /ignite:plan-phase [N] [--auto] | Research + plan + verify for a phase | | /ignite:execute-phase <N> | Execute all plans in parallel waves, verify when complete | | /ignite:verify-work [N] | Manual user acceptance testing ¹ | | /ignite:ship [N] [--draft] | Create PR from verified phase work with auto-generated body | | /ignite:next | Automatically advance to the next logical workflow step | | /ignite:fast <text> | Inline trivial tasks — skips planning entirely, executes immediately | | /ignite:audit-milestone | Verify milestone achieved its definition of done | | /ignite:complete-milestone | Archive milestone, tag release | | /ignite:new-milestone [name] | Start next version: questions → research → requirements → roadmap |

Quick Mode

| Command | What it does | |---------|--------------| | /ignite:ui-phase [N] | Generate UI design contract (UI-SPEC.md) for frontend phases | | /ignite:ui-review [N] | Retroactive 6-pillar visual audit of implemented frontend code |

Navigation

| Command | What it does | |---------|--------------| | /ignite:progress | Where am I? What's next? | | /ignite:next | Auto-detect state and run the next step | | /ignite:help | Show all commands and usage guide | | /ignite:update | Update Ignite with changelog preview | | /ignite:join-discord | Join the Ignite Discord community |

Brownfield

| Command | What it does | |---------|--------------| | /ignite:map-codebase [area] | Analyze existing codebase before new-project |

Phase Management

| Command | What it does | |---------|--------------| | /ignite:add-phase | Append phase to roadmap | | /ignite:insert-phase [N] | Insert urgent work between phases | | /ignite:remove-phase [N] | Remove future phase, renumber | | /ignite:list-phase-assumptions [N] | See Claude's intended approach before planning | | /ignite:plan-milestone-gaps | Create phases to close gaps from audit |

UI Design

| Command | What it does | |---------|--------------| | /ignite:pause-work | Create handoff when stopping mid-phase (writes HANDOFF.json) | | /ignite:resume-work | Restore from last session | | /ignite:session-report | Generate session summary with work performed and outcomes |

Code Quality

| Command | What it does | |---------|--------------| | /ignite:review | Cross-AI peer review of current phase or branch | | /ignite:pr-branch | Create clean PR branch filtering .ignite/ commits | | /ignite:audit-uat | Audit verification debt — find phases missing UAT |

Backlog & Threads

| Command | What it does | |---------|--------------| | /ignite:plant-seed <idea> | Capture forward-looking ideas with trigger conditions — surfaces at the right milestone | | /ignite:add-backlog <desc> | Add idea to backlog parking lot (999.x numbering, outside active sequence) | | /ignite:review-backlog | Review and promote backlog items to active milestone or remove stale entries | | /ignite:thread [name] | Persistent context threads — lightweight cross-session knowledge for work spanning multiple sessions |

Utilities

| Command | What it does | |---------|--------------| | /ignite:settings | Configure model profile and workflow agents | | /ignite:set-profile <profile> | Switch model profile (quality/balanced/budget/inherit) | | /ignite:add-todo [desc] | Capture idea for later | | /ignite:check-todos | List pending todos | | /ignite:debug [desc] | Systematic debugging with persistent state | | /ignite:do <text> | Route freeform text to the right Ignite command automatically | | /ignite:note <text> | Zero-friction idea capture — append, list, or promote notes to todos | | /ignite:quick [--full] [--discuss] [--research] | Execute ad-hoc task with Ignite guarantees (--full adds plan-checking and verification, --discuss gathers context first, --research investigates approaches before planning) | | /ignite:health [--repair] | Validate .ignite/ directory integrity, auto-repair with --repair | | /ignite:stats | Display project statistics — phases, plans, requirements, git metrics | | /ignite:profile-user [--questionnaire] [--refresh] | Generate developer behavioral profile from session analysis for personalized responses |

¹ Contributed by reddit user OracleGreyBeard

Configuration

Ignite stores project settings in .ignite/config.json. Configure during /ignite:new-project or update later with /ignite:settings. For the full config schema, workflow toggles, git branching options, and per-agent model breakdown, see the User Guide.

Core Settings

| Setting | Options | Default | What it controls | |---------|---------|---------|------------------| | mode | yolo, interactive | interactive | Auto-approve vs confirm at each step | | granularity | coarse, standard, fine | standard | Phase granularity — how finely scope is sliced (phases × plans) |

Model Profiles

Control which Claude model each agent uses. Balance quality vs token spend.

| Profile | Planning | Execution | Verification | |---------|----------|-----------|--------------| | quality | Opus | Opus | Sonnet | | balanced (default) | Opus | Sonnet | Sonnet | | budget | Sonnet | Sonnet | Haiku | | inherit | Inherit | Inherit | Inherit |

Switch profiles:

/ignite:set-profile budget

Use inherit when using non-Anthropic providers (OpenRouter, local models) or to follow the current runtime model selection (e.g. OpenCode /model).

Or configure via /ignite:settings.

Workflow Agents

These spawn additional agents during planning/execution. They improve quality but add tokens and time.

| Setting | Default | What it does | |---------|---------|--------------| | workflow.research | true | Researches domain before planning each phase | | workflow.plan_check | true | Verifies plans achieve phase goals before execution | | workflow.verifier | true | Confirms must-haves were delivered after execution | | workflow.auto_advance | false | Auto-chain discuss → plan → execute without stopping | | workflow.research_before_questions | false | Run research before discussion questions instead of after |

Use /ignite:settings to toggle these, or override per-invocation:

• /ignite:plan-phase --skip-research
• /ignite:plan-phase --skip-verify

Execution

| Setting | Default | What it controls | |---------|---------|------------------| | parallelization.enabled | true | Run independent plans simultaneously | | planning.commit_docs | true | Track .ignite/ in git | | hooks.context_warnings | true | Show context window usage warnings |

For the full config schema, see the User Guide.

Control how Ignite handles branches during execution.

What Ignite Is (and Isn't)

Strategies:

• none — Commits to current branch (default Ignite behavior)
• phase — Creates a branch per phase, merges at phase completion
• milestone — Creates one branch for entire milestone, merges at completion

At milestone completion, Ignite offers squash merge (recommended) or merge with history.

Security

Built-in Security Hardening

Ignite includes defense-in-depth security since v1.27:

• Path traversal prevention — All user-supplied file paths (--text-file, --prd) are validated to resolve within the project directory
• Prompt injection detection — Centralized security.cjs module scans for injection patterns in user-supplied text before it enters planning artifacts
• PreToolUse prompt guard hook — ignite-prompt-guard scans writes to .ignite/ for embedded injection vectors (advisory, not blocking)
• Safe JSON parsing — Malformed --fields arguments are caught before they corrupt state
• Shell argument validation — User text is sanitized before shell interpolation
• CI-ready injection scanner — prompt-injection-scan.test.cjs scans all agent/workflow/command files for embedded injection vectors

[!NOTE] Because Ignite generates markdown files that become LLM system prompts, any user-controlled text flowing into planning artifacts is a potential indirect prompt injection vector. These protections are designed to catch such vectors at multiple layers.

Protecting Sensitive Files

Ignite's codebase mapping and analysis commands read files to understand your project. Protect files containing secrets by adding them to Claude Code's deny list:

1. Open Claude Code settings (.claude/settings.json or global)
2. Add sensitive file patterns to the deny list:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/*)",
      "Read(**/*credential*)",
      "Read(**/*.pem)",
      "Read(**/*.key)"
    ]
  }
}

[!IMPORTANT] Ignite includes built-in protections against committing secrets, but defense-in-depth is best practice. Deny read access to sensitive files as a first line of defense.

Troubleshooting

Commands not found after install?

• Restart your runtime to reload commands/skills
• Verify files exist in ~/.claude/commands/ignite/ (global) or ./.claude/commands/ignite/ (local)
• For Codex, verify skills exist in ~/.codex/skills/ignite-*/SKILL.md (global) or ./.codex/skills/ignite-*/SKILL.md (local)

Commands not working as expected?

• Run /ignite:help to verify installation
• Re-run npx @dev-mn/ignite to reinstall

Updating to the latest version?

npx @dev-mn/ignite@latest

Using Docker or containerized environments?

If file reads fail with tilde paths (~/.claude/...), set CLAUDE_CONFIG_DIR before installing:

CLAUDE_CONFIG_DIR=/home/youruser/.claude npx @dev-mn/ignite --global

This ensures absolute paths are used instead of ~ which may not expand correctly in containers.

Uninstalling

To remove Ignite completely:

# Global installs
npx @dev-mn/ignite --claude --global --uninstall
npx @dev-mn/ignite --opencode --global --uninstall
npx @dev-mn/ignite --gemini --global --uninstall
npx @dev-mn/ignite --codex --global --uninstall
npx @dev-mn/ignite --copilot --global --uninstall
npx @dev-mn/ignite --cursor --global --uninstall
npx @dev-mn/ignite --antigravity --global --uninstall

# Local installs (current project)
npx @dev-mn/ignite --claude --local --uninstall
npx @dev-mn/ignite --opencode --local --uninstall
npx @dev-mn/ignite --codex --local --uninstall
npx @dev-mn/ignite --copilot --local --uninstall
npx @dev-mn/ignite --cursor --local --uninstall
npx @dev-mn/ignite --antigravity --local --uninstall

This removes all Ignite commands, agents, hooks, and settings while preserving your other configurations.

Community Ports

OpenCode, Gemini CLI, and Codex are now natively supported via npx @dev-mn/ignite.

These community ports pioneered multi-runtime support:

| Project | Platform | Description | |---------|----------|-------------| | ignite-opencode | OpenCode | Original OpenCode adaptation | | ignite-gemini (archived) | Gemini CLI | Original Gemini adaptation by uberfuzzy |

Star History

License

MIT License. See LICENSE for details.

Claude Code is powerful. Ignite makes it reliable.