Skill

create-harness

Create a reusable harness that defines how to process workflow tasks — step-by-step instructions, constraints, and behavior.

npx claudepluginhub samklevin/claude-skills --plugin checkpoint

Tool Access

This skill is limited to using the following tools:

ReadWriteEditGlobGrepBashAskUserQuestion

Preview

You are creating a reusable harness — a set of instructions that defines how to process tasks from any workflow. Harnesses are stored in `.claude/harnesses/` so they can be applied to different workflows.

Supporting Assets

templates/harness.yaml.tmpl

SKILL.md

Similar Skills

agent-introspection-debugging

169.4k

Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.

everything-claude-code

canary-watch

169.4k

Monitors deployed URLs for regressions in HTTP status, console errors, performance metrics, content, network, and APIs after deploys, merges, or upgrades.

everything-claude-code

frontend-patterns

169.4k

Provides React and Next.js patterns for component composition, compound components, state management, data fetching, performance optimization, forms, routing, and accessible UIs.

everything-claude-code

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitMar 29, 2026

Actions

View Source View Plugin View on GitHub View README

Create Harness

You are creating a reusable harness — a set of instructions that defines how to process tasks from any workflow. Harnesses are stored in .claude/harnesses/ so they can be applied to different workflows.

Step 1: Gather Configuration

If a harness name was provided as $ARGUMENTS, use it. Otherwise, ask.

Prompt the user for:

Harness name — short, slug-friendly (e.g., tdd, review-and-fix, research-only)
Description — one sentence describing what this harness does
Steps — walk the user through defining the harness behavior:
- What should happen for each task? (e.g., "write tests first, then implement, then verify")
- Are there constraints? (e.g., "never modify files outside src/", "always run tests after changes")
- Should it pause between tasks or continue automatically?
- Any special handling for blocked tasks?
- Any verification or quality gates before marking a task done?

Step 2: Write the Harness

Read the harness template from harness.yaml.tmpl.

Create .claude/harnesses/<harness-name>.yaml by populating the template:

{{HARNESS_NAME}} — the slug name
{{DESCRIPTION}} — the description sentence
{{CREATED_DATE}} — today's date in ISO format (e.g., 2026-03-29)

Populate steps, constraints, done_criteria, and pause_between_tasks based on the user's answers from Step 1.

Translate the user's description into concrete, actionable steps. Each step's instruction should be clear enough that Claude can follow it without ambiguity.

Step 3: Confirm

Tell the user:

The harness was created at .claude/harnesses/<name>.yaml
Summarize the steps and constraints
How to use it: /checkpoint:run-harness <harness-name> <workflow-name>
Remind them harnesses are reusable across any workflow

Rules

Create .claude/harnesses/ if it doesn't exist
If a harness with the same name exists, ask whether to overwrite or pick a new name
Steps should be specific and actionable — avoid vague instructions like "do the work"
Constraints should be enforceable — things Claude can actually check
Done criteria should be verifiable — things Claude can confirm before marking a task complete