Claude Code, with a guard that fails closed and a process that learns
A guard hook checks tool calls before they run: it blocks pushes to your environment branches, secret files and changes that would switch it off, asks before deploys, publishes and merges, and blocks the call when it can't run its check. Your session does everyday changes alone; a change to a risk path gets a plan you approve, a build agent and QA. Retros turn misses into rules, and prunes propose cutting the ones that never fire.
Open source, MITAny language or frameworkGrew out of about 150 features on a real product
Test results are public, with the known limits listed.
- Guard
- Plan
- Build
- Check
- Retro
- Prune
The guard comes first
scripts/guard.sh runs as a Claude Code PreToolUse hook. It reads a Bash command the way the shell does (each command in a chain, inside $(…), bash -c, eval, after sudo and other wrappers), then lets the call through, asks you, or blocks it and tells the agent why. A block has no switch.
Blocks
Pushes to your environment branches and force-pushes. Reading or writing secret and credential files (.env*, keys, cloud and SSH credentials), also through a symlink. Printing the whole environment. Changes that would switch the guard off. gh secret writes. Remote database writes from the migrate and push commands it knows.
Asks you
Deploys and cloud CLIs that do more than read, publishes, merges and other code-host writes, edits to its settings, CI files and git hooks, git config keys that run commands, git reset --hard, moving an environment branch in your clone and wide deletes, database clients aimed at a remote host unless they only read, code fetched and run (curl … | sh), package runners on packages you don't have, and any MCP tool whose name isn't a read (by default the GitHub pull request tools may work on your own repository's PRs).
Fails closed
It blocks the call when it can't run its check: the script missing, no python3 or awk, input it can't parse, a crash, or a check that runs past 15 seconds. An owner can opt out with guard.fail_open for a missing python3.
Sees, and doesn't
It checks Bash, file tools, Grep, WebFetch and MCP calls; other tools get Claude Code's own prompts. It is not a sandbox: shell expansions it doesn't perform, commands inside an existing script, secrets in unusually named files and plain downloads get past it, and a hook that hangs past its 60 second timeout lets the call run. Branch protection on the host stays the real guard. Full list.
Same model, with a guard and a paper trail
Morphness doesn't change the model. It adds a guard and a process around it: a plan you approve, a record of every check, and a loop that keeps your CLAUDE.md rules short and true, packaged so you don't write it by hand. It spends the process where the risk is.
One agent by default
A script, risk-check.sh, reads the files a change touches. Off the risk paths your own session plans, builds and checks it alone. Sign-in, money, the database schema, deleted data or a change to many files brings in a Full-stack agent and a QA agent; a new migration that only adds stays in your session, with database tests and a code review.
Plan first, then build
A change that alters behaviour gets a plan with testable acceptance criteria that you approve before code is written: short off the risk paths, full on them. A bug fix starts from a failing test; a docs change needs no plan.
Done means verified
Every change records the checks it ran with their exit codes, and a planned change the evidence for each criterion. A separate QA agent checks full and bug mode work; light, small and research mode have none.
Learns from its mistakes
Retros turn real misses into rules. Every ten learnings files (8 to 30, your choice), a prune audits them and proposes cutting the ones that never fired; you decide each one, and nothing is cut on its own.
Works on any codebase
New or existing repos, monorepos with several apps, and folders that aren't a git repo or online yet. Any language or framework. It keeps your CLAUDE.md, shows a diff for settings and lands everything on a branch you review.
Honest about cost
Process costs tokens. Small mode costs more than the same change in a plain session, and a full-mode feature costs several times as much, which is why only risky changes get the agents. Every hand-off shows its estimated dollar cost.
Yours to configure
Branches, environments, checks, modules, risk areas, models and effort live in one harness.config.yml. Every rule and checklist is a Markdown file in your repo.
What happens on each change
You talk to the Technical Lead in the main chat. It names the files a change will touch and runs risk-check.sh, which picks the mode. Your wording never changes it; you can force a mode yourself.
| Mode | When | Who works | Plan | QA agent |
|---|---|---|---|---|
| Light | Off the risk paths, nothing changes at run time | Your session | None | No |
| Small | Off the risk paths, behaviour changes (or a migration that only adds) | Your session | Short, you approve | No |
| Small bug fix | Off the risk paths, something broke | Your session | Failing test first | No |
| Full | A risk path, deleted data, or many files | Full-stack and QA | Full, you approve | Yes |
| Bug | Something broke on a risk path, or a hotfix | QA writes the test, Full-stack fixes | Bug plan, you approve | Yes |
| Research | A question, no change | A read-only researcher | None | No |
- PlanAcceptance criteria you approve, short or full.
- BuildYour session, or Full-stack on a risk path, on a draft PR.
- CheckEvery check with its exit code; QA verifies each criterion on a risk path.
- RetroOnly the action items its misses call for, plus the cost.
- PruneEvery ten learnings files: proposed cuts you decide.
- ShareRules that fired can become community lessons.
Technical Lead
Your session. Makes plain changes itself; plans risk-path work, gets your approval and delegates it.
Full-stack
In full and bug mode, builds the approved plan and its tests. Extra-high effort for sign-in, secrets and money.
QA
In full and bug mode, reviews the diff, runs the checks and validates every acceptance criterion, with the evidence recorded.
Researcher
Answers a question about your code or the web with cited sources, when you want an answer and not a change.
Code scout
In full mode, maps the code a change touches before the plan, so your session and the later agents read only the lines it changes.
Feature closer
After a QA pass, drafts the closing records and the cost line; your session checks them and decides the retro items.
Legal writer
Writes wording that makes a legal promise, when a feature needs it.
/morph-init installs and sets up the harness./morph-update reviews what changed upstream and brings in what you accept, merged with your edits./morph-doctor checks the wiring, flags a due prune and counts upstream updates waiting./morph-module adds or removes an optional module on an installed project./morph-share turns rules that fired into a PR to the lessons catalog.Install
The setup scans your repo, then asks a short series of questions in plain words, each with a suggested answer. It suggests skills, connectors and lessons that fit your stack, and installs only the ones you accept. No git repo yet? It starts one, and can create the GitHub repository and its branch protection on your yes.
Ask your agent
Paste this in any Claude Code session inside your repo, new or existing:
Set up the Morphness agent harness in this repo by following https://github.com/antarsoft/morphness/blob/main/INSTALL.md step by step. Scan the repo first, then ask me the setup questions one at a time with your suggested answer. Keep my existing files, install skills or connectors only after I say yes, and put every change on a new branch for me to review. If Morphness is already installed here, follow its UPDATE.md instead and show me what changed upstream.
Or as a plugin
Add the marketplace, install, then run the setup:
/plugin marketplace add antarsoft/morphness /plugin install morphness@morphness /morph-init
Prefer to copy files yourself? scripts/install.sh copies and never overwrites. Needs: Claude Code with plugins, subagents and effort levels; sonnet (opus optional, fable for the legal writer); bash, git, python3 3.7 or later, awk and perl (gh helps, with a fallback). Without python3 the guard blocks every call it checks. Every hand-off shows its estimated dollar cost.
Your first feature
- Ask for the change. The Technical Lead runs the risk check on the files it will touch.
- Off the risk paths, your session works alone: a short plan you approve when behaviour changes, then the change, its tests and every check.
- On a risk path, you approve a full plan; Full-stack builds it on a draft PR, the Technical Lead reviews the code, QA checks every criterion and the PR is marked ready.
- You merge, and get the cost, a retro on risky work, and a steps file for anything only you can do. When a connected service can do a step, the Technical Lead offers to, and acts only after your yes.
For something broken, a failing test comes before anyone touches the fix. When you want an answer rather than a change, ask a question and the Technical Lead uses research mode.
What lands in your repo
AGENTS.md,CLAUDE.md,.claude/rules/- A short core every session loads, and rules that load only when a task touches their files.
.claude/agents/- Full-stack, QA, researcher, code-scout, feature-closer and legal-writer subagents at several effort levels.
.claude/settings.json- The guard hook and the end-of-task checks, plus deny rules for secrets and protected-branch pushes and ask rules on merge commands.
harness/- The process: lifecycle, handoffs, checks, modes (full, small, light, bug, research), the guard's full list, release and environments, the plan checklist, model prices, and how it morphs. Optional modules for Claude Projects, data access, browser e2e, legal wording, a roadmap, CI/CD pipelines and security.
project/- Your project's facts: stack, the commands behind each check and their scope, risk areas, effort per area, and the official connector for each service you use.
harness.config.yml- Branches, environments, apps, branch protection, who merges, release tags, modules, named checks, CI gate, risk areas, mode, models and effort, cost tracking, the guard's switches, loop limits.
scripts/and.github/- The guard, the risk check, the end-of-task checks, the prune counter and the feature cost estimate; a PR template and the branch-protection ruleset.
_harness/- Runtime: feature folders, learnings, research, prunes, releases.
From the community, for the community.
Rules that prove themselves can help the next team
When a prune shows a rule caught a real problem, /morph-share strips anything project-specific and drafts a PR to the shared catalog. A maintainer checks it is new, portable and backed by evidence. /morph-update then offers it to every project it matches.
fired count yet: from the first project's records, which didn't count firesThe catalog starts with lessons from the product Morphness was built and run on for about 150 features, and yours could be the next project in it. Lessons are amended, never replaced: your report strengthens an existing lesson when one matches.