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"]

Step combining: When two steps need the same project knowledge loaded, combining them is nearly free — the knowledge is loaded once, both steps execute in the remaining space. Splitting them wastes context by loading the same knowledge twice. Step boundaries belong where information gaps exist, not where implementation boundaries happen to fall.

Dynamic vs static constraints: RT-ICA produces dynamic constraints — discovered fresh from the current goal, disposable after use. These provide visibility into edges that would cause problems if crossed blindly: scope creep, missing user opinions, abstract requirements that need to become definite. RT-ICA's value is turning the abstract into the definite for each specific task.

Self-Initialization from Backlog Item

When invoked with a #N argument (e.g., Skill(skill='dh:rt-ica', args='#42')):

1. Load item context before doing anything else:

uv run "${CLAUDE_PLUGIN_ROOT}/sam_schema/cli.py" backlog view --selector "#N"

Note: the CLI's backlog view has no summary toggle — it always returns the flatter, full-content equivalent of summary=false.

2. Extract: title, description, sections['Acceptance Criteria'], sections['Expected Behavior'], sections['Impact Radius'], and any other populated sections.
3. Use the loaded content as the goal input for the RT-ICA procedure below.
4. After completing the assessment, write the RT-ICA result back to the item:

uv run "${CLAUDE_PLUGIN_ROOT}/sam_schema/cli.py" backlog groom --selector "#N" --section "RT-ICA" --content "{RT-ICA SUMMARY block}"

Without a #N arg, the skill expects the goal/input to be provided inline in the invocation context. Invoking without args and without inline context returns BLOCKED — always pass #N when invoking from a workflow step that has an item reference.

Activation Triggers

<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)

</activation_triggers>

Definitions

Term	Definition
Goal	A desired outcome the user wants
Condition	A prerequisite that must be true to achieve the goal
Required Information	Concrete data needed to confirm or satisfy a condition
AVAILABLE	Explicitly present in provided material or loaded project evidence. Must cite exact source.
EVIDENCE-DERIVED	Not stated verbatim, but forced by cited evidence. Must state inference, basis, and contradiction check. Not allowed for taste, policy, product meaning, security, external effects, or user preference.
SAFE-DEFAULTED	Not known as fact, but a local default was chosen because every Safe Default Gate criterion passed. Must record chosen default, scope, reversibility, and verification.
MISSING	Required information is not available, not evidence-derived, and not safe-defaultable.
HARD-BLOCKED	Missing input involves irreversible or destructive action, external side effects, credentials, production data, compliance or security policy, or meaning-affecting user or product choice.

Safe Default Gate

Safe-defaulting is permission to choose a low-risk local implementation detail, not permission to invent a requirement. If the missing detail affects meaning, policy, external behavior, data, security, or user intent, it is not safe-defaultable.

A missing detail may be SAFE-DEFAULTED only when all of the following are true:

1. Bounded outcome with known blast radius - the possible outcomes are known, limited, and do not create material risk outside the task boundary.
2. Blast radius is named - exact files, commands, generated artifacts, tests, and runtime surfaces affected are identified.
3. Existing evidence narrows the choice - code, tests, docs, schemas, examples, or nearby patterns constrain acceptable options. Cite the project evidence; do not rely on general model prior.
4. Easily reversible action - the change can be undone cleanly with a local revert, file edit, config rollback, branch reset, or regenerated artifact.
5. Low-impact local change - the decision affects naming, formatting, organization, helper structure, comments, local docs, tests, or similar local implementation details without changing scope or product intent.
6. Convention-following choice - the selected option matches a cited repository, team, or platform convention.
7. Equivalent implementation paths - if multiple approaches are possible, they are equivalent for current requirements, preserve behavior, and do not introduce new operational risk.
8. Verification method exists before action - tests, CI, type checks, linters, static analysis, or reproducible local validation exist and can expose a wrong choice before merge or release.
9. Non-user-visible internal improvement - the choice does not alter product behavior, public contracts, data formats, persistence, security posture, or external integrations.
10. Safe default exists - the project, user instructions, or platform define a conservative default and the agent is following it.
11. Generated artifact can be regenerated - if editing derived outputs, the source of truth and regeneration command are known.
12. Failure mode is recoverable - a wrong choice fails loudly as a test failure, build rejection, local exception, or harmless no-op rather than causing hidden corruption, user impact, deployment damage, or data loss.
13. Scope is explicit and narrow - the task boundary is clear and the choice does not expand the requirement or alter unrelated systems.
14. No external side effect - work stays in the local workspace, branch, draft, sandbox, test environment, or disposable resource.
15. Risk is observable before commit - problems surface before merge, release, deploy, publish, notify, charge, delete, migrate, or otherwise affect external state.
16. Choice affects presentation or implementation detail, not meaning - wording, ordering, section names, formatting, examples, explanation style, internal structure, or equivalent implementation detail may change, but the underlying requirement or behavior does not.

If any item is false, unknown, or subjective, do not safe-default. Mark the condition MISSING or HARD-BLOCKED.

Ambiguity Escalation Rules

If ambiguity would increase the risk profile of the task, do not let the agent silently choose a path. Convert the ambiguity into a research item, clarification question, or hard block, then present the findings and open decisions back to the human in a compact, decision-ready form.

Use the following rules:

1. Security boundary or credential ambiguity - any action involving secrets, credentials, tokens, auth rules, permissions, encryption keys, signing keys, customer data, or privilege escalation where the agent cannot prove the change is safe. Stop when access scope, exposure risk, or downstream authority is unclear.
2. External side effect the agent cannot undo - sending email, posting publicly, notifying users, charging money, opening tickets against another team, modifying vendor systems, or triggering a workflow outside the repo. If the action leaves the local workspace and cannot be confidently recalled, ask first.
3. Data migration or schema change with uncertain compatibility - changing persisted data, migrations, serialization formats, protocol contracts, public APIs, config schemas, or artifact formats when backward or forward compatibility is not proven. Stop when existing consumers may break and the agent cannot verify them.
4. Policy, legal, compliance, or privacy uncertainty - anything involving licenses, regulated data, retention rules, audit requirements, user privacy, export controls, employment matters, or contractual obligations. The agent must not infer authority from silence.
5. Missing rollback path - a change where the agent cannot describe how to recover the previous known-good state. This includes deployments, infra mutations, dependency upgrades, migrations, and generated artifacts. If rollback is unknown, treat the action as unsafe.
6. Contradiction with explicit instructions or project conventions - when the task request conflicts with repository rules, prior decisions, ADRs, coding standards, security policy, or direct user instructions. Stop and surface the conflict instead of silently choosing one.
7. Insufficient test signal for high-impact behavior - tests pass, but they do not exercise the behavior being changed, or the agent cannot map the test coverage to the risk. Passing unrelated CI is not permission to proceed.
8. Authority ambiguity - the agent can technically perform the action, but it is unclear whether it is allowed to make that decision. This includes changing scope, accepting tradeoffs, redefining requirements, merging, releasing, deleting, or overriding another owner.
9. Dependency or supply-chain uncertainty - adding, upgrading, replacing, vendoring, or executing third-party code when license, provenance, security posture, runtime behavior, or maintenance status is unclear. Stop when the agent cannot justify the dependency.
10. Cost, quota, or resource expansion - actions that may materially increase spend, consume limited quota, reserve infrastructure, start long-running jobs, or scale resources. If the agent cannot estimate or bound the cost, ask first.
11. Ambiguous ownership of failure - when a failure could belong to environment, test data, credentials, infrastructure, product behavior, or the agent’s own change, and proceeding would mask the root cause. Stop and report the ambiguity.
12. User-visible behavior change without confirmed intent - UI text, API responses, workflow behavior, permissions, defaults, notifications, error handling, or product semantics that could be valid either way. If users would notice and intent is not explicit, ask.

Default routing for these ambiguity classes:

• HARD-BLOCKED for security, privacy, destructive external effects, irreversible data risk, compliance, missing rollback, or unclear authority over consequential actions.
• REQUIRES-USER when the ambiguity is about intent, policy, scope, ownership, user-visible behavior, or risk acceptance.
• REQUIRES-DISCOVERY when repository, runtime, test, or architecture evidence could resolve the ambiguity safely before action.

These are provisional routes, not permanent labels. After discovery:

• If evidence resolves the ambiguity, reclassify it as AVAILABLE or EVIDENCE-DERIVED and proceed without asking the human.
• If the remaining choice becomes a bounded local default and every Safe Default Gate criterion passes, record it as SAFE-DEFAULTED and proceed without asking the human.
• Ask the human only for ambiguity that remains unresolved after research or still requires human judgment.

Respect the human's attention:

• Never interrupt with one-off clarification questions. All REQUIRES-USER paths must be batched into a single clarification packet for the current goal or sub-goal.
• Do required discovery first when the answer may already exist in local evidence, runtime evidence, internet research, or other available tools.
• Before asking the human, explore the repo, docs, tests, runtime artifacts, internet sources, or other relevant tools enough to narrow the question and eliminate avoidable uncertainty.
• If exploration disproves the cautionary assumption or resolves the risk, do not ask the human. Reclassify the condition from evidence, answer it directly, and continue.
• Present research findings and open choices together so the human can make an educated decision without redoing the investigation.
• Name the question, why it matters to the goal, the side effects or affected boundary, the current constraints, the available options that fit those constraints, the risk of choosing incorrectly, and the recommended path if one exists.
• Keep the batch minimal in count but complete in context: ask only the questions that still require human judgment after exploration is exhausted.

Report Back For Review

Exploration for RT-ICA often surfaces issues beyond the current scoped task. These do not automatically block the current work, but they must be reported back to the orchestrator or supervisor agent so they can be tracked, reviewed, and converted into follow-up tasks or backlog items when appropriate.

Create a review report for findings such as:

1. Tool failure or unreliable tooling - required tools fail, behave inconsistently, return partial results, time out, produce malformed output, or cannot access expected files, services, commands, APIs, or repositories.
2. Environmental or configuration failure - tests fail because of missing dependencies, credentials, paths, services, ports, containers, hardware, permissions, clocks, network access, package versions, or machine-specific state rather than because product behavior is clearly wrong.
3. Edit, read, or write failure - the agent cannot read, modify, save, patch, diff, move, delete, or inspect expected files. Include what was attempted, what failed, and whether the final state is known.
4. Verification gap - implementation completed but relevant validation could not run, or validation ran but did not exercise the risk being changed.
5. Suspicious code quality concern - magic numbers, duplicated logic, non-DRY implementation, non-SOLID architecture, unclear ownership, hidden coupling, excessive complexity, stale abstractions, or brittle tests.
6. Stale or misleading documentation - docs, comments, examples, ADRs, READMEs, generated references, or inline guidance appear outdated, contradicted by the code, or likely to mislead future agents or engineers.
7. TOCTOU or state-race concern - behavior depends on a check-then-act sequence where state may change between validation and use, especially around files, permissions, credentials, locks, external resources, deployments, or concurrent workflows.
8. Workaround introduced to achieve the goal - workaround, shim, bypass, hardcoded assumption, skipped validation, temporary branch, compatibility hack, retry loop, fallback path, or manual step was added to make progress.
9. Tech debt introduced knowingly - immediate goal was satisfied but cleanup work, architectural compromise, test debt, duplicated behavior, unclear naming, narrow assumptions, or future migration risk remains.
10. Unexpected complexity or scope expansion - the task required touching more systems, files, layers, dependencies, or concepts than expected, even if implementation succeeded.
11. Inconsistent project conventions - nearby code uses conflicting patterns and the agent had to choose one without a clear standard.
12. Ambiguous ownership or boundary friction - unclear which module, team, interface, service, config layer, or document owns the behavior being changed.
13. Manual intervention required - a human must run a command, provide credentials, inspect an environment, approve a change, update an external system, or diagnose a failure before the work can be considered complete.
14. Partial success - some parts of the task were completed but others were skipped, blocked, approximated, unverified, or deferred.
15. Risk accepted locally - the agent proceeded because the risk was bounded and reversible, but the concern is still worth reviewing before merge, release, or future reuse.

For each report-back item, record:

• Issue category
• What was observed
• Why it matters
• Whether it blocks current work
• Recommended owner or destination
• Recommended follow-up action or backlog item

When such findings exist, emit them in a literal <concerns>...</concerns> block so the orchestrator or supervisor can append them into backlog ## Concerns using the plugin's existing concern-ingestion flow. Do not bury these findings only inside prose.

RT-ICA Procedure

Apply this procedure to each goal and sub-goal:

The final RT-ICA artifact should function like a compact PRD for the scoped work. It should leave downstream planners and executors with explicit goals, constraints, evidence, open questions, resolved decisions, risks, validation expectations, and review-worthy findings without requiring reconstruction from chat history.

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.

Question discovery is recursive:

• During exploration, research, or subagent work, new unknowns may appear.
• Any newly discovered unknown that matters to the goal must be added to the active question queue.
• For each queued question, first attempt resolution through repo evidence, runtime evidence, tests, internet research, or other available tools.
• If research answers the question, close it from the queue and record the evidence.
• If research narrows but does not resolve it, keep it in the queue with updated constraints, options, and risks.
• If it still requires human judgment after exploration, include it in the batched clarification packet.
• Repeat until each queued question is either answered from evidence or escalated to the human.

<condition_categories>

Include conditions in these categories (where applicable):

Category	Example Conditions
Functional requirements	Features, behaviors, user flows
Non-functional requirements	Latency, throughput, availability, compliance, security
Interfaces/Integration	APIs, schemas, dependencies, external systems
Environment/Runtime	Cloud, region, OS, language, build system
Data requirements	Sources, quality, migration, retention
Access/Permissions	Repos, secrets, credentials, IAM
Operational constraints	SLOs, oncall, monitoring, incident response
Delivery constraints	Timeline, release process, approvals
Verification needs	Tests, canaries, acceptance criteria, observability
Risks/Failure modes	Rollback, data loss, security exposure
Replacement coverage	Full capability inventory of module being replaced, coverage matrix against replacement tool
Data Deletion Fidelity	When goal text signals source data will be deleted (keywords: "delete", "remove", "drop", "migrate from X", "replace X with Y", "convert format", "remove source after migration"): acceptance criteria must include a content completeness check against real production data AND an explicit deletion gate. If absent: classify as MISSING.

</condition_categories>

For each condition, specify:

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

Step 3: Evidence and Defaultability Verification

For each condition, classify evidence first, then action disposition.

Evidence status:

Status	Required proof
AVAILABLE	Cite exact source snippet or section name
EVIDENCE-DERIVED	Cite source, inference, basis, and contradiction check
UNRESOLVED	State what source is absent or ambiguous

If evidence status is UNRESOLVED, classify disposition:

Disposition	Use when
SAFE-DEFAULTABLE	Every Safe Default Gate criterion passes
REQUIRES-DISCOVERY	Repo, runtime, test, or document inspection can resolve the gap
REQUIRES-USER	The missing detail affects product meaning, policy, security, external systems, approvals, or user-visible behavior
HARD-BLOCK	The gap is destructive, irreversible, external-side-effecting, production-data-affecting, credential-related, compliance-related, or not recoverable

Final condition label: