A Turnkey Toolkit for Agentic Development with Flox

Claude Code, Codex, OpenCode, Hermes Agent, Pi, OpenClaw. These are the agentic harnesses people can’t seem to stop obsessing about. But the harness by itself isn’t actually the most important tool in the agentic toolkit. Arguably, it’s the domain- or use-case-specific enhancements—the skills, tools, persistent memory, sandboxes, software for managing swarms of agents at once—that most matter.

These give coding agents an understanding of their environing world, what they can do, what they have to work with, what matters… and what doesn’t. This also presupposes a definite environment in which an agent runs: a world consisting of pinned software packages, standard shell settings, and runtime services. It’s the one part of the stack that can be made reproducible, the one thing you can control… even when the behavior and output of stochastic agents isn’t and can’t.

Enter Flox: a cross-language, cross-toolchain package manager that works across operating system and CPU/GPU architectures. Agentic tools use Flox to discover, find specific versions of, and install just the right dependencies, searching among millions of historical package versions. Flox doesn’t require using containers, installing (or changing) system-wide packages, or clobbering installed dependencies.

Worlds within worlds

Because Flox is also a cross-platform, cross-language, cross-architecture virtual environment manager, agentic tools won’t burn tokens resolving dependency conflicts. It’s even straightforward to run conflicting versions of dependencies in the same runtime, at the same time. Need OpenSSL versions 1.1.1q and 3.0.19 in the same Flox environment, side by side? No problem!

Best of all, Flox runs directly on your system—no containers or VMs required.

And when you (or your Hermes, Pi, or Claude Code minions) are ready to share what you’ve created, the Flox environments that you built and perfected locally Just Work when friends, coworkers, or random users (human and agentic alike) pull and run them on their own machines.

Read on to find out why Flox and FloxHub are perfect for vibe coding, prototyping, and agentic engineering… and how the Flox environments you work with locally travel to CI and prod, too.

Looking for a specific agentic tool? Skip straight to the category that interests you:

Agentic development with Flox

This repo consolidates nearly 80 environments into a one-stop resource for agentic development. Each folder is its own turnkey Flox environment, complete with a README.md that explains what it is, how it works, and what features / affordances it offers.

Clone it to get started:

git clone https://github.com/flox/agentic-development-with-flox

Once you download and install Flox, you can start Flox environments by running:

$ flox activate

None of the repo’s environments includes a committed manifest.lock file, so first-time activation must resolve dependencies via the Flox Catalog. That requires a FloxHub login (which is free): just run flox auth login first. After a successful resolution, Flox saves the lockfile locally, and activation with a valid lockfile doesn’t require login. If you want to try one of these environments, cd into its folder before activating it.

If an environment defines services—like MCP servers, databases, model servers, workflow scheduling engines (like Airflow), and so on—you can either start them at runtime or from within an activated session.

$ flox activate -s
 
## or:
 
$ flox services start <optional_service_name>        # if more than one service is defined

This is all you need to start working with any of these tools, once you’ve configured whatever model credentials they require. As for the AI agents/assistants included with this repo, several get the knowledge + context they need from the Flox flox, floxify, and flox-debug skills; others will benefit from reading and referring back to the FLOX.md file that’s baked into the root of this repo. Flox retired its own MCP server in October 2026, chiefly because—as a thin wrapper around our CLI—agents could use the CLI directly. Flox focused its efforts on skills to make the best use of the CLI, bolstered by scripts to lower token costs and increase determinism.

Some tools don’t need to know anything about Flox: Flox just provides the world (and a declarative, predictable mechanism for reproducing this world) that lets them run anytime/anywhere. How they run and what you do with them is up to you—or (Skynet isn’t a thing yet, right?) them…?

Making agents reproducible, too

Flox is also sponsoring Agent Stacks, an open source project aimed at making the agents themselves reproducible. Consider everything that goes into a typical agent setup: the agent, its skills, plugins, MCP servers, and the runtimes those components depend on. Install all of that ad hoc, and two developers running the “same” agent can end up running very different software.

Agent Stacks packages these components together, pins their versions, and gives you a launcher that makes everything available to the agent without modifying your global configuration. Its agent-pkgs repository already contains hundreds of packaged plugins, including the Flox skills, and there's a Claude Code reference implementation you can try today.

The specification is still a draft, and features like sandboxing and secrets management remain works in progress. But the idea is compelling: if we're going to make development environments reproducible for agents, why not make the agents themselves reproducible?

Terminal coding agents

claude-code

Anthropic's official Claude Code CLI bundled with the Flox flox, floxify, and flox-debug skills. These give Claude Code the knowledge + context to discover packages, create and modify Flox environments, and troubleshoot the ones that don’t work as expected. Creates a turnkey Claude Code development environment with built-in Flox integration. The activation hook also removes the old Flox MCP registration if it finds one.

Note: This environment should pick up new versions of Claude Code as they become available; just run flox upgrade within the repo directory to force an upgrade.

codex

OpenAI's local AI coding agent with ChatGPT account integration and approval-based command execution. (For full filesystem access, use codex --sandbox danger-full-access; approval controls are separate.) This environment includes the Flox skills and removes the old Flox MCP entry if one is present.

OpenCode

Open-source AI coding agent built for the terminal. Its TUI lets you switch between “build” (for interactive development) and “plan” (for analysis + code exploration) agents. In “plan” mode, OpenCode defaults to read-only behavior, asks before running shell commands, and is geared toward planning changes. You can point OpenCode at Anthropic’s Claude, OpenAI’s GPT models, or Google Gemini, along with local providers (like Ollama). Uses a client/server architecture so the TUI is just one possible client. (You can run the agent on one machine and drive it from another client). OpenCode offers an optional (beta) desktop app, plus an internal “@general” subagent that can perform complex searches + multi-step tasks.

pi

A deliberately minimal terminal coding agent. Pi gives the model four tools—read, bash, edit, write—and lets you add what you need with skills, extensions, prompt templates, themes, or Pi packages. It supports multiple providers and models, so you don’t need to buy into a single model vendor to use it. And it has an appealingly small amount of machinery between you, your code, and the model.

The Flox environment includes the flox, floxify, and flox-debug skills. Pi has also added native MCP support, for anyone who still wants to connect tool servers. (Skills and MCP aren’t enemies. One supplies instructions and practices; the other supplies connections to external systems.)

crush

Charm's glamorous, stylish, and surprisingly powerful AI coding agent front-end. (Full disclosure: We here at Flox are fans.) Ships with a self-bootstrapping wizard that encrypts/stores secrets using system keyring (if available). Supports multiple providers—including Ollama! The Flox skills are pre-integrated, too. Arguably the most versatile agentic coding assistant out there.

copilot-cli

GitHub Copilot’s terminal-based agent, with repository context and access to GitHub workflows. Talk to it about a codebase, ask it to investigate issues or make changes, and review what it proposes before letting it run commands. The Flox environment includes the Flox skills, so Copilot can work with the same package and environment setup as the other agents in this repo.

Claw-adjacent agents

The “claw” cluster is a loose family of self-hosted, open-source personal/coding-agent stacks with overlapping design goals (viz.: local-first, sandboxed, multi-channel, pluggable providers) but built in different languages with wildly different tradeoffs. If you want to test-drive several of these stacks side by side, Flox offers arguably the path of least resistance: You could even activate each environment and run them at the same time; you don’t need to worry about them stomping on one another’s runtimes or config.

hermes-agent

AI agent from Nous Research with a built-in learning loop. Hermes identifies routine work and turns it into reusable skills, improves them during use, nudges itself to persist knowledge, and searches conversation history for recall across sessions. Runs as a persistent gateway you can talk to from a TUI and/or messaging platforms like Discord, Slack, WhatsApp, Signal, and email.

Model choice is wide open: Nous Portal, OpenRouter, NVIDIA NIM, Hugging Face, OpenAI, and other compatible endpoints, all switchable via hermes model. Hermes also supports scheduled automations, spinning up isolated subagents for concurrent work, and multiple backends, so it can run on anything from a cheap VPS to a cloud GPU cluster. Hermes feels like a close relative of the seminal OpenClaw agent, but with a focus on learning from past work, building reusable behaviors, and running as a persistent agent.

Speaking of which….

openclaw

Self-hosted AI assistant and agent platform. OpenClaw runs a persistent local gateway that multiple frontends can connect to: a built-in TUI, single-turn CLI agent mode, or external chat channels (Telegram, Discord, WhatsApp). Uses OpenRouter as its model provider, facilitating access to a large catalog of models (Claude, GPT, Gemini, Llama, etc.) via a single API key. Features agent workspaces with session persistence, cron scheduling, plugin/skill systems, a browser automation subsystem, and sandbox containers for agent isolation. Includes a doctor command for health checks and self-repair.

This Flox environment runs the gateway as a managed service (flox activate -s) that stops automatically when you exit. This means no orphaned daemons or persistent systemd units.

ironclaw

Secure personal AI assistant written in Rust by NEAR AI. Built around WASM-sandboxed tool execution with capability-based permissions, credential-leak detection, and HTTP allowlisting. Persistent memory runs on PostgreSQL + pgvector if you flox activate -s, enabling hybrid full-text and vector search (Reciprocal Rank Fusion); runs on an embedded libSQL database if you run without services (e.g., flox activate). Multi-provider (NEAR AI, Anthropic, OpenAI, Gemini, Copilot, Ollama, Mistral, OpenRouter, and more) and multi-channel (REPL, HTTP webhooks, Web Gateway, Telegram, Slack) via WASM channels. A routines engine handles cron schedules, event triggers, webhook handlers, and heartbeat loops; a dynamic-tools feature can build new WASM tools from natural-language descriptions. Note: This Flox environment auto-detects Postgres-mode vs libSQL-mode based on whether you run flox activate -s.

The repo also includes lighter or more specialized relatives, including nullclaw, claw-code, and claurst. They’re still available if that particular tradeoff interests you; they’re just not where I’d start a tour of the agentic tools people are gravitating toward in late 2026.

Multi-agent orchestration & parallel workflows

The next cluster is all about running multiple agents at once: either coordinating specialized sub-agents inside a single task, or fanning out several independent agents across isolated workspaces so you can review their work as it lands.

herdr

Think of Herdr as a tmux-like workspace manager that “understands” coding agents. It can track Claude Code, Codex, OpenCode, Pi, Hermes, and others in separate terminal panes, showing which are busy, which are waiting for interactive input, and which have finished. The panes survive terminal disconnects, and you can attach remotely over SSH. Run one agent, five agents, whatever you want; Herdr is about keeping track of what they’re all doing without juggling terminal windows.

Its server runs independently of the Flox session, just as a tmux server does. That’s intentional: you detach and the agents keep working. Stop it explicitly with herdr server stop when you’re done.

worktrunk

A git worktree manager designed for running coding agents side by side. One task gets one branch and one worktree, so two agents—or you and an agent—don’t work on the same files at the same time. wt switch -c creates the worktree; wt list shows what’s happening; wt merge gets the finished work back into the main checkout. Less exciting than a swarm of 100 autonomous agents, perhaps, but also less likely to micturate upon one another’s work. Worktrunk, then, really ties the room together.

xum (née mux)

xum lets you plan and run tasks using multiple agents at the same time, each getting its own isolated workspace: git worktree, Docker container, SSH remote, or local directory. Multi-provider (Anthropic, OpenAI, Google, xAI, DeepSeek, OpenRouter, Ollama, AWS Bedrock, GitHub Copilot) with a plan/exec loop and built-in orchestrator sub-agents (exec, explore, plan). Use the one-shot CLI (xum run "Refactor the auth module"), the browser UI (start the Flox service and hit localhost:3000), or the desktop app. Perfect for “fan out N tasks, review diffs as they land”-type workflows.

ruflo

Multi-agent orchestration platform that sits on top of Claude Code. (Formerly known as Claude Flow.) Ruflo coordinates specialized role-based agents—coder, tester, reviewer, architect, security, etc.—and adds memory, routing, and MCP integrations. There’s a lot going on here, and some of the project’s marketing claims are difficult to independently verify. Ruflo installs ruflo@latest via npm on first activation of this Flox environment. That means the downloaded version isn’t pinned by Flox, so inspect what you’re installing before giving it access to a repo or credentials.

Skills, browser automation & MCP

There’s another big change since OpenClaw first dropped: much of the interesting work has moved from choosing the agent to choosing what the agent knows and can safely do. Skills package up instructions, reference material, and repeatable workflows. MCP connects agents to tools and services. You’ll find both in the wild, often in the same setup. It turns out there’s no law requiring you to pick a side.

Flox has made the same shift. Its old MCP server is retired; the maintained Flox skills are flox, floxify, and flox-debug. They teach supported agents how to work with Flox rather than forcing every operation through a dedicated Flox MCP server. The floxify skill is particularly useful when you inherit a repo whose setup instructions nobody trusts: have an agent inspect the project and create a Flox environment for it. The agent does the detective work once; the environment is what you keep.

agent-browser

Browser automation aimed at agents rather than people. Instead of dumping a huge blob of HTML into the context window and hoping the model finds the right button, agent-browser gives it a compact accessibility snapshot with element references it can click, fill, inspect, or screenshot. It works as a CLI or MCP server. The Flox environment provides Chromium on Linux, so there’s no separate browser download there. Browser automation is especially useful once you want the agent to test the application it just wrote.

mcporter

Lets an agent call MCP tools from the shell: list servers, inspect their schemas, invoke a tool, and get the result as text or JSON. Mcporter can reuse MCP server definitions already configured for Claude Code, Codex, Cursor, and other agents, or connect directly to a server. It can even turn a tool server into a standalone CLI. This is a useful counterexample to the notion that MCP has somehow gone away.

Sandboxing & supply-chain security

Giving an agent the tools it needs to install packages, run commands, and mutate files is useful. It also invites the question as to what agent can and can’t do. Sandboxing software gives you a way to confine agents to a restricted environment—a “jail,” so to speak—and control which files they can read or mutate; which (if any) network destinations they can reach; and what local resources they can access. If an agent gets confused, makes mistakes, or goes rogue, a sandbox helps contain the damage.

nono

Kernel-enforced sandbox for AI agents. nono run --allow-cwd -- <command> runs an agent, an MCP server, or any command such that it writes only to the current directory. Credentials like ~/.ssh stay unreadable. No root, container, or VM is involved; on Linux it uses Landlock. You can cut off network access (--block-net) or allow only listed domains (e.g., --allow-domain api.anthropic.com). Snapshot a project with --rollback and restore it if/when an agent goes off the rails. Signed, ready-made profiles for Claude Code, Codex, pi, OpenCode, and others come from nono's registry. Every session lands in a tamper-evident audit log.

nono's default profile can't see the Nix store, so the Flox environment adds a nono-flox-profile helper. It extends any profile with access to /nix/store and to other active Flox environments, so Flox-installed agents and their wrappers run inside the nono sandbox. Layer it on top of an agent environment, then run, for example, nono run --allow-cwd --profile "$(nono-flox-profile nolabs-ai/claude)" -- claude. Like any sandbox, it’s a way to limit the blast radius vis-a-vis the damage an AI agent run amok can do.

sandbox-runtime

Anthropic’s lightweight sandbox for coding agents and other commands. Runs a process—and the processes it starts—with filesystem and network restrictions using operating-system facilities, without requiring a container. On Linux it uses bubblewrap; on macOS, sandbox-exec. Give an agent enough access to work on the code in front of it, not the entire contents of your home directory. Flox manages the dependencies; the sandbox manages what the process can touch. Different jobs.

agent-lint

Six scanners and validators for agent skills and configurations, including NVIDIA’s SkillSpector. Scan a downloaded skill for suspicious instructions, dependency behavior, credential access, or scripts that fetch more scripts; check your own skills and agent settings before you commit them. Linters and scanners aren’t proof that code is benign, but they’re a much better idea than installing an anonymous skill and hoping for the best.

sfw

Socket Firewall Free (sfw) checks packages against known-malware data as package managers fetch them. The Flox environment puts shims for npm, npx, yarn, pnpm, pip, uv, cargo, and a few aliases in $PATH, so agent-invoked commands (like npm install) also go through sfw. It's another layer of protection, not a substitute for vetting untrusted packages or limiting an agent's privileges.

Memory & context

A tool can keep every conversation in a log and still have no idea which details from Tuesday matter most on Friday. Long-running agent work creates a different kind of problem: teams need a way to reuse useful knowledge across sessions without requiring models to reread the complete project history every time.

honcho

Persistent memory for agents, backed by sessions, messages, and a background worker whose job it is to turn conversations into facts, preferences, and summaries. Honcho can answer questions about what an agent has learned about a project or person over time. The Flox environment runs its API, the background worker, and a local PostgreSQL + pgvector database as managed services.

Honcho also integrates with Hermes Agent, which adds semantic search and persistent user modeling to Hermes's built-in memory. With PostgreSQL's pgvector extension, it uses vector embeddings to search memories by meaning rather than keywords, finding relevant information even when an agent's question uses different words than the original conversation.

basic-memory

The less elaborate alternative: store memories as ordinary Markdown files in a directory you own, with links and a local searchable index. Agents can read and write those notes over MCP. You can also open them in your editor, grep them, commit them, or decide a particular memory was a bad idea and delete it. And the knowledge isn’t trapped inside somebody else’s opaque state store.

serena

Gives coding agents semantic code navigation backed by language servers: find a symbol, follow references, inspect implementations, or replace a function instead of guessing where it lives from a text search. Serena also stores project memories.

Keeping tabs on token spend

It’s now trivially easy to run several agents at once. It’s also no less easy to outfit agents with browsers, tools, and memories. And, by the same token, it’s easy to get an extremely unpleasant surprise when the bill for all of this agentic work comes due. Finops for AI is impossible to ignore in this era of agentic engineering.

ccusage

Reads the logs agents already write to disk and reports token counts and estimated costs by day, session, or billing window. It supports Claude Code, Codex, OpenCode, Pi, and others, with a status-line integration for Claude Code. No extra service or telemetry collector needed.

codeburn

A richer dashboard for tracking agent spend across models, projects, and tasks. CodeBurn reads local session logs, with TUI, web, and machine-readable reports. Useful for finding the agents or workflows that consume the most tokens, or for comparing a local-model experiment against a paid API workflow.

Agentic IDEs

Both of these are full desktop IDEs rather than TUIs, and both orchestrate multiple agents—but their philosophies are very different. Antigravity is Google’s agent-first VS Code fork built around a Mission Control dashboard; Kiro is a spec-first IDE that formalizes planning, constraints, and automation via first-class workflow primitives.

antigravity

Google’s agent-first IDE: a deep fork of VS Code that integrates Gemini (and Claude) for autonomous multi-agent coding. Three surfaces: a familiar Editor with inline AI commands (Cmd/Ctrl+I) and tab completions; a Manager (“Mission Control”) view for spawning and monitoring parallel autonomous agents across workspaces; and an integrated Browser for agent-driven web testing. Multi-model: Gemini and Claude models (with the specific lineup changing as Google updates the service). Agents produce artifacts—code diffs, screenshots, browser recordings, implementation plans—that you review asynchronously. Per-project agents.md and skills.md files provide persistent instructions and reusable skills (à la CLAUDE.md). Sign in with a supported Google account; model access and quotas depend on your plan.

kiro

Kiro is a spec-first desktop IDE (also VS Code-based) that embeds a coding agent. Instead of a chat-driven UX, Kiro incorporates first-class workflow primitives—specs, steering files, and hooks—to formalize how work gets planned, constrained, and automated. It turns prompts into specs, extracting requirements and producing an implementation plan; markdown steering files apply persistent guidance across tasks; hooks fire on file events to automate quality gates. Kiro codebase-indexes your workspace by scanning + tracking code, configs, docs, and dependencies. The IDE runs locally, but AWS operates the backend and powers inference via Amazon Bedrock. Kiro also has a CLI for agentic workflows outside the editor.

Local inference for agents

agentic-ollama

Ollama paired with a curated set of CLI coding agents, pre-wired for ollama launch. Pull a tool-use-capable model (ollama pull gemma4, qwen3, devstral, llama4, …), start the service with flox activate -s, and launch any bundled agent against it in one command: ollama launch claude --model gemma4, ollama launch codex --model gemma4, ollama launch opencode --model gemma4, ollama launch openclaw --model gemma4 (if you enable the optional OpenClaw package in this environment). Includes Flox skills for supported agents. GPU accelerated on supported platforms (Nvidia CUDA, Apple Metal/MPS), with CPU fallback; edit the manifest to swap ollama-cuda for ollama-rocm on AMD. The one-command path from “downloaded a model” to “running a coding agent against it locally.”

lmstudio

Headless-by-default local inference server with a desktop GUI when you want one. Runs llama.cpp everywhere and MLX on Apple Silicon. Exposes both an OpenAI-compatible API (/v1/chat/completions) and an Anthropic-compatible API (/v1/messages) on localhost:1234—drop-in for either SDK. Supports tool calling, JSON-schema structured output, MCP servers, and configurable parallel inference slots (default 4). The headless daemon starts automatically via flox activate -s; opt into the GUI with LMS_GUI=true. Designed to be composed into other Flox environments: when you want a local backend that speaks Anthropic’s protocol, not just OpenAI’s, this is the one.

The next four are production-grade inference engines. They’re almost certainly overkill for a single developer vibe-coding against a local model—Ollama or LM Studio will serve you better day-to-day—but they’re cool to have on hand when you need serious throughput, multi-GPU deployments, or want to experiment with the runtimes that actually power production LLM serving. All four are x86_64-linux only and require an NVIDIA GPU with a recent NVIDIA® CUDA® driver.

vllm

Production inference and serving engine, optimized for high throughput and low latency via PagedAttention KV-cache management and continuous batching. This Flox environment installs flox-cuda/python3Packages.vllm from the catalog along with flox/vllm-flox-runtime (model provisioning + serving scripts). Exposes an OpenAI-compatible API on localhost:8000. Override the model at activation with VLLM_MODEL and VLLM_MODEL_ORG env vars. Supports streaming, prefix caching, Multi-LoRA, distributed inference (tensor/pipeline/data/expert parallelism), and INT4/INT8/FP8 quantization. Handles MoE, embeddings, and multimodal models from Hugging Face.

llamacpp

llama-server wrapped as a production Flox environment. Where vLLM serves full HuggingFace model directories, llama.cpp serves GGUF files—single files or split shard sets—so quantized models run out of the box with no torch dependency and the entire runtime is a single compiled binary. Uses flox-cuda/llama-cpp (CUDA 12.9, driver 575+). Defaults to microsoft/Phi-4-mini-instruct-GGUF (Q8_0, ~3.9 GB) on localhost:8080 with GPU offload and continuous batching. Override the model at activation with LLAMACPP_MODEL, LLAMACPP_MODEL_ORG, LLAMACPP_MODEL_ID, and LLAMACPP_MODEL_FILE. OpenAI-compatible API.

sglang

High-performance serving framework focused on structured generation, constrained decoding, and complex multi-call LLM programs. CUDA 12.8 (driver 550+), AVX2 required. The default manifest targets an all-SM build covering T4, A10, A100, L40, H100, B200, and RTX 3090/4090/5090 (SM75–SM120); swap in a GPU-family-specific package (e.g., flox/sglang-python312-cuda12_8-sm89-avx2 for Ada Lovelace) if you want a tighter build. Defaults to Phi-4-mini-instruct-FP8-TORCHAO on localhost:30000; override with SGLANG_MODEL at activation. Supports tensor parallelism across multiple GPUs (SGLANG_TP_SIZE=4) for 70B-class models and attention-backend tuning for older GPUs (SGLANG_ATTENTION_BACKEND=triton).

nvidia-triton

NVIDIA’s Triton Inference Server (now part of Dynamo-Triton), built from source via Nix and shipped with four backends: Python, ONNX Runtime, vLLM, and TensorRT. Triton serves model repositories—directories containing versioned subdirectories with backend-specific artifacts and optional config.pbtxt files—and exposes HTTP, gRPC, and Prometheus metrics simultaneously on separate ports. This runtime handles the operational lifecycle: port reclaim, model provisioning, environment validation, and process management. Defaults to Phi-3.5-mini-instruct-AWQ via the vLLM backend with zero network access (the model is installed as a Flox package, ~2.2 GB). Opt into an OpenAI-compatible frontend on port 9000 with TRITON_OPENAI_FRONTEND=true. This is the one you reach for when you need to serve many models concurrently across mixed backends with production-grade observability.

Spec tools

OpenSpec and GitHub’s spec-kit both push the same idea: make AI-assisted coding more predictable by turning requirements into versioned, reviewable artifacts you can diff, test against, and hold the implementation accountable to. Align on intent before any code is generated; keep an auditable trail from spec → tasks → changes.

openspec

A spec workflow you add to your existing repos so you + your AI coding assistant can align on intended behavior. Run openspec init to create an openspec/ sub-folder structure: openspec/specs/ stores the current source-of-truth specs; openspec/changes/ the per-feature change folders that bundle a proposal. This path also stores a task checklist and spec deltas (i.e., the “patch” to the specs). Some assistants surface OpenSpec’s steps as /openspec <verb> slash commands after running openspec init, because OpenSpec writes the instruction/config files they read at startup. But these commands are mere shortcuts: the “real” workflow lives in the repo as an openspec/ folder. With tools that don’t support custom slash commands, you run the same spec-first loop by posing requests in plain language and having the assistant create/review/apply/archive OpenSpec files.

spec-kit (GitHub Spec Kit)

GitHub’s open-source toolkit for “spec-driven development.” Pushes you to define requirements + outcomes first, then turns your spec into: plan → task list → code. Run the specify CLI (specify init, specify check) to scaffold or retrofit projects. Spec Kit drops a small set of files into your repo and configures your preferred agent so that when you type /speckit.<command>, the agent runs Spec Kit’s scripts and uses the generated artifacts. Supports a broad range of tools out of the box: Claude Code, OpenAI Codex CLI, Gemini CLI, Cursor, Copilot, Kilo Code, OpenCode, and Qwen Code.

GSD Core (Get Shit Done) is another active take on the problem. Its emphasis is less on writing the spec than on getting an agent through a long project without losing the plot: break the work into phases, give it fresh context, save the decisions and progress, and verify what comes back. The original GSD repo is archived, but development continues in Open GSD. This one isn’t a turnkey environment in the Flox repo yet; it belongs here as a point of comparison, not as a package I’m pretending you can activate.

>227,000 Other Packages, Millions of Historical Versions

The Flox Catalog contains just about every dependency you (or your AI agent minions) will need to build, test, and ship software. The Flox environments collected in this repo offer ready-to-run implementations showcasing some of these packages; however, what you see here isn’t close to exhausting the possibilities of what’s available. Here’s a sampling of the MCP packages available in the Flox Catalog:

• github-mcp-server. Exposes GitHub repo/issue/PR operations via the GitHub API.
• gitea-mcp-server. Exposes Gitea repo/issue/PR operations via the Gitea API.
• terraform-mcp-server. Lets agent inspect/plan/apply Terraform workflows.
• mcp-k8s-go. Go-based MCP tool server that exposes Kubernetes cluster operations (via kubectl-style reads/actions) as callable tools.
• aks-mcp-server. MCP server for Microsoft’s Azure Kubernetes Service (AKS); supports cluster/resource management + other operations; surfaced as MCP tools.
• playwright-mcp. Exposes Playwright browser automations (navigate/click/extract/screenshot) as MCP tools.
• mcp-grafana. Exposes Grafana entities (dashboards/panels/alerts/queries) as tools.
• mcp-proxy. Forwards/bridges MCP connections so clients can reach tool servers through a single hop.
• pythonXXXPackages.mcp (where XXX is the version). Python MCP library/SDK used to build MCP clients/servers and define tool schemas in Python. Packages available for Python versions 3.10-3.13.
• toolhive. Installs/runs/manages MCP servers as “tool bundles” so agents can consume them.

Search all 227,000+ packages on FloxHub

But Wait: There's More

How about another serving of turn-key environments to build with as you ramp up your vibecoding vacation? If you or your AI agent minion need a database, scheduler, workflow management engine, httpd/reverse proxy, or other tools, services, or runtimes, check out the following repos:

• flox/floxenvs. A collection of ready-to-run Flox environment examples (via flake.nix) for language toolchains like Go, Python (pip/poetry/uv), JavaScript (node/bun/deno), Ruby, and Rust, plus local service stacks like Postgres, Redis, MySQL, MongoDB, Cassandra, and Elasticsearch. This repo also includes environment templates for tools/apps such as nginx, mkcert, direnv/dotenv, 1Password, Dagger, Podman/Colima, LocalStack, JupyterLab, and Ollama.
• floxrox/floxenvs. Another collection of ready-to-run Flox environments, including: Airflow, AWS CLI, Colima, ComfyUI, Dagster, GitHub CLI, Jenkins, JupyterLab, Kafka (plus Karapace, a schema registry), kind, MariaDB/MySQL, n8n, Neo4j, nginx, Node-RED, Ollama (plus Open WebUI), Postgres (including a Metabase combo), Prefect, Redis, Spark, Temporal (plus a temporal-ui env), and multiple Python dev environments (3.10–3.13).

You and your AI assistants can combine these environments in two complementary ways:

• Composition. Compose multiple modular environments into a single, declarative “stack” that resolves and locks everything up front. Composition is great when you need reproducible, shareable setups;
• Layering. Layer environments one on top of another at runtime. Useful for adding tools/services when you need them in the moment: e.g., layering Python debugging tools on top of core Python dev tools.

In practice you’ll often use both: using composition to create rich “stack” environments; layering extras on top when you need them.

What else? How about Flox-and-AI guides to get you started?

• Reproducible Dev Environments in Any Repo with AI Agents and Flox: Part 1
• Reproducible Dev Environments in Any Repo with AI Agents and Flox: Part 2
• Next-Level Agentic Coding with Nix and Flox
• Reproducible Builds Made Simple with Nix and Flox
• Composable Dev Environments: Layering and Composition in Flox
• Production Model Serving Using NVIDIA Triton, vLLM, and llama.cpp with Flox