Haskell hx Toolchain

VerifiedCaution

Build, test, run, format, lint, and manage dependencies for Haskell projects using the hx CLI.

Sby Skills Guide Bot
DevelopmentIntermediate
2809/4/2026
Claude CodeCursorWindsurfCopilotCodex
#haskell#build-tool#toolchain#package-management#cli

Recommended for

Our review

Drives the `hx` Haskell toolchain CLI (build, check, test, run, fmt, lint, GHC and dependency management) inside a project that has an `hx.toml`.

Strengths

  • A single CLI replacing ghcup, cabal, stack, fourmolu, hlint, and hpc
  • Meaningful exit codes (0–6) so success or failure is decided without scraping output
  • Structured stderr summaries with a suggested fix that can be surfaced directly to the user
  • `hx.lock` lockfile for reproducible builds plus an MCP server (`hx mcp`) for tool-call access

Limitations

  • The first `hx build` may download a GHC of several hundred MB
  • `hx build --native` is experimental and only fits single-package, `base`-only projects
  • Project-local `.hx/plugins/*.scm` scripts do not run on a freshly cloned repo until trusted
When to use it

Use it whenever a Haskell project contains an `hx.toml`, or when the user asks to build, test, lint, or manage dependencies of Haskell code with hx.

When not to use it

Avoid it on projects that only have a `.cabal` or `stack.yaml` and no `hx.toml`, unless you explicitly plan to adopt them with `hx init` or `hx import --from stack`.

Security analysis

Caution
Quality score88/100

The skill describes a legitimate Haskell toolchain with standard build, test, and dependency management commands. It does not contain destructive or exfiltrating instructions and includes a clear warning about not trusting project-local plugins. However, because it orchestrates downloading GHC, building and running arbitrary project code, and potentially executing plugins after explicit trust, caution is warranted.

Findings
  • •Instructs executing project code via build/test/run commands, which can run arbitrary code from the repository.
  • •May download and install GHC toolchains, involving network access and large file operations.
  • •Mentions project-local plugin scripts that can run after `hx plugins trust`, though it explicitly warns against trusting untrusted projects.
  • •No allowed-tools are declared, but the skill implies shell command execution.

Examples

Build and run
Build this Haskell project, run it with --help, then run the test suite and tell me the result.
Add a dependency
Add aeson with the constraint >=2.0 to this project and rebuild to confirm it still compiles.
Pre-commit quality gate
Run the formatting check, the linter, and the tests on this repo, and report exactly which step failed and why.

name: hx description: Build, test, run, lint, format, and manage dependencies for Haskell projects using the hx toolchain CLI. Use whenever working in a Haskell project that has an hx.toml (or when setting one up), or when the user asks to build/test/run/typecheck Haskell code, manage GHC/Cabal versions, or add/remove Hackage dependencies.

hx — Haskell toolchain

hx is a single CLI that replaces ghcup, cabal, stack, fourmolu, hlint, and hpc. It manages GHC itself, uses an hx.toml manifest and an hx.lock lockfile, and returns meaningful exit codes.

Detecting that this skill applies

The project is an hx project if there is an hx.toml at (or above) the working directory. If the user has a .cabal/stack.yaml but no hx.toml, you can adopt it with hx init or hx import --from stack.

Core commands

| Goal | Command | |------|---------| | Scaffold a project | hx init <name> | | Build | hx build (--release, -j N) | | Type-check only (fast) | hx check | | Run tests | hx test (--pattern <p>) | | Build & run | hx run -- <args> | | Format / check format | hx fmt / hx fmt --check | | Lint / autofix | hx lint / hx lint --fix | | Add / remove a dependency | hx add <pkg> "<constraint>" / hx rm <pkg> | | Lock / build from lock | hx lock / hx sync | | Diagnose the environment | hx doctor | | Install/manage GHC | hx toolchain install |

Run hx <command> --help for flags. --quiet/--verbose are global; NO_COLOR is respected.

Interpreting results — exit codes

Decide success/failure from the exit code, not by scraping output:

  • 0 success · 1 general error · 2 bad arguments · 3 bad hx.toml
  • 4 toolchain error (GHC/Cabal missing or mismatched — run hx doctor)
  • 5 build/test failure · 6 plugin hook failure

Errors print a structured summary with a suggested fix on stderr; surface that fix to the user.

Typical workflows

# new project
hx init myapp && cd myapp && hx build && hx run

# add a dependency and rebuild
hx add aeson ">=2.0" && hx build

# pre-commit quality gate
hx fmt --check && hx lint && hx test

# reproducible build
hx lock && hx sync

Important behavior

  • Toolchain auto-install: the first hx build may download a GHC (hundreds of MB). hx doctor returns exit 4 when a required tool is missing and tells you how to install it.
  • hx build --native is experimental — a fast path for single-package, base-only projects; it falls back to cabal otherwise. Don't use it for multi-dependency projects.
  • Plugins require trust: project-local .hx/plugins/*.scm scripts do not run on a freshly cloned repo. Never run hx plugins trust on a project you don't trust.

Programmatic / MCP use

For tool-call access instead of shelling out, run hx mcp (an MCP server over stdio) — it exposes build/check/test/run/lock/sync/fmt/lint/doctor and dependency tools. See AGENTS.md in the repo.

Related skills