Pipeline Overview

The end-to-end Propel workflow: from user idea to validated implementation, with human checkpoints at every phase transition.

The Problem Propel Solves

An unconstrained LLM will skip straight to implementation when you say "implement X." Without guardrails, Claude fills in gaps with the mean of its training data — plausible-looking but often wrong implementations built from averaged patterns rather than project-specific knowledge.

Vague requests like "build a can transport task with robosuite" lead to implementations that look reasonable but silently diverge from what you actually need. Claude fills architectural gaps with defaults instead of asking. The result: hours of debugging code that was wrong from the start because the problem was never properly scoped.

Propel solves this by injecting a structured workflow into every Claude session — a pipeline of gates, questioners, investigations, and auditors that forces investigation before implementation and human approval before phase transitions.

End-to-End Flow

The complete Propel pipeline has 12 phases, connected by 5 gates and 2 questioner checkpoints:

User idea → Gate 0 → Q0 → Investigation → Gate 1 → Q1 → Design → Gate 2 → Implementation → Gate 3 (loop) → Validation → Debugging → Gate 4 → Training → Retrospective

Each phase serves a distinct purpose in the pipeline:

Pipeline Diagram

The following diagram shows which phases are active in each mode. Filled blocks (█) indicate active phases; diamond blocks (◆) indicate questioner checkpoints:

                    Researcher          Engineer            Debugger            Trainer
                    ──────────          ────────            ────────            ───────
Gate 0  Intake      ██████████          ██████████          ██████████
                        |                   |                   |
  Q0    Questioner      ◆◆◆◆◆◆◆◆◆◆          ◆◆◆◆◆◆◆◆◆◆
        (grounding)     |                   |
        Investigation   ██████████          ██████████          ██████████
                        |                   |                   |
Gate 1  Post-Invest.    ██████████          ██████████          ██████████
                        |                   |                   |
  Q1    Questioner      ◆◆◆◆◆◆◆◆◆◆          ◆◆◆◆◆◆◆◆◆◆          |
        (details)                           |                   |
        Design                              ██████████          |
                                            |                   |
Gate 2  Post-Design                         ██████████          |
                                            |                   |
        Implementation                      ██████████          |
                                            |               ┌────┴─────┐
Gate 3  Mid-Impl.                           ██████████      | classify |
                                            |               | evidence |
        Validation                          ██████████      | lit srch |
                                                            └────┬─────┘
        Training                            ██████████           |         ┌──────────┐
                                            |                   |         | scan,    |
        Debugging                           ██████████          ██████████ | launch,  |
                                            |                   |         | monitor  |
Gate 4  Post-Debug                          ██████████          ██████████ └────┬─────┘
                                            |                   |              |
        Retrospective   ██████████          ██████████          ██████████ ██████████
                                                                          (runtime only)

Mode Filtering

Not every session uses the full pipeline. Propel's four modes filter which phases and gates are active, so you only engage the checkpoints relevant to your task.

Gates by Mode

Phases by Mode

The Injection Mechanism

An unconstrained Claude will ignore the pipeline and skip to implementation. Propel prevents this through a hook-based injection system that loads the full workflow into Claude's context before it sees your first message.

How It Works

propel init
  ↓
Copies skills/, agents/, commands/, hooks/ into .claude/
Merges hook config into .claude/settings.local.json
  ↓
User starts `claude`
  ↓
SessionStart hook fires → runs session-start.sh
  ↓
Injects full using-propel/SKILL.md content as JSON into Claude's context
(Also injects: active investigations, project profile, registry entries)
  ↓
Claude's context now contains:
  1. Core principles (core/CORE.md — non-negotiable mindset rules)
  2. The gate protocol (5 mandatory gates)
  3. The skill routing table (which skill for which trigger)
  4. The auditor dispatch rules (which agent after which code change)
  5. Active investigation state (scratch/ READMEs)
  6. Project profile (.propel/profile.md, if it exists)
  7. Current mode + mode_selection_needed (.propel/mode.json)
  8. Empty repo flag (whether to use progressive CLAUDE.md building)

What Each Layer Provides

Redundant Constraint Layers

Propel's reliability comes from redundancy. No single layer is critical — if one fails, the others still constrain Claude. This is the difference between "please follow this process" and having the process embedded in every layer of context.

Skill description match  →  "activates before any action"
Hook injection           →  full routing table in context
CLAUDE.md                →  "This project uses the Propel research workflow"
Auditor dispatch rules   →  agents auto-run after code changes

The system is prompt-based, not mechanically enforced. There is no code-level gate that blocks Claude from skipping a step. Claude follows the workflow because:

1. The hook injects the full routing table into context before Claude sees your first message
2. The using-propel skill description says "activates before any action" — Claude Code's skill matching prioritizes this
3. The instructions are specific and structured (routing tables, not vague guidelines)
4. The PreCompact hook re-injects on compaction, so instructions survive long sessions