# How design-control-loop Decides to Fuse Sensor/Controller or Controller/Actuator Steps

> Learn how design-control-loop fuses sensor/controller or controller/actuator steps when tools combine roles, or keeps them discrete otherwise. Understand the logic behind step consolidation.

- Repository: [HumanLayer/skills](https://github.com/humanlayer/skills)
- Tags: internals
- Published: 2026-09-13

---

**The design-control-loop skill fuses sensor/controller or controller/actuator steps when existing tooling already combines these roles—such as when a tool both measures repository state and prioritizes findings (sensor+controller) or when a prompt both selects and applies changes (controller+actuator)—otherwise it keeps the steps discrete as separate sensor → controller → actuator operations.**

The **design-control-loop** skill in the `humanlayer/skills` repository guides users through architecting automation workflows that follow control-system patterns. When building a loop with set-point, sensor, controller, and actuator components, the skill must determine whether to collapse adjacent steps into fused operations or maintain them as discrete stages. This decision hinges on a bottom-up discovery process that examines existing repository tooling against the definitions in [`control-loop-taxonomy.md`](https://github.com/humanlayer/skills/blob/main/control-loop-taxonomy.md).

## The Control Loop Taxonomy Framework

The skill references a strict taxonomy defined in [`plugins/design-control-loop/skills/design-control-loop/references/control-loop-taxonomy.md`](https://github.com/humanlayer/skills/blob/main/plugins/design-control-loop/skills/design-control-loop/references/control-loop-taxonomy.md) to classify components. This taxonomy establishes four distinct roles:

- **Set-point**: The target state or specification
- **Sensor**: Measures the current repository state and reports findings
- **Controller**: Ranks or prioritizes findings against the set-point to select targets
- **Actuator**: Applies changes to move the system toward the target

The skill maps existing scripts, linters, and agents onto these roles during an initial interview phase. When a single tool spans multiple roles, the skill triggers fusion logic to avoid unnecessary workflow fragmentation. The taxonomy explicitly marks these fusion points: "Sensor + controller fused" appears at lines 25-26, while "Controller + actuator fused" appears at lines 26-27 of the taxonomy file.

## Fusion Detection Logic

During the repository analysis phase, the skill checks for two specific fusion scenarios by inspecting tool capabilities and prompt behaviors.

### Sensor + Controller Fusion

When a tool both **measures** the repository state **and** ranks or prioritizes the findings, the skill classifies this as a combined sensor and controller. The canonical example is `react-doctor`, which returns the "top-3 rules" directly—performing both the detection (sensor) and the prioritization (controller) in a single invocation.

As documented in [`example-control-loop.md`](https://github.com/humanlayer/skills/blob/main/example-control-loop.md) at lines 21-24, this fusion eliminates the need for a separate controller step. The workflow instead passes the tool's prioritized output directly to the actuator, embedding the selection logic within the actuator's prompt.

### Controller + Actuator Fusion

When a single agent prompt both **selects the next target** and **applies the change**, the skill recognizes a controller/actuator fusion. This occurs when the decision logic and the mutation capability reside within the same agent invocation. The taxonomy marks this as "Controller + actuator fused" and instructs the workflow to collapse these into a single agent step.

## Discrete Steps vs. Fused Operations

If the repository lacks tooling that merges roles, the skill mandates discrete separation. According to [`SKILL.md`](https://github.com/humanlayer/skills/blob/main/SKILL.md) at lines 115-116, the guidance states to "run the loop as discrete steps: sensor → controller → actuator" unless existing infrastructure demonstrates fusion.

**Discrete architecture** maintains strict boundaries:
1. Sensor runs independently and outputs raw findings
2. Controller receives sensor output and selects targets via deterministic script or agent
3. Actuator receives specific targets and applies changes

**Fused architecture** optimizes for fewer handoffs:
- **Two-step**: Fused sensor/controller → discrete actuator
- **One-step**: Fused controller/actuator (single agent decides and mutates)

## Implementation Examples

The following patterns illustrate how the skill maps these decisions to concrete code implementations.

### Fused Sensor/Controller Example

When using `react-doctor`, the sensor and controller roles fuse because the tool returns a prioritized list. The actuator prompt absorbs the selection policy:

```typescript
// Sensor (react-doctor) command - fuses measurement and prioritization
await $`bunx react-doctor --project '@codelayer/riptide-ui' --diff false --yes`;

// The actuator's prompt contains the policy that selects up to 5 issues
// from the top-3 rules reported by the already-prioritized sensor output
const prompt = `
You are a CodeLayer agent. Fix up to 5 issues from the top 3 rules:
${sensorOutput}
`;

```

This implementation, referenced in [`example-control-loop.md`](https://github.com/humanlayer/skills/blob/main/example-control-loop.md), demonstrates how the controller logic disappears as a separate step when the sensor tool already ranks results.

### Discrete Three-Step Implementation

When no existing tool combines roles, the skill generates explicit separation between components:

```typescript
// 1️⃣ Sensor – run a lint script (measurement only)
const lintResults = await $`bun run lint`;

// 2️⃣ Controller – deterministic script that picks the highest-severity finding
const target = pickHighestSeverity(lintResults);

// 3️⃣ Actuator – CodeLayer agent applies the fix to the selected target
await runAgent({
  skill: "my-fix-skill",
  input: target,
});

```

This discrete approach, recommended in [`SKILL.md`](https://github.com/humanlayer/skills/blob/main/SKILL.md), ensures each component has a single responsibility and allows for human review between stages.

## Summary

- The **design-control-loop** skill uses [`control-loop-taxonomy.md`](https://github.com/humanlayer/skills/blob/main/control-loop-taxonomy.md) to classify repository tooling into sensor, controller, and actuator roles.
- **Sensor + Controller fusion** occurs when a tool both measures state and prioritizes findings, such as `react-doctor` returning top-3 rules.
- **Controller + Actuator fusion** occurs when an agent prompt both selects targets and applies changes.
- When no fusion exists, the skill mandates **discrete steps**: sensor → controller → actuator.
- The decision is made through a **bottom-up discovery process** during the initial repository interview, examining existing scripts to avoid unnecessary workflow complexity.

## Frequently Asked Questions

### How does the skill detect if my existing linter can act as a fused sensor and controller?

The skill examines whether your tool both reports repository state and performs ranking or prioritization of those findings. According to the taxonomy in [`control-loop-taxonomy.md`](https://github.com/humanlayer/skills/blob/main/control-loop-taxonomy.md), if a tool like `react-doctor` returns a pre-sorted list of the "top-3 rules," it qualifies as a fused sensor/controller because it performs both measurement and selection in a single execution.

### Can I force discrete steps even if my tooling supports fusion?

Yes. While the skill identifies opportunities for fusion by inspecting existing tooling, the final workflow design remains configurable. The [`SKILL.md`](https://github.com/humanlayer/skills/blob/main/SKILL.md) guidance prioritizes fusion for simplicity, but you can explicitly define separate sensor, controller, and actuator scripts if your use case requires human review or custom logic between stages that the existing fused tool cannot support.

### What happens when a prompt selects targets but delegates to another tool for changes?

This scenario represents a **controller + actuator fusion** where the agent prompt making the decision is also responsible for invoking the change mechanism. The taxonomy at lines 26-27 of [`control-loop-taxonomy.md`](https://github.com/humanlayer/skills/blob/main/control-loop-taxonomy.md) classifies this as fused because the selection logic (controller) and the mutation trigger (actuator) occur within the same operational boundary, even if the actual file modification is delegated to a subprocess.