framing-cybernetic-intent

name	framing-cybernetic-intent
description	Use when cybernetic routing is requested but user input is pre-task intent or role-ambiguous context: confusion, dissatisfaction, risk sense, observed symptoms, failed attempts, method preference, process distrust, source material, declared current state, or unclear requested transformation.

Framing Cybernetic Intent

Overview

Use this before workflow routing when the input is not yet a formed task.

human situation -> role binding -> collaborative intent framing -> Shared Intent Understanding -> optional task candidate

This is not routing, requirements analysis, planning, review, or execution. Detailed rules live in references/intent-framing-detailed-rules.md.

Core Rule

Bind input roles before treating anything as the task.

Protect these distinctions:

• method preference is not purpose;
• source material is not automatically the primary object;
• declared current state is not automatically a new investigation;
• confusion, dissatisfaction, risk sense, failed experience, and process distrust are pre-task inputs until shared intent is clear.

Do not turn source material into the task unless the user explicitly asks to act on it as the primary object.

Do not turn a declared completed finding into a new investigation unless the user asks to verify it.

Do not treat current implementation as the primary object of a feasibility inquiry unless the user asks for current-state audit.

Input Role Binding

At minimum identify:

• human purpose;
• method preference;
• source material;
• declared current state;
• requested transformation;
• primary object;
• reference object;
• non-goals;
• uncertainty to reduce.

Value / Fidelity Frame

Use this only when result fidelity, cost, or visible meaning could materially differ. Capture:

• value_sought: the user value behind the requested feature or change;
• maximum_fidelity_reference: the most faithful observable result, not an automatic requirement;
• truthful_approximation_boundary: what a lower-cost result may say, and must never imply;
• decision_to_defer: what still needs facts or a human choice.

Do not estimate cost, generate candidates, or choose a technical path here. Defer that fact-bound analysis to the selected route: direct current-turn work or commitment formation. Skip this frame when there is no meaningful tradeoff.

Ask one concise role-binding question only when roles conflict or the primary object is ambiguous.

Process

1. Reflect the situation, bind roles, and identify a material tradeoff.
2. Capture the frame when needed; state unproven assumptions; ask at most one high-value question if intent is unstable.
3. Summarize Shared Intent Understanding and offer a response-only next move.

The loop ends at shared understanding, not artifact production.

Default Output

Use the chat-only shape from references/intent-framing-detailed-rules.md. It starts with:

Shared Intent Understanding
- Human situation:
- Input role binding:
  - Source material:
  - Declared current state:
  - Requested transformation:
  - Primary object:
  - Reference object:
  - Method preference:
  - Non-goals:
- Value / Fidelity Frame, when relevant:
  - Value sought:
  - Maximum fidelity reference:
  - Truthful approximation boundary:
  - Decision to defer:

Possible next moves:

• continue intent framing;
• make a judgment or decision;
• design a small experiment;
• perform a bounded inspection;
• hand off to $routing-cybernetic-workflows;
• stop because purpose is not stable.

Optional Task Formation

Only include a task candidate after shared intent is clear. If the next step is routing, keep the handoff response-only:

$routing-cybernetic-workflows <clear task statement>

Do not hand off from Framing directly to commitment formation. Routing decides whether the formed task needs durable commitment control.

Carry a relevant Value / Fidelity Frame in the task statement or surrounding chat. The router chooses whether durable commitment is needed; the selected route then investigates candidate paths before implementation (direct work) or before approval (commitment formation).

Do not write this command into requirements, design, goal, plan, review, progress, or orchestration artifacts.

Persistence

Default to no file write. Persist only when the user asks or it guides future approved files.

Use assets/intent-frame-template.md. The intent brief must not contain complete requirements, solution design, execution policy, control review, or runtime goal content.

Common Mistakes

• Treating "use this workflow" as the user's goal.
• Treating source material as the task object.
• Treating declared completed findings as a new investigation request.
• Treating artifact creation as evidence that intent is clear.