# Harden Worker

> Run the background harden pass for one creation -- crystallize, update, or heal a skill, an app, a service, or the system interface in an isolated worktree, then report back. Invoke when your task file hands you a creation to harden; it names the operation and creation type to compose.

- Skill: `imbue-ai/harden-worker` (Agent Skill, multi-file: 14 files)
- Install (CLI): `npx skillmds@latest add imbue-ai/harden-worker`
- Raw SKILL.md: https://api.skillmd.com/api/skills/imbue-ai/harden-worker/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: imbue-ai (https://skillmd.com/u/imbue-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/imbue-ai/harden-worker

---


# Hardening a creation (generic worker)

You are the single worker that runs every background harden pass. Your task file
names one **operation** and one **creation type**, and your whole job is to load
the references they select and follow them. You own no operation- or
type-specific *behavior* yourself -- that all lives in the references; Step 2
just routes you to the right ones.

## Step 1: Read your task file and resolve inputs

Your task file was synced to your worktree under `data/.tasks/harden/<slug>/task.md`.
Extract the lead address and the report destination (plus the `operation` and
`type` fields the lead set in frontmatter):

```bash
eval "$(uv run .agents/shared/scripts/parse_task_frontmatter.py 'data/.tasks/harden/*/task.md')"
```

This sets `LEAD_AGENT`, `FINISH_REPORT_PATH`, `OPERATION`, and `TYPE`. Fail
loudly if `OPERATION` or `TYPE` is unset -- the lead must supply both.

- `OPERATION` is one of `crystallize`, `update`, `heal`.
- `TYPE` is one of `skill`, `app`, `service`, `system-interface`.

## Step 2: Load the references that define your run

Read these top to bottom, then follow them.

Filenames are relative to `.agents/shared/worker/references/`, except the two
marked **[shared]**, which live in `.agents/shared/references/`.

| Load when | Reference | What it gives you |
|---|---|---|
| every run | `harden-creation.md` | the universal contract: the bar, isolation, reporting, testing/hardening, review gates, preserve-and-surface, give-up |
| every run | `op-<OPERATION>.md` | your operation's spine: pre-work, stages, which gates fire and their `name:` values, gate report templates |
| every run | `type-<TYPE>.md` | the creation itself: where it lives, how to run/test it in isolation, how to edit it safely |
| every run | `worker-reporting.md` **[shared]** | the report-file procedure and task-file frontmatter schema (Step 3 uses it) |
| you reconstruct the work from the lead's session | `transcript-exploration.md` | how to find the work in the lead's transcript |
| `TYPE` is `skill` | `spec-summary.md` **[shared]** | the agentskills.io layout/spec authority |
| `TYPE` is `skill`, and your operation runs an outline gate | `skill-outline-fields.md` | what goes inside the outline gate |
| `TYPE` is `skill`, on an emergent `update` | `update-vs-create-new.md` | update-in-place vs. split-a-new-sibling |
| `TYPE` is `app` or `system-interface` | `web-frontend-testing.md` | isolated-instance and rendered-page rules |

The two conditional cases that need defining:

- **"you reconstruct the work from the lead's session"** -- a skill
  `crystallize`, an emergent `update`, or any `heal`: the work or incident you
  must reproduce lives only in the conversation. The other runs are handed a
  materialized source instead and skip `transcript-exploration.md` -- a committed
  `update` reads the diff, an app `crystallize` reads the pre-built app on
  disk, and a system-interface change reads its brief.
- **"runs an outline gate"** -- a skill `crystallize` or an emergent skill
  `update`. A committed `update` and any `heal` have no outline gate, so they
  never use `skill-outline-fields.md` or `update-vs-create-new.md` (loading them
  anyway is harmless).

The operation reference is the lifecycle spine -- it owns the stages, which gates
fire and in what order, and the report templates. The type reference is the
operation-agnostic description of the thing you are hardening. Where the
operation reference needs a type-specific value (a gate template's field list,
the crystallize shape), it carries that itself, keyed by type.

## Step 3: Report back to the lead

Follow `.agents/shared/references/worker-reporting.md` for the report-file
procedure. The `eval` in Step 1 already set the variables it needs. Substitute:

- `<TASK_FILE_GLOB>` -> `data/.tasks/harden/*/task.md`
- `<RUNTIME_REPORTS_DIR>` -> the directory part of `FINISH_REPORT_PATH`
  (i.e. `dirname "$FINISH_REPORT_PATH"`).

The valid `name:` values for gates and terminal statuses come from your
operation reference -- it is the authority on which gates fire for your
operation × type combination (e.g. a crystallized app emits no gates; a
crystallized skill emits `outline-approval` then `final-creation`).

That is the entire worker. Everything else is in the references you loaded in
Step 2.