RT-ICA: Reverse Thinking - Information Completeness Assessment

RT-ICA: Reverse Thinking - Information Completeness Assessment

Purpose

This skill inserts a mandatory RT-ICA checkpoint into planning workflows. For every goal (top-level and each decomposed sub-goal), the model MUST:

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

No planning, delegation, scheduling, or solution design may begin until RT-ICA has been performed 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, the model MUST stop and request only the missing information.

Activation Triggers

Invoke RT-ICA when receiving ANY of:

• Spec, request, ticket, user story, PRD, architecture design, RFC
• Request to produce a plan, execution order, agent delegation, guardrails, acceptance criteria, or rollout steps
• Any multi-step engineering effort with dependencies, unknowns, constraints, or risk

Integration Points (where RT-ICA checkpoints MUST occur):

1. Before creating the top-level plan
2. Before delegating tasks to specialized agents (per-agent input completeness)
3. Before finalizing acceptance criteria (verify testability inputs exist)
4. Before defining rollout/ops steps (verify env and access inputs exist)

Definitions

RT-ICA Procedure

Apply this procedure to each goal and sub-goal:

Step 1: Goal Reconstruction

Produce:

• Goal statement: One sentence describing the desired outcome
• Output form: What deliverable proves success (artifact, behavior, metric, deployment state)
• Scope boundaries: In-scope/out-of-scope if stated

Step 2: Reverse Prerequisite Enumeration

Work backwards from the goal to list ALL conditions required for success.

Include conditions in these categories (where applicable):

For each condition, specify:

• Condition name
• Required information to verify/satisfy it
• Why it matters (one line)

Step 3: Availability Verification

For each condition, set status:

Step 4: Completeness Decision

IF any condition is MISSING:
    DECISION = BLOCKED
ELSE:
    DECISION = APPROVED

Step 5: Action Based on Decision

IF BLOCKED:

1. Do NOT plan
2. Ask ONLY for missing inputs
3. Structure questions by category, ordered by criticality
4. Prefer multiple-choice or constrained questions when possible
5. If user explicitly requests assumption-based planning:
   • Proceed with explicit assumptions for each missing condition
   • Include risk note per assumption
   • Add validation tasks to confirm assumptions early

IF APPROVED:

1. Proceed to normal planning
2. Carry forward the validated condition list
3. Mark DERIVABLE items as "assumptions to confirm"
4. Enforce constraints as guardrails

Output Format

The model MUST produce this summary block for each goal/sub-goal:

RT-ICA SUMMARY

Goal:
- [one sentence]

Success Output:
- [deliverable/observable result]

Conditions (reverse prerequisites):
1. [Condition] | Requires: [info] | Why: [1 line]
2. [Condition] | Requires: [info] | Why: [1 line]
...

Verification:
- [Condition 1]: [AVAILABLE|DERIVABLE|MISSING] | Evidence/Basis: [text]
- [Condition 2]: [AVAILABLE|DERIVABLE|MISSING] | Evidence/Basis: [text]
...

Decision:
- [APPROVED|BLOCKED]

--- IF BLOCKED ---
Missing Inputs Requested:

[Category]:
- [missing item question] (why needed)
- [missing item question] (why needed)

[Category]:
- [missing item question] (why needed)

--- IF APPROVED ---
Assumptions to Confirm (DERIVABLE only):
- [assumption] | Basis: [basis] | Validation step: [how to confirm early]

Integration with CoVe-Style Planning

Recommended sequence with RT-ICA:

A) RT-ICA on top-level goal
B) Draft plan and decomposition
C) RT-ICA on each major workstream/sub-goal
D) Assign agents with clearly bounded deliverables
E) Verification pass: cross-check plan against conditions and acceptance criteria
F) Refinement pass: resolve gaps, reduce risk, ensure ordering and guardrails

Planning Deliverables (After APPROVED)

After RT-ICA APPROVED decision, produce a plan that includes:

Guardrails

The model MUST NOT:

• Fabricate unknown inputs
• Silently assume missing requirements
• Begin planning with MISSING conditions (unless user explicitly requests assumption-based planning)

The model MUST:

• Keep missing-input questions minimal and high signal
• Prefer early validation tasks for DERIVABLE items
• Block planning when information is insufficient

Question Templates

When requesting missing inputs, use structured questions:

Environment/Infrastructure:

• "What is the target environment (prod/stage/dev), and where will this run (cloud/region/account)?"

Success Criteria:

• "What are the success metrics or acceptance criteria (latency, correctness, SLO)?"

Integration:

• "Which systems/APIs are in scope, and what are their interface contracts (schema/version)?"

Technical Constraints:

• "Are there constraints on language/framework/build tooling?"

Approvals:

• "Who owns approvals for release and security review (if required)?"

Example: RT-ICA in Action

User Request: "Build a user authentication service"

RT-ICA Summary:

RT-ICA SUMMARY

Goal:
- Implement user authentication service for the application

Success Output:
- Deployed service that authenticates users and issues session tokens

Conditions (reverse prerequisites):
1. Auth protocol | Requires: OAuth2/OIDC/custom spec | Why: Determines implementation approach
2. User store | Requires: Database type, schema | Why: Persistence layer dependency
3. Session management | Requires: Token format, expiry rules | Why: Security policy compliance
4. Integration points | Requires: API consumers list | Why: Interface contract design
5. Security requirements | Requires: Compliance standards (SOC2, HIPAA) | Why: Audit requirements
6. Deployment target | Requires: Cloud/region/infra | Why: Runtime configuration

Verification:
- Auth protocol: MISSING | Need: Which protocol to implement
- User store: DERIVABLE | Basis: Project uses PostgreSQL per docker-compose.yml
- Session management: MISSING | Need: Token format and expiry policy
- Integration points: MISSING | Need: List of services calling auth
- Security requirements: MISSING | Need: Compliance requirements if any
- Deployment target: AVAILABLE | Evidence: README specifies AWS us-east-1

Decision:
- BLOCKED

Missing Inputs Requested:

Authentication Design:
- Which auth protocol: OAuth2, OIDC, or custom JWT? (determines implementation)
- Session token expiry policy? (security requirement)

Integration:
- Which services will consume this auth service? (API contract design)

Compliance:
- Are there compliance requirements (SOC2, HIPAA, etc.)? (audit scope)

Anti-Patterns

Planning without RT-ICA:

User: "Build auth service"
Model: "Here's my plan: 1. Create user table, 2. Add login endpoint..."

Problem: Assumed requirements, will likely need rework

Asking too many questions:

Model asks 20 questions about edge cases before understanding core requirements

Problem: Overwhelms user, delays progress on high-signal items

Proceeding with silent assumptions:

Model: "I'll assume OAuth2 since that's common..."

Problem: Assumption may be wrong, causes rework or security issues

Related Skills

• agent-orchestration - Scientific delegation framework for orchestrator-to-agent workflows
• subagent-contract - DONE/BLOCKED signaling protocol for sub-agents

Sources

Note: This skill adapts the RT-ICA (Reverse Thinking for Information Completeness Assessment) framework for planning workflows.