Install HELIX
Pick the install guide for the tool that will run HELIX, such as Claude Code, Codex, DDx, or Databricks. For what HELIX is, see the thesis.
Minimal runtime contract
A HELIX-compliant runtime can:
- Read markdown files from the project’s filesystem.
- Write markdown files to the project’s filesystem.
- Search files by path or pattern across the project.
- Optionally execute a shell command for runtime-owned verification.
That is the full contract. HELIX assumes nothing else: no tracker, no queue, no execution loop, no IDE integration, no language toolchain. Items 1 through 3
are required; item 4 is optional and belongs to the runtime, not the HELIX
methodology contract.
Per-runtime install guides
Each guide names the file layout, install steps, invocation, and verification for one runtime. Pick the one that matches your environment; install more than one if you use more than one.
Source of truth
Runtime install guides are packaging notes. The normative HELIX content lives in two places:
- Skills: the HELIX skill with one public entry point (
helix), one routing table, and one set of per-mode workflow contracts. There are no separate publichelix-*skills. - Artifact types: HELIX document patterns, including templates, prompts, quality criteria, and examples for PRDs, ADRs, test plans, runbooks, and related documents.
When a per-runtime guide and the skill or catalog disagree, the skill and catalog govern.
No-fork policy
The per-runtime guides exist so adopters can install HELIX. They do not exist to localize, dialect, or rewrite the methodology.
- The normative skill body lives in
skills/helix/SKILL.mdand nowhere else. - The artifact-type catalog lives in
workflows/and nowhere else. - If a runtime requires a shim (a manifest, wrapper, or packaging document),
that shim lives inside the per-runtime guide, explicitly marked as
runtime-specific. It does not get pushed back into
skills/orworkflows/.
Three runtime guides, one HELIX source.