The Guides-and-Sensors cross-classification

The harness has many elements, and lining them all up makes them hard to grasp. So if we classify them into four groups along two axes, the role and weakness of each becomes clear. The framework in this chapter serves as the yardstick for judging "which kind just fired" in the chapters that follow.

The two axes

The first axis is timing.

• Guide — directs before the action (feedforward). It steers in advance: "proceed this way."
• Sensor — detects after the action (feedback). It makes you notice and correct after the fact: "that one was wrong."

The second axis is mechanism.

• Computational (deterministic) — runs reliably via scripts or settings. If a condition is met, it always fires.
• Inferential — relies on the LLM's reading comprehension. It often works, but probabilistically misses.

Crossing these two axes produces four cells.

The four-way matrix

Let us map this environment's real examples onto each.

Category	When and how it works	Example in ~/.claude
Computational Guide (deterministic, before the action)	Physically stops dangerous operations	check-protected-files.sh (🔧; blocks writes to .env in advance), the permission settings in settings.json (🔧 config values on a 📦 mechanism), type-checking and lint settings
Inferential Guide (inferential, before the action)	States the policy in prose and makes the model follow it	CLAUDE.md, rules/*.md, skills/*/SKILL.md (all 🔧)
Computational Sensor (deterministic, after the action)	Mechanically inspects the output and sends it back	Stop hooks (check-plain-question.sh and others, 🔧), check-suppression.sh (🔧), CI
Inferential Sensor (inferential, after the action)	The LLM re-reads and evaluates the output	the /review skill, the code-reviewer subagent (both 🔧)

Why one side alone is not enough

What governs the harness's reliability comes down to this one point: because inferential things miss probabilistically, relying on them alone keeps you stuck in a state of "mostly follows, but occasionally breaks the rule."

Let us see it with a concrete example. This environment has a standard: "questions to the user are structured with a dedicated tool, not written in plain prose." This is written as an Inferential Guide called rules/ask-user-question.md.

With only an Inferential Guide

rules/ask-user-question.md (a guide before the action)
  → Instructs: "don't ask in plain prose, use the dedicated tool"
  → Usually followed. But on occasion, you write "what should we do?" in plain prose
  → A guide steers before the action, so once it is written, it cannot notice

So we back the same standard with a Computational Sensor as well. This Sensor, too, was born not from desk-bound design but from an actual failure: the recurrence of plain-prose questions.

With a Sensor paired to it

check-plain-question.sh (a Stop hook = a sensor after the action)
  → Mechanically greps the entire body of the finalized response to detect plain-prose question patterns
  → If found, sends it back with exit 2 and makes it re-ask with the dedicated tool
  → Deterministically catches "the one time it slipped through probabilistically"

The guide is "steering in advance," and the sensor is "catching what was missed." This Guide-and-Sensor pair is the crux of turning a probabilistic model into a reliable agent. In a later chapter, we look at this pair again in detail with the /grill-me example.

Writing it in the rules does not mean it is followed

Writing a standard in rules/ places only one Inferential Guide. The more you genuinely want a standard followed, the more you prepare a pair with a Computational Sensor (a hook) that catches what is missed. Not thinking "written = followed" is the design stance of this harness.

How to use this yardstick

When following the flow of /debug, being aware of "which of the four categories is this" for each element that fires makes the roles come into three-dimensional view.

• An MCP load instruction or a rule load is → an Inferential Guide
• The .env block is → a Computational Guide, and suppression-comment detection is → a Computational Sensor
• The self-correction at the end of the response is → a Computational Sensor
• The after-the-fact review by /review is → an Inferential Sensor

Summary of this chapter

The key points are as follows.

• The harness's elements can be classified four ways by "before/after the action" × "deterministic/inferential"
• Inferential ones (rules / skills) miss probabilistically, so they are insufficient on their own
• The more important a standard, the more you pair a Guide with a Sensor to deterministically catch what is missed

---

Next, in A map of ~/.claude's components, we list what is actually placed in this environment.