rt-ica

RT-ICA: Reverse Thinking - Information Completeness Assessment

Sister skill — when to use which

If you are…	Load
At the S2 implementation gate where missing inputs must halt the pipeline	dh:rt-ica (this skill — blocking)
Grooming a backlog item, generating a plan, decomposing tasks under uncertainty	dh:planner-rt-ica (the non-blocking sister skill)

dh:rt-ica and dh:planner-rt-ica are deliberately split: same framework, different cost-of-being-wrong. At the implementation gate, a MISSING condition is a halt event because the agent would otherwise guess. During planning or grooming, the same MISSING is a research task or a question for the human. Do not consolidate.

Purpose

RT-ICA surfaces what the executor needs to know before it can act without stopping.

For every goal (top-level and each decomposed sub-goal), the model should:

1. Reverse-think prerequisites from the goal
2. Assess information completeness for each prerequisite
3. Either BLOCK planning until missing inputs are obtained, or APPROVE with explicit assumptions

<core_rule>

RT-ICA should be performed before planning, delegation, or solution design on:

1. The overall goal/request
2. Each decomposed goal or sub-goal that could fail due to missing information

If any required condition is MISSING, stop and request only the missing information.

</core_rule>

Complexity Model

Task complexity is not implementation difficulty — it is the ratio of project-specific knowledge required to context window available.

Training data provides craft knowledge (language patterns, framework APIs, tooling). That is free. What consumes context budget is everything specific to this project: schemas, conventions, constraints, interfaces, user preferences, existing system behavior. That knowledge must be loaded before the agent can act.

This changes how RT-ICA results inform task design:

flowchart TD
    RTICA["RT-ICA conditions enumerated"] --> Measure["Estimate knowledge payload:<br>how much project-specific context<br>must be loaded to satisfy conditions?"]
    Measure --> Ratio{Knowledge payload<br>vs context window?}
    Ratio -->|"< 40% of window<br>Room to work"| Proceed["Single task — execute directly"]
    Ratio -->|"40-70% of window<br>Tight but workable"| Combine["Look for steps sharing<br>the same knowledge payload —<br>combine them into one task"]
    Combine --> Proceed
    Ratio -->|"> 70% of window<br>No room to implement"| Decompose["Decompose into subtasks<br>that each need a smaller<br>subset of the knowledge"]