Autonomous development plugin for Claude Code. Define requirements with a PM, then let parallel workers implement everything using TDD.
- Overview
- Getting Started
- How It Works
- Reference
- Architecture
- Design Principles
- Development
- Changelog
- Contributing
- License
HCF separates planning (human-in-the-loop) from execution (fully autonomous):
Planning → Human + AI collaborate on requirements
Execution → Parallel TDD workers implement autonomously
Add the marketplace, install, then reload:
/plugin marketplace add markshust/hcf
/plugin install hcf@hcf
/reload-plugins/project-setupInteractively configures your project:
- Auto-detects tech stack (Laravel, React, etc.)
- Asks about testing, linting, architecture
- Creates
.claude/config directory
Just describe what you want:
"Help me implement user authentication with JWT"
The plan-create skill activates automatically to:
- Discover & brainstorm — explore the codebase and enumerate scope/assumption permutations a senior engineer would catch
- Create a
feature/{plan-name}branch for the work - Ask grounded clarifying questions categorized as must-answer vs will-default-if-silent
- Break down into tasks with dependencies
- Write requirements as test descriptions
- Create
.claude/plans/user-auth/with task files - Run post-plan pipeline agents (devil's advocate by default) to find gaps before execution
After planning completes, you'll be asked:
Ready to begin autonomous implementation?
- Yes, start now
- No, I'll run it later
If you chose "later" or want to re-run, say:
"Run the user-auth plan" or "Execute the plan"
The plan-orchestrate skill auto-triggers. It verifies you're on the correct feature/{plan-name} branch before starting, and automatically uses ralph-wiggum for session persistence if installed. If not installed, you'll see a warning but execution continues.
After completion, you'll be prompted to push the branch and create a PR (never done without your permission).
ralph-wiggum is prompted during /project-setup, or install manually:
/plugin marketplace add anthropics/claude-code
/plugin install ralph-wiggum@claude-code-plugins| Phase | Type | What Happens |
|---|---|---|
| Setup | One-time | Configure project for autonomous dev |
| Planning | Interactive | Discover codebase, brainstorm scope, then define tasks with human guidance |
| Post-Plan Hooks | Automated | Agents enrolled at the post-plan hook review the plan |
| Execution | Autonomous | Parallel TDD implementation, with agents enrolled at the implementation hooks |
The pipeline controls which agents run at fixed points in the plan/implementation flow. HCF uses convention over configuration: there is no central registry — each agent enrolls itself by declaring a phase in its own YAML frontmatter. If an agent declares a phase, it runs at that hook; if it has no phase, it never runs via a hook.
Hook points:
There are exactly 8 hook points where enrolled agents can run:
| Hook | Fires |
|---|---|
pre-plan |
Before planning Discovery begins |
post-plan |
After the plan is built and validated, before user review |
pre-implementation |
Before the first implementation batch |
pre-batch |
Before each batch of TDD workers is spawned |
post-batch |
After each batch of TDD workers completes |
post-implementation |
After all tasks complete |
pre-commit |
After the full test suite passes, before the commit |
post-commit |
After the commit, before the push/PR prompt |
By default, only devils-advocate is enrolled (at post-plan). See HOOKS.md for the authoritative reference — the full frontmatter schema, the deterministic discovery routine, and tie-break/ordering rules.
Enrollment frontmatter:
An agent enrolls by adding three keys to its frontmatter:
---
name: devils-advocate
description: "..."
model: opus
tools: Read, Write, Edit, Glob, Grep
# --- hook enrollment ---
phase: post-plan # one of the 8 hook points above
order: 10 # lower runs first within a hook; default 100
mode: single # "single" | "batch"; default "single"
---Customizing the pipeline:
Enable, add, remove, or reorder agents by editing frontmatter — never a central file.
-
Enable a built-in agent.
standards-enforcerships with its enrollment commented out. Uncomment itsphase(and optionalorder/mode) to turn it on:--- name: standards-enforcer description: "..." model: opus tools: Read, Edit, Glob, Grep # To enable code-standards enforcement after implementation, uncomment: phase: post-implementation order: 50 mode: batch ---
-
Add a custom gate. Drop an agent file into your project's
.claude/agents/directory with aphase, and it is enrolled automatically:--- name: doc-updater description: "Updates documentation when implementation changes." model: sonnet tools: Read, Edit, Glob, Grep phase: post-implementation order: 100 mode: single --- You are a documentation updater. Your job is to... {define the agent's behavior, process, and output format}
-
Disable an agent. Remove (or comment out) its
phasekey — there is no condition to toggle.
The agent's filename (without .md) should match its frontmatter name. Local agents in .claude/agents/ override plugin agents with the same name (the local file wins entirely).
Upgrading from
pipeline.md: Earlier versions of HCF configured the pipeline in a central.claude/pipeline.mdfile. That file is no longer read — agent frontmatter is now the only source of pipeline configuration. If a leftover.claude/pipeline.mdis present, HCF blocksplan-createandplan-orchestrate(you'll see a prompt on session start and when you try to plan) until you run/project-update, which migrates your configuration into agent frontmatter and removes the file./project-updateis never blocked, and the gate clears automatically once the file is gone.
After generating a plan, HCF visualizes the task dependency graph so you can verify parallelism and ordering before execution:
001 ─┬─► 002 ─┬─► 005
│ │
└─► 003 ─┘
│
└─► 004 ────► 006
This tells the orchestrator which tasks can run in parallel and which must wait. In this example:
- Batch 1: Task 001 (no dependencies)
- Batch 2: Tasks 002, 003, 004 (all depend only on 001)
- Batch 3: Tasks 005, 006 (005 depends on 002+003; 006 depends on 004)
Independent tasks within each batch run simultaneously:
Batch 1: Task 001 (no deps) → 1 worker
Batch 2: Tasks 002, 003, 004 → 3 parallel workers
Batch 3: Tasks 005, 006 → 2 parallel workers
100 tasks might complete in 5-10 batches instead of 100 sequential runs.
Each task follows strict Red → Green → Refactor:
- Write failing test for one requirement
- Write minimum code to pass
- Refactor while tests stay green
- Repeat for next requirement
- Commit when task complete
| File | Purpose |
|---|---|
testing.md |
Test commands, coverage requirements |
code-standards.md |
Linting, formatting rules |
architecture.md |
Directory structure, patterns |
| File | Purpose |
|---|---|
_plan.md |
Plan overview, task table |
001-{task}.md |
First task with requirements |
002-{task}.md |
Second task |
| ... | More tasks |
# Task 001: Create User Model
**Status**: pending
**Depends on**: none
**Retry count**: 0
## Description
Create the User model with authentication fields.
## Requirements (Test Descriptions)
- [ ] `it creates a user with valid email and password`
- [ ] `it hashes the password before storing`
- [ ] `it validates email uniqueness`Requirements become test names directly.
All skills can be invoked directly with /skill-name or triggered automatically by Claude when your request matches their description.
| Skill | Invocation | Auto-triggers | Description |
|---|---|---|---|
project-setup |
/project-setup |
No | Configure project (one-time) |
project-update |
/project-update |
No | Sync config with latest plugin defaults |
plan-create |
/plan-create [description] |
Yes — "Build a...", "Let's start building...", "I want an app that...", "Help me implement...", capability lists, etc. | Interactive planning with codebase discovery and grounded clarification |
plan-orchestrate |
/plan-orchestrate [plan-name] |
Yes — "Run the plan", "Execute", "Start implementation" | Parallel TDD execution |
| Output | Meaning |
|---|---|
ALL_TASKS_COMPLETE |
Plan finished successfully |
TASKS_BLOCKED: [003, 007] |
Some tasks failed after retries |
hcf/
├── .claude-plugin/
│ └── plugin.json # Plugin manifest
├── agents/
│ ├── devils-advocate.md # Plan reviewer - finds gaps before execution (opus)
│ ├── tdd-worker.md # TDD implementation worker (sonnet)
│ └── standards-enforcer.md # Code standards enforcement (sonnet)
├── skills/
│ ├── project-setup/
│ │ └── SKILL.md # One-time setup skill (manual invocation only)
│ ├── project-update/
│ │ └── SKILL.md # Sync project config with plugin updates (manual)
│ ├── plan-create/
│ │ └── SKILL.md # Interactive planning skill (auto-triggers)
│ └── plan-orchestrate/
│ └── SKILL.md # Parallel TDD execution skill (auto-triggers)
├── HOOKS.md # Authoritative hook/frontmatter reference
├── CLAUDE.md # Portable CLAUDE.md template for projects
└── README.md
- Pure TDD - No Gherkin/BDD, requirements map directly to test names
- Parallel by default - Auto-detect independent tasks, maximize concurrency
- 100% portable - CLAUDE.md identical across all projects
- Explicit dependencies - Tasks declare what they depend on
- Fail gracefully - Retry 3x, then block and continue with other tasks
- Claude Code CLI
- Git repository
- Test framework configured in project
Test the plugin locally without publishing using the --plugin-dir flag:
claude --plugin-dir /path/to/hcfSkills are namespaced with the plugin name:
/hcf:project-setup/hcf:plan-create [description]/hcf:plan-orchestrate [plan-name]
Skills with disable-model-invocation: true (like project-setup) require manual invocation. Others auto-trigger based on their descriptions.
-
Start Claude Code with the plugin:
cd ~/Sites/your-test-project claude --plugin-dir ~/Sites/hcf
-
Verify plugin loads:
/helpSkills should appear under the
hcfnamespace. -
Test each component:
# Test project setup (direct invocation only) /hcf:project-setup # Test plan-create (auto-triggers on feature requests, or invoke directly) "Create a plan to implement user authentication" /hcf:plan-create user authentication with JWT # Test plan-orchestrate (auto-triggers on execution requests, or invoke directly) "Run the user-auth plan" /hcf:plan-orchestrate user-auth
Run with debug output to see plugin loading details:
claude --plugin-dir ./hcf --debugTo load multiple plugins:
claude --plugin-dir ./hcf --plugin-dir ./other-pluginPlugin Structure Notes:
- Only
plugin.jsongoes in.claude-plugin/ - Skills, agents, and other components stay at the plugin root level
- Each skill is a directory with a
SKILL.mdentrypoint - Skills auto-trigger based on their
descriptionfrontmatter (unlessdisable-model-invocation: true)
See CHANGELOG.md for the full release history. New user-visible changes are added to the [Unreleased] section as they land and moved into a versioned section at release time.
- Fork the repository
- Create a feature branch
- Test locally with
--plugin-dir - Add an entry to the
[Unreleased]section ofCHANGELOG.mdif your change is user-visible - Submit a pull request
Created by Mark Shust
HCF is open-source software licensed under the MIT License.