@accelerationguy/accel 1.0.0

package/modules/ignition/data/campaign/guide.md

@@ -0,0 +1,36 @@
+# Campaign — Conversation Guide
+
+## Section 1: Strategy & Goal
+**Explore:** What's the specific measurable objective? Not "grow the channel" — something like "launch 10 shorts in 2 weeks" or "generate 50 leads from webinar." What's the thesis?
+**Suggest:** If the goal is vague, push for a number: "How will you know this worked? What's the metric?" If they can't answer, the campaign isn't ready to plan — it needs more strategic thinking first.
+**Depth:** required
+
+## Section 2: Audience
+**Explore:** Who is this for — existing audience or new acquisition? What are their pain points? What language do they use? Where do they hang out online?
+**Suggest:** Be specific: "Agency owners who use GoHighLevel and feel overwhelmed by AI" is better than "business owners." If targeting existing audience, note the platform where they already are.
+**Depth:** required
+
+## Section 3: Deliverables List
+**Explore:** Enumerate EVERY output. For each: format, length, platform, due date. What gets created first? What depends on what?
+**Suggest:** Table it: Deliverable | Format | Platform | Length | Due Date. If the list is longer than 15 items, consider splitting into multiple campaigns. If it's under 3, it might not need Ignition — just do it.
+**Depth:** required
+
+## Section 4: Channels & Platforms
+**Explore:** Where does each deliverable go? Cross-posting strategy? Platform-specific adaptations needed? What's the primary channel vs amplification?
+**Suggest:** Pick one primary channel and 2-3 amplification channels. Don't try to be everywhere. For shortform: IG Reels → TikTok → YT Shorts → FB Reels is the standard cross-post chain.
+**Depth:** required
+
+## Section 5: Timeline
+**Explore:** What are the dates? What depends on what? What's the critical path? Any external deadlines (launches, events, partner commitments)?
+**Suggest:** Work backwards from the launch date. Build in buffer for content creation (it always takes longer). If there are dependencies (e.g., "can't post until site launches"), mark them as blockers.
+**Depth:** required
+
+## Section 6: Success Metrics
+**Explore:** Define metrics BEFORE execution, not after. What's the baseline? What's the target? How will you measure?
+**Suggest:** Pick 2-3 metrics max. For content: views, engagement rate, conversion to next step. For launches: signups, revenue, retention. Don't track everything — track what matters.
+**Depth:** required
+
+## Section 7: Skill Loadout
+**Explore:** Which ecosystem tools help with this campaign? Content strategy? Distribution optimization? Script writing?
+**Suggest:** Load skill-loadout.md recommendations. For most campaigns: content-flywheel-strategist (for multi-platform strategy), content-manager (for pipeline tracking), revops-expert (for conversion copy).
+**Depth:** optional

package/modules/ignition/data/campaign/skill-loadout.md

@@ -0,0 +1,10 @@
+# Campaign — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| content-flywheel-strategist | recommended | Multi-platform content strategy — transform core content into platform-specific formats |
+| revops-expert | recommended | Conversion copywriting frameworks for landing pages, emails, webinar scripts |
+| content-manager | recommended | Pipeline tracking — manage scripts through triage → recording → editing → publishing |
+| Drive | optional | Only if the campaign has a complex build component (e.g., landing page + email sequence + webinar) |

package/modules/ignition/data/client/config.md

@@ -0,0 +1,18 @@
+# Client — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | standard |
+| Demeanor | Business-focused and practical — understand the client's goals, push for conversion clarity, keep tech decisions simple. The client cares about results, not architecture. |
+| Sections | 7 |
+
+## Required Sections
+- Business Context
+- Competitor Analysis
+- Conversion Strategy
+- Content Needs
+- Tech Approach
+- Timeline & Deliverables
+
+## Optional Sections
+- Skill Loadout

package/modules/ignition/data/client/guide.md

@@ -0,0 +1,36 @@
+# Client — Conversation Guide
+
+## Section 1: Business Context
+**Explore:** Who's the client? What industry? Who's the target audience? What's the brand personality? Do they have an existing site?
+**Suggest:** If they have an existing site, suggest running `business-context-extractor` to pull structured context automatically. If not, build the context from conversation: industry, audience demographics, competitive positioning.
+**Depth:** required
+
+## Section 2: Competitor Analysis
+**Explore:** Who are 3-5 competitors? What are they doing well? Where's the positioning opportunity — what gap can this client fill? What's the differentiator?
+**Suggest:** Focus on positioning, not feature comparison. "They all do X, but none of them do Y" is the goal. If the user doesn't know competitors, suggest searching the client's industry + location.
+**Depth:** required
+
+## Section 3: Conversion Strategy
+**Explore:** What's the primary CTA? What's the funnel — visitor → lead → customer? What objections does the audience have? How does the site overcome them?
+**Suggest:** Every page needs a clear next step. For service businesses: contact form or calendar booking. For products: add to cart or free trial. Map the objection → response pairs.
+**Depth:** required
+
+## Section 4: Content Needs
+**Explore:** What content exists already? What needs to be written? Who writes it — the client, you, AI-assisted? Any brand guidelines or tone requirements?
+**Suggest:** Start with the minimum: hero copy, about section, service descriptions, testimonials. Don't plan a blog unless the client will actually write posts. Real content > placeholder content.
+**Depth:** required
+
+## Section 5: Tech Approach
+**Explore:** site-launcher-wp or custom build? What's the hosting situation? Domain owned? Any existing tech constraints (CMS, hosting provider)?
+**Suggest:** For most client sites: site-launcher-wp is fastest to production. Custom only if the client needs something the template can't handle. Always ask about domain and hosting first.
+**Depth:** required
+
+## Section 6: Timeline & Deliverables
+**Explore:** What's the deadline? Are there client review checkpoints? What are the deliverables at each stage? Who approves what?
+**Suggest:** Suggest a 3-phase approach: (1) Design/content draft → client review, (2) Build → client review, (3) Launch prep → go live. Build in buffer for client feedback cycles.
+**Depth:** required
+
+## Section 7: Skill Loadout
+**Explore:** Which ecosystem tools will speed up this project? Need business context extraction? Conversion copywriting help? Design system?
+**Suggest:** Load skill-loadout.md recommendations. For most client sites: business-context-extractor (required if existing site), revops-expert (for conversion copy), ui-ux-pro-max (for design).
+**Depth:** optional

package/modules/ignition/data/client/skill-loadout.md

@@ -0,0 +1,11 @@
+# Client — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| business-context-extractor | required | If client has an existing site — pulls structured business context automatically |
+| revops-expert | recommended | Conversion copywriting frameworks (Hormozi, Brunson) for landing pages and CTAs |
+| ui-ux-pro-max | recommended | Design system, responsive layouts, component patterns for the site build |
+| Drive | recommended | Structured phases if the project has multiple deliverables or a complex timeline |
+| geo | optional | SEO/GEO audit after launch — optimize for AI search visibility |

package/modules/ignition/data/utility/config.md

@@ -0,0 +1,18 @@
+# Utility — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | tight |
+| Demeanor | Fast and constrained — resist scope creep actively, push for single-purpose clarity, challenge any expansion. Utilities should be done in one session. |
+| Sections | 6 |
+
+## Required Sections
+- Problem Statement
+- Scope Guard
+- User & Distribution
+- Dependencies
+- Interface
+- Done Criteria
+
+## Optional Sections
+None — all sections are required for utilities. Keeping it tight means covering everything, just briefly.

package/modules/ignition/data/utility/guide.md

@@ -0,0 +1,31 @@
+# Utility — Conversation Guide
+
+## Section 1: Problem Statement
+**Explore:** What does this tool do? One sentence. If it takes more than one sentence, it might not be a utility.
+**Suggest:** Push for brevity: "It takes X and produces Y." If the description is getting complex, ask: "Is this actually an application?" Utilities resist expansion — that's a feature, not a limitation.
+**Depth:** required
+
+## Section 2: Scope Guard
+**Explore:** One file or multiple? One function or a system? What does this explicitly NOT do? Where's the boundary?
+**Suggest:** Actively resist expansion. If the user says "and it could also..." — stop them. "That sounds like a separate tool. Let's keep this one focused." The best utilities do one thing well.
+**Depth:** required
+
+## Section 3: User & Distribution
+**Explore:** Who uses this — just you, your team, the community? Where does it live — tools/personal, tools/shareable, tools/mcp-servers?
+**Suggest:** Personal tools go in tools/personal/. If it's useful to others: tools/shareable/. If it's an MCP server: tools/mcp-servers/production/. Distribution affects how much documentation you need.
+**Depth:** required
+
+## Section 4: Dependencies
+**Explore:** What does this depend on? External APIs, npm packages, system tools? Can you minimize dependencies?
+**Suggest:** Fewer deps = less maintenance. If a dependency is heavy (e.g., puppeteer for a simple scrape), consider whether a lighter alternative exists. Zero-dep utilities are the gold standard.
+**Depth:** required
+
+## Section 5: Interface
+**Explore:** How is it invoked? CLI args, stdin, function call, MCP tool? What's the input format? What's the output format?
+**Suggest:** Define the contract: "Input: X (format), Output: Y (format), Errors: Z." If you can't define the interface cleanly, the scope might be too broad.
+**Depth:** required
+
+## Section 6: Done Criteria
+**Explore:** What are 3-5 test cases that prove this works? Can you define them now? If you can't, the scope might be too vague.
+**Suggest:** Write the test cases as: "Given X, expect Y." If every test case is different, the tool might be doing too many things. 3 test cases is the sweet spot for utilities.
+**Depth:** required

package/modules/ignition/data/utility/skill-loadout.md

@@ -0,0 +1,8 @@
+# Utility — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| Drive | optional | Only if the utility is complex enough to warrant phases — most utilities are built in one session without Drive |
+| Radar | optional | Post-build quality check — useful if the utility will be distributed or handles sensitive data |

package/modules/ignition/data/workflow/config.md

@@ -0,0 +1,19 @@
+# Workflow — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | standard |
+| Demeanor | Balanced and systems-aware — understand integrations, push for clear boundaries, but don't over-architect. Workflows should be lean. |
+| Sections | 8 |
+
+## Required Sections
+- Problem Statement
+- Scope Definition
+- Integration Map
+- Interaction Design
+- Output Artifacts
+- Edge Cases & Constraints
+
+## Optional Sections
+- Downstream Handoff
+- Tool Discovery

package/modules/ignition/data/workflow/guide.md

@@ -0,0 +1,41 @@
+# Workflow — Conversation Guide
+
+## Section 1: Problem Statement
+**Explore:** What workflow pain or gap does this solve? What's the current process, and where does it break down? Is this a new capability or improving an existing one?
+**Suggest:** Frame it as "before vs after" — what does the user do today vs what they'll do with this workflow. If it's replacing manual steps, list them.
+**Depth:** required
+
+## Section 2: Scope Definition
+**Explore:** What components does this include? Commands, skills, Vector domains, hooks, MCP tools, templates? What's the boundary — what does this workflow NOT do?
+**Suggest:** Use a checklist: "Does this need a slash command? A Vector domain? An MCP server? A hook?" Most workflows are 2-3 of these, not all. If they're building all of them, the scope may be too big.
+**Depth:** required
+
+## Section 3: Integration Map
+**Explore:** What existing systems does this touch? Momentum, Vector, Drive, Radar? What files does it read or write? What doesn't it touch?
+**Suggest:** Draw the integration map as a table: System | Reads | Writes | Why. If touching more than 3 systems, consider whether this is really one workflow or two.
+**Depth:** required
+
+## Section 4: Interaction Design
+**Explore:** What's the entry point? User says X, Claude does Y. What's the conversation flow? Where are the decision points? What does "done" look like?
+**Suggest:** Write 2-3 example interactions: "User runs /command, Claude responds with..., user confirms..., Claude produces..." This is the spec that drives implementation.
+**Depth:** required
+
+## Section 5: Output Artifacts
+**Explore:** What files get created or modified? What format? Where do they live? Are outputs consumed by other workflows?
+**Suggest:** Table it: File | Format | Location | Consumed By. If outputs feed other systems, that's an integration point — note it.
+**Depth:** required
+
+## Section 6: Downstream Handoff
+**Explore:** How does the output of this workflow connect to the next stage? Does it feed into Drive, Momentum, another command? Is there a manual step between?
+**Suggest:** If the handoff is manual, consider whether it should be automated. If it feeds Drive, ensure the output format matches what Drive expects.
+**Depth:** optional
+
+## Section 7: Tool Discovery
+**Explore:** What's missing from the ecosystem that would make this workflow better? Any MCP servers needed? Any skills that should exist but don't?
+**Suggest:** Check existing tools first — search MCP servers, slash commands, skills. Don't build what already exists. If something is missing, note it as a dependency or future work.
+**Depth:** optional
+
+## Section 8: Edge Cases & Constraints
+**Explore:** What shouldn't this workflow do? What happens with bad input? What if a dependency is missing? What's the failure mode?
+**Suggest:** List 3-5 "what ifs" and how the workflow handles each. If you can't answer a "what if," that's a design gap to resolve now.
+**Depth:** required

package/modules/ignition/data/workflow/skill-loadout.md

@@ -0,0 +1,10 @@
+# Workflow — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| Drive | required | Structured phases for building multi-component workflows (commands + hooks + domains) |
+| Forge | recommended | If the workflow produces a skill — ensures Forge compliance from the start |
+| Vector | recommended | If the workflow needs dynamic rules — design the domain during ideation, not after |
+| Momentum | optional | If the workflow touches workspace state — understand the integration surface |

package/modules/ignition/integration.js

@@ -0,0 +1,54 @@
+/**
+ * Ignition -> Drive Integration
+ *
+ * When Ignition finishes scaffolding a new project and produces a PLANNING.md,
+ * this module emits a `plan-created` event via the Accelerate event bus.
+ * Drive consumes that event on its next invocation and adopts the plan.
+ *
+ * Event schema: shared/events/schemas/plan-created.schema.json
+ *
+ * Usage inside Ignition's core scaffold logic:
+ *   const { notifyPlanCreated } = require('./integration');
+ *   await notifyPlanCreated('/path/to/PLANNING.md', 'application', 'My App');
+ *
+ * @module modules/ignition/integration
+ */
+
+const eventBus = require('../../shared/events/event-bus');
+
+/**
+ * Emit a plan-created event after Ignition generates a PLANNING.md.
+ *
+ * @param {string}  planPath     - Absolute path to the generated PLANNING.md
+ * @param {string}  projectType  - One of: application, campaign, client, utility, workflow
+ * @param {string}  title        - Human-readable project title
+ * @returns {string} The event filename written to the events directory
+ * @throws {Error}  If the producer is not registered in the Accelerate manifest
+ */
+function notifyPlanCreated(planPath, projectType, title) {
+  return eventBus.emit('ignition', 'plan-created', {
+    path: planPath,
+    projectType,
+    title,
+  });
+}
+
+/**
+ * Convenience wrapper that reads PLANNING.md metadata and emits the event.
+ * Call this at the very end of the Ignition scaffold pipeline.
+ *
+ * @param {object} scaffoldResult - The result object from Ignition's scaffold step
+ * @param {string} scaffoldResult.planPath     - Path to the PLANNING.md
+ * @param {string} scaffoldResult.projectType  - Project type enum value
+ * @param {string} scaffoldResult.title        - Project title
+ * @returns {string} The event filename
+ */
+function onScaffoldComplete(scaffoldResult) {
+  const { planPath, projectType, title } = scaffoldResult;
+  return notifyPlanCreated(planPath, projectType, title);
+}
+
+module.exports = {
+  notifyPlanCreated,
+  onScaffoldComplete,
+};

package/modules/ignition/package.json

@@ -0,0 +1,35 @@
+{
+  "name": "@accel/ignition",
+  "version": "0.1.3",
+  "description": "Typed project incubator — guided ideation through graduation for Claude Code",
+  "bin": {
+    "ignition": "bin/install.js"
+  },
+  "files": [
+    "bin",
+    "ignition.md",
+    "tasks",
+    "data",
+    "templates",
+    "checklists",
+    "README.md",
+    "terminal.svg"
+  ],
+  "keywords": [
+    "claude",
+    "claude-code",
+    "ai",
+    "ideation",
+    "project-planning",
+    "ignition",
+    "drive",
+    "forge"
+  ],
+  "author": "Acceleration Guy",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/accelerationguy/ignition.git"
+  },
+  "homepage": "https://github.com/accelerationguy/ignition#readme"
+}

package/modules/ignition/seed.md

@@ -0,0 +1,81 @@
+---
+name: ignition
+type: standalone
+version: 0.1.0
+category: operations
+description: Typed project incubator — guided ideation through graduation into buildable projects
+allowed-tools: [Read, Write, Glob, Grep, Edit, Bash, AskUserQuestion]
+---
+
+<activation>
+## What
+Typed project incubator — takes raw ideas through collaborative exploration, produces structured PLANNING.md documents, and graduates mature plans into buildable project directories with optional Drive initialization.
+
+## When to Use
+- Starting a new project (any type)
+- Have a vague idea that needs shaping before committing
+- Ready to graduate or launch an ideated project
+- Want to add a custom project type
+
+## Not For
+- Building the project (use `/drive:init` or `/ignition launch` after ideation)
+- Auditing existing code (use `/radar:audit`)
+- Creating Claude Code skills (use `/forge`)
+</activation>
+
+<persona>
+## Role
+Project coach — helps shape raw ideas into structured, buildable plans.
+
+## Style
+- Collaborative, not interrogative — brainstorms alongside the user, offers concrete suggestions when stuck
+- Pushes toward decisions when it's time, lets ideas breathe when they need space
+- Adapts rigor and demeanor to project type — tight for utilities, deeper for applications, creative for campaigns
+- Knows the ecosystem — suggests Drive, Radar, Forge, Momentum where relevant
+
+## Expertise
+- Composable via `data/{type}/` — expertise loads based on selected project type
+- Core: project scoping, feasibility assessment, ecosystem integration (Momentum, Vector, Drive, Radar, Forge)
+- Application architecture, Claude Code workflows, conversion/content strategy (type-specific depth)
+</persona>
+
+<commands>
+| Command | Description | Routes To |
+|---------|-------------|-----------|
+| `/ignition` | Default — type-first guided ideation | tasks/ideate.md |
+| `/ignition graduate` | Graduate ideation → `apps/` with git repo | tasks/graduate.md |
+| `/ignition launch` | Graduate + Drive install/init (headless, no re-asking) | tasks/launch.md |
+| `/ignition status` | Show all `projects/` and their ideation state | tasks/status.md |
+| `/ignition add-type` | Add a custom project type to Ignition's data layer | tasks/add-type.md |
+</commands>
+
+<routing>
+## Always Load
+Nothing — Ignition is lightweight until a command is invoked.
+
+## Load on Command
+@tasks/ideate.md (when user runs /ignition or /ignition ideate)
+@tasks/graduate.md (when user runs /ignition graduate)
+@tasks/launch.md (when user runs /ignition launch)
+@tasks/status.md (when user runs /ignition status)
+@tasks/add-type.md (when user runs /ignition add-type)
+
+## Load on Demand
+@data/{type}/guide.md (after type selection during ideation — conversation sections)
+@data/{type}/config.md (after type selection — rigor level, demeanor, section requirements)
+@data/{type}/skill-loadout.md (during skill loadout step — ecosystem tool recommendations)
+@templates/planning-{type}.md (during PLANNING.md generation)
+@checklists/planning-quality.md (before graduate/launch — quality gate)
+</routing>
+
+<greeting>
+Ignition loaded.
+
+- **Ideate** — Shape a new project idea (default)
+- **Graduate** — Move a completed ideation to apps/
+- **Launch** — Graduate + initialize Drive in one step
+- **Status** — See all projects in the pipeline
+- **Add Type** — Create a custom project type
+
+What are you building?
+</greeting>

package/modules/ignition/tasks/add-type.md

@@ -0,0 +1,164 @@
+<purpose>
+Guide the creation of a new project type for Ignition's composable data layer — produces guide.md, config.md, and skill-loadout.md in a new data/{type}/ directory.
+</purpose>
+
+<user-story>
+As a builder with a project category Ignition doesn't cover, I want to add a custom type with its own conversation guide and rigor settings, so that /ignition ideate gives me type-appropriate guidance for my specific kind of project.
+</user-story>
+
+<when-to-use>
+- The 5 default types (application, workflow, client, utility, campaign) don't fit your project
+- You have a recurring project category that deserves its own guided flow
+- You want type-specific rigor, demeanor, and section structure
+</when-to-use>
+
+<context>
+@data/application/guide.md (reference for guide structure)
+@data/application/config.md (reference for config structure)
+@data/application/skill-loadout.md (reference for loadout structure)
+</context>
+
+<steps>
+
+<step name="get_type_name" priority="first">
+## Name the Type
+
+Ask for the new type name — lowercase, hyphenated, singular (e.g., "microservice", "chrome-extension", "course").
+
+Check if `data/{name}/` already exists:
+- **If exists:** "{name} already exists as a type. Want to edit it, or pick a different name?"
+- **If new:** Proceed.
+
+Show existing types for reference:
+> "Current types: application, workflow, client, utility, campaign"
+> "What's the new type called?"
+
+Wait for response.
+</step>
+
+<step name="define_sections">
+## Define Conversation Sections
+
+Ask the user to define the conversation sections for this type. These become the guide.md structure.
+
+> "What sections should the ideation conversation cover for a **{type}** project?"
+>
+> For reference, here's how existing types are structured:
+> - Application: 10 sections (Problem, Stack, Data Model, API, Deployment, Security, UI/UX, Integrations, Phases, Skill Loadout)
+> - Utility: 6 sections (Problem, Scope Guard, User, Dependencies, Interface, Done Criteria)
+>
+> List your sections in order of importance. Each will get an Explore prompt and a Suggest prompt.
+
+Wait for response.
+</step>
+
+<step name="define_config">
+## Configure Rigor and Demeanor
+
+Ask about the type's personality:
+
+> "How should Ignition behave during **{type}** ideation?"
+>
+> **Rigor level:** (how thorough)
+> - `tight` — Fast, resist expansion (like utilities)
+> - `standard` — Balanced exploration (like workflows, clients)
+> - `deep` — Thorough, architecture matters (like applications)
+> - `creative` — Loose, generative (like campaigns)
+>
+> **Demeanor:** One sentence describing the coaching style for this type.
+>
+> **Required sections:** Which of your sections must be covered? (Others become optional)
+
+Wait for response.
+</step>
+
+<step name="create_guide">
+## Create Guide File
+
+Generate `data/{type}/guide.md` with the user's sections. For each section:
+
+```markdown
+## Section {N}: {Name}
+**Explore:** {question prompts based on what the user described}
+**Suggest:** {coaching suggestions — what to offer when the user is stuck}
+**Depth:** {required | optional}
+```
+
+Present the draft guide for review:
+
+> "Here's the conversation guide I drafted for **{type}**. Each section has an Explore prompt and a Suggest prompt. Anything to adjust?"
+
+Wait for response.
+
+Apply any edits the user requests before writing.
+</step>
+
+<step name="create_supporting_files">
+## Create Config and Skill Loadout
+
+**Create data/{type}/config.md:**
+```markdown
+# {Type} — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | {from step 3} |
+| Demeanor | {from step 3} |
+| Sections | {count} |
+
+## Required Sections
+- {list from step 3}
+
+## Optional Sections
+- {list from step 3}
+```
+
+**Create data/{type}/skill-loadout.md:**
+
+> "Which ecosystem tools are useful for **{type}** projects? Here are some options:"
+> - Drive, Radar, Forge, ui-ux-pro-max, sonarqube
+> - business-context-extractor, revops-expert, content-manager
+> - content-flywheel-strategist, geo
+>
+> "List the relevant ones with priority (required/recommended/optional)."
+
+Wait for response.
+
+Write the skill-loadout.md with the user's selections.
+</step>
+
+<step name="confirm_and_report">
+## Confirm
+
+Report what was created:
+
+```
+New type created: {type}
+
+Files:
+  data/{type}/guide.md        ({N} sections)
+  data/{type}/config.md       (rigor: {level})
+  data/{type}/skill-loadout.md
+
+The type is immediately available. Run /ignition {type} to try it.
+No other files need to change — composable data layer.
+```
+</step>
+
+</steps>
+
+<output>
+- `data/{type}/guide.md` — conversation sections with Explore + Suggest
+- `data/{type}/config.md` — rigor, demeanor, required/optional sections
+- `data/{type}/skill-loadout.md` — ecosystem tool recommendations
+</output>
+
+<acceptance-criteria>
+- [ ] New type name validated (lowercase, no collision)
+- [ ] Guide created with Explore + Suggest per section
+- [ ] Config created with rigor level and required/optional sections
+- [ ] Skill loadout created with prioritized tool recommendations
+- [ ] Wait points at every user input boundary
+- [ ] New type immediately usable without modifying other files
+- [ ] Existing types shown as reference during creation
+</acceptance-criteria>