claude-hammer

claude-hammer

A Claude Code plugin — the Claude Code build of glm-hammer, a forge-and-hammer engineering harness:

• forge — recon-first strong planning, verified by a 3-critic panel (feasibility, integration, coverage).
• hammer — a worker → validator → critic implementation loop, gated by security/QA review before completion.
• crucible — optional storyline-driven design tokens (W3C format), verified by a two-designer panel.

Hooks enforce the gates so the agent cannot skip verification — plan approval, token budgets, comment quality, and a final stop-gate all run automatically.

Requirements

• Claude Code with plugin support (/plugin).
• node on your PATH (the hooks are Node scripts).

Everything the plugin needs — skills, agents, and hook scripts — is vendored into this repo as plain files. There is no git submodule to initialize and no build step, so a plain /plugin install works on macOS, Linux, and Windows alike.

Install

From the marketplace (recommended)

In Claude Code:

/plugin marketplace add tmdgusya/claude-hammer
/plugin install claude-hammer@claude-hammer

The first argument is the marketplace, the second (@claude-hammer) is the plugin inside it — they share a name here. Restart or reload Claude Code when prompted so the hooks, skills, and agents register.

From a local checkout (development)

git clone https://github.com/tmdgusya/claude-hammer ~/claude-hammer

Then in Claude Code:

/plugin marketplace add ~/claude-hammer
/plugin install claude-hammer@claude-hammer

What you get

Once installed, the plugin adds:

• Skills — forge, hammer, crucible, and blueprint (lightweight planning for small, ≤3-file tasks).
• Agents — the review panels: feasibility-critic, integration-critic, coverage-critic (forge), implementation-critic (hammer), and security-reviewer / qa-reviewer (final gates).
• Hooks (hooks/hooks.json) — run on SessionStart, UserPromptSubmit, PostToolUse (Write/Edit + Agent/Task), and Stop to route intent and enforce the gates.

Usage

You don't invoke phases by name — just describe your intent, and a routing hook picks the right phase:

• "Properly build feature X" (a real, multi-file task) → forge runs recon, asks a few questions, drafts a plan, and gets unanimous critic + your approval before any code is written. Then hammer implements task-by-task with validator/critic loops and a final security/QA gate.
• "Build this with <mood/storyline>" (a design request) → crucible first turns the storyline into reviewed design tokens, then hands off to forge/hammer.
• Small, clear change → blueprint does lightweight planning with a self-review.

Throughout, you're only asked to engage twice: answering the recon questions and approving the plan. The hooks handle the rest of the verification automatically.

How it relates to glm-hammer

glm-hammer is ZCode-native. claude-hammer reuses its skills, agents, and hook scripts unchanged in content, vendored into this repo as plain files (skills/, agents/, hooks/scripts/). Only the hook-runtime wiring differs between ZCode and Claude Code:

• hooks/hooks.json is Claude Code-native (type: command, timeout in seconds).
• Hook commands run the scripts with GLM_HAMMER_EMIT=claude, which switches glm-hammer's emitContext to Claude Code's hookSpecificOutput schema.
• skills/ and agents/ are pure markdown, copied verbatim (no conversion).

The files are vendored rather than pulled via a git submodule because Claude Code plugin installs don't fetch submodules and plugin discovery doesn't follow symlinks — vendoring is what makes a one-command /plugin install work everywhere.

To pull newer glm-hammer changes into these copies:

node scripts/sync-from-glm-hammer.js [ref]   # ref defaults to the default branch

Then review git diff, run the smoke test, and commit.

Development

Run the zero-dependency smoke test (validates hooks.json shape, that every referenced script exists, and that skills//agents/ are vendored as real files):

node tests/smoke.test.js

License

MIT