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

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)

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

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.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}