# How the Reframe Pass in ADHD Strips Incidental Anchors from Problem Statements

> Learn how the ADHD reframe pass removes incidental anchors from problem statements, ensuring unbiased brainstorming for better solutions. Discover the process and its benefits.

- Repository: [Udit Akhouri/adhd](https://github.com/UditAkhourii/adhd)
- Tags: deep-dive
- Published: 2026-07-30

---

**The reframe pass in ADHD uses a specialized system prompt and LLM call to identify and remove implementation-specific details—called incidental anchors—from problem statements before the divergence phase, ensuring unbiased solution brainstorming.**

The ADHD engine executes a mandatory Phase 0 operation immediately upon starting a run. This preprocessing step, known as the *reframe pass*, analyzes the input problem statement to strip away transient constraints like current tech stacks or existing tool names, allowing subsequent divergence phases to explore solutions free from accidental implementation bias.

## What Are Incidental Anchors?

**Incidental anchors** are details embedded in problem statements that reflect current implementation choices rather than genuine constraints. These include specific programming languages, existing database choices, or framework dependencies—essentially "how it happens to be built today." In contrast, **load-bearing anchors** represent immutable constraints such as compliance requirements, budget limits, or physical laws that must remain part of the problem definition. The reframe pass distinguishes between these categories to prevent solution space contamination.

## How the Reframe Pass Works

The reframe pass operates as Phase 0 of the ADHD engine pipeline, executing before any divergent brainstorming begins. According to the source code in `UditAkhourii/adhd`, the implementation follows a strict four-step workflow:

### System Prompt Definition

The engine constructs a precise instruction set in the `REFRAME_SYSTEM` constant located in **src/engine.ts** (lines 96‑113). This prompt explicitly defines the stripping rules:

- Keep genuine immutable constraints (compliance, budget, physical limits)
- Strip anchors that are just implementation artifacts of the current build
- Return the problem unchanged if nothing needs stripping, setting `changed` to `false`

This system prompt ensures the LLM understands the semantic difference between essential constraints and accidental complexity.

### LLM Call and Schema Validation

The `reframeProblem` function (lines 123‑142 in **src/engine.ts**) sends the original problem statement to the LLM along with the `REFRAME_SYSTEM` context. The function expects a strictly typed JSON response matching the `ReframeSchema` interface, which includes three fields:

- `reframed`: The cleaned problem statement (if anchors were found)
- `changed`: Boolean indicating whether any modifications occurred
- `note`: Optional explanation of what was stripped

This structured response ensures deterministic downstream processing.

### Conditional Application in the Run Loop

Within the `run` function (lines 31‑48 in **src/engine.ts**), the engine checks the `stripAnchors` option from `RunOptions` (defined in **src/types.ts**), which defaults to `true`. When enabled:

1. The engine invokes `reframeProblem` with the original text
2. If `changed` is `true` and the returned string is non-empty, the problem passed to `divergeProblem` is replaced with the reframed version
3. The original reframed text is preserved in the final `RunResult.reframe` field for audit purposes

If `stripAnchors` is set to `false`, the divergence phase receives the exact input text, preserving all incidental anchors.

### Event Emission and CLI Feedback

Upon completion, the engine emits a `reframe:done` event (lines 46‑47) containing the `changed` status. The CLI renderer in **src/render.ts** (lines 26‑30) listens for this event and prints a dimmed status line when reframing occurs, providing visibility into whether the problem statement was modified before brainstorming.

## Configuration and Type Definitions

The behavior is controlled through the `RunOptions` interface in **src/types.ts**, which includes:

- `stripAnchors`: Boolean flag defaulting to `true`
- Problem context and metadata

The `RunResult` type captures the reframe output in the `reframe` field, allowing post-run analysis of what specific implementation details were removed during Phase 0.

## Practical Implementation Examples

**Example 1: Default behavior (anchors stripped automatically)**

```typescript
import { run } from "./engine.js";

await run({
  problem: "Build a feature flag system using our existing Redis cache and Node.js backend.",
  // stripAnchors defaults to true
});

```

*The LLM rewrites the problem to remove implementation specifics, producing something like: "Build a feature-flag system that can be toggled at runtime, without assumptions about underlying storage or language."*

**Example 2: Disabling the reframe pass**

```typescript
await run({
  problem: "Build a feature flag system using our existing Redis cache and Node.js backend.",
  stripAnchors: false,  // Preserves original constraints
});

```

*The divergence phase receives the exact original text, maintaining Redis and Node.js as fixed constraints in the solution space.*

## Summary

- The **reframe pass** operates as Phase 0 in the ADHD engine, running before divergent brainstorming begins.
- It leverages the `REFRAME_SYSTEM` prompt in **src/engine.ts** to instruct the LLM on distinguishing incidental anchors from load-bearing constraints.
- The `reframeProblem` function handles LLM communication and schema validation, returning structured data via `ReframeSchema`.
- Configuration via `stripAnchors` (default `true` in **src/types.ts**) allows optional preservation of implementation details.
- Event emission (`reframe:done`) and rendering logic provide transparency when problem statements are modified.

## Frequently Asked Questions

### What is the default behavior of the reframe pass in ADHD?

By default, the reframe pass is enabled via `stripAnchors: true` in the `RunOptions` configuration. The engine automatically processes every problem statement through the LLM to remove incidental anchors before entering the divergence phase, unless explicitly disabled.

### How does ADHD distinguish between incidental anchors and genuine constraints?

The distinction is made through the `REFRAME_SYSTEM` prompt defined in **src/engine.ts** (lines 96‑113). This prompt instructs the LLM to preserve immutable constraints such as compliance requirements, budget limitations, and physical laws, while stripping details that merely reflect current implementation choices like specific frameworks or databases.

### Where is the reframed problem stored when anchors are removed?

If the reframe pass modifies the problem statement, the cleaned version is stored in the `reframe` field of the `RunResult` object, as defined in **src/types.ts**. The actual problem passed to the divergence phase is replaced with this reframed text, while the original remains accessible through the result object for comparison.

### Can I disable the reframe pass to maintain specific technical constraints?

Yes. Set `stripAnchors: false` in your `RunOptions` when calling the `run` function. This bypasses the `reframeProblem` call entirely, ensuring the divergence phase receives the original problem statement with all implementation-specific details intact.