27 docs tagged with "harness"

A list of where Claude Code's harness components — CLAUDE.md, rules, skills, agents, hooks, MCP, and memory — are placed and when they work.

How this harness ports the philosophy of nrslib/takt — an AI Agent Orchestration Framework — including Faceted Prompting, Output Contracts, Worktree Isolation, and the 8 design principles, onto Claude Code's skills + agents + handoff dir without using the takt CLI itself.

An explanation of the core idea that an AI agent's reliability is determined by the design quality of the "harness" surrounding it, not by the model itself.

The post-rebuild directory layout under ~/.claude/, and the criticality-driven 3-tier delivery rule that splits how each facet reaches the agent, explained with real examples.

A dictionary-style walkthrough of the responsibilities and boundaries of every rules / skills / agents / hooks / output-contracts / knowledge facet file, with real-code excerpts.

An explanation of Faceted Prompting — an organizing axis that splits prompts into Persona / Policy / Instruction / Knowledge / Output Contract — covering each facet's responsibility and the routing rules between them.

We follow the first few hundred milliseconds, from a one-line bug report passing through the UserPromptSubmit hook, launching the /debug skill, to SKILL.md becoming the work procedure.

The five disciplines (usage-driven addition / size cap / one-file-one-concern / reverse ratchet / hooks-after-evidence) that structurally prevent harness re-bloat, and the inverted-approval workflow that makes deletion the default.

Hooks are scripts registered against events in settings.json. We organize the 8 events used in this environment and the self-correction feedback mechanism via exit 2.

Rules come in two kinds—always-loaded and path-scoped. We dig into the mechanism where the frontmatter paths (glob) means "load only when you open a matching file."

A guide that follows a single run of the debug command /debug to learn how Claude Code's skills, rules, memory, hooks, and MCP work together. Understand the harness engineering workflow through a concrete, worked example.

So you never step into the same hole twice, we look at the Ratchet flow that promotes learnings to rules / hooks / fitness functions, starting from the recurrence-prevention judgment in /debug.

Post-bootstrap iterations (silent drop / doubled worktrees / wording drift, and more) walked through as problem → analysis → fix → verification.

The top page of a series that walks chapter by chapter through a Claude Code harness running at dozens-of-files scale, with nrslib/takt-derived Faceted Prompting (5 concerns) and orchestrator (takt-inspired) at its core.

Reading a file auto-loads path-scoped rules, and the moment you rewrite it, PreToolUse / PostToolUse hooks step in. We look at the mechanisms that structurally block "the easy fix."

The first move of /debug is loading MCP. We explain why MCP is not available from the start and is loaded each time with ToolSearch, and why sequential-thinking is mandatory.

We look at Generator-Evaluator separation—keeping the one who implements separate from the one who evaluates—and at multi-perspective-review, which runs multiple subagents in parallel, via a detour into /review.

We look back at the overall picture of the harness, followed through one run of /debug, and show the first step to starting your own harness small and growing it.

The final chapter of the series, organizing a 3-tier summary, the state of the 4 Quality metrics, and the road ahead.

Protect a standard with a pair of "a Guide that steers in prose" and "a Sensor that mechanically catches what is missed." We look at the sharpest example of the cross-classification, using the requirements-grilling skill /grill-me.

Classify the harness's components along two axes, "before/after the action" × "deterministic/inferential," and show with concrete examples why either one alone is insufficient.

The moment /debug returns its answer, seven hooks run in parallel on the Stop event. We explain the difference between Sensors that block immediately and log-only Sensors that just observe first.

A session forgets when it ends. With three layers—learnings, project memory, and handoff—we organize what to keep, where, and at what granularity.

MCP is controlled in two stages, "loading the schema" and "connecting to the server." We organize the loading of deferred tools via ToolSearch and the autonomous loading based on a usage table.

Iterate Investigate→Fix→Verify up to 3 times, and back "it is fixed" with the evidence of test output. You experience the harness's core principle, "show evidence, do not assert success," through /debug.

A walkthrough of each phase (⓪'-⑤) of the autodev flow using autodev-smoke's anagram-check task, with real spec / plan / story / done / review excerpts.

A walkthrough of the four symptoms observed in the pre-rebuild Claude Code harness and the decision to rebuild from zero, along with the four design decisions that shaped the new setup.