rt-ica

name: rt-ica description: Use before creating plans, delegating to agents, or defining acceptance criteria — performs Reverse Thinking Information Completeness Assessment (RT-ICA) to surface missing prerequisites and block planning until all required inputs are verified. Activates on specs, PRDs, tickets, RFCs, architecture designs, and multi-step engineering tasks. Integrates with CoVe-style planning pipelines. user-invocable: true context: fork

RT-ICA: Reverse Thinking - Information Completeness Assessment

Sister skill — when to use which

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

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. This is different from static process constraints (hardcoded gates, enforcement hooks, "MUST do X before Y" rules baked into workflow definitions) which carry maintenance cost and go stale. 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:

mcp__plugin_dh_backlog__backlog_view(selector="#N", 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:

mcp__plugin_dh_backlog__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

Definitions

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.

IF any condition is HARD-BLOCKED:
    DECISION = BLOCKED
ELSE IF any condition is MISSING or REQUIRES-USER:
    DECISION = BLOCKED
ELSE IF any condition is REQUIRES-DISCOVERY:
    DECISION = BLOCKED unless the task is explicitly a discovery task
ELSE:
    DECISION = APPROVED

Output Format

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]: Evidence=[AVAILABLE|EVIDENCE-DERIVED|UNRESOLVED] | Disposition=[N/A|SAFE-DEFAULTABLE|REQUIRES-DISCOVERY|REQUIRES-USER|HARD-BLOCK] | Basis: [citation/inference/check]
- [Condition 2]: Evidence=[AVAILABLE|EVIDENCE-DERIVED|UNRESOLVED] | Disposition=[N/A|SAFE-DEFAULTABLE|REQUIRES-DISCOVERY|REQUIRES-USER|HARD-BLOCK] | Basis: [citation/inference/check]
...

Decision:
- [APPROVED|BLOCKED]

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

[Category]:
- Question: [missing item question]
- Why it matters: [impact to goal]
- Known constraints: [repo, runtime, policy, or user constraints already discovered]
- Options under current constraints: [option A / option B / option C]
- Risk if wrong: [side effect or failure mode]

[Category]:
- Question: [missing item question]
- Why it matters: [impact to goal]
- Known constraints: [repo, runtime, policy, or user constraints already discovered]
- Options under current constraints: [option A / option B / option C]
- Risk if wrong: [side effect or failure mode]

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

Safe Defaults Applied (SAFE-DEFAULTED only):
- [choice made] | Why allowed: [checks passed] | Validation step: [how risk is surfaced before external impact]

<concerns>
[Issue category]
  Observation: [what was found]
  Why it matters: [impact]
  Blocks current work: [yes/no]
  Recommended owner/destination: [owner, supervisor, backlog, or task stream]
  Recommended follow-up: [task/backlog/escalation]
</concerns>

Integration with CoVe-Style Planning

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)

Guardrails

Question Templates

Example: RT-ICA in Action

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: Evidence=UNRESOLVED | Disposition=REQUIRES-USER | Basis: Protocol choice is not specified and affects product behavior
- User store: Evidence=EVIDENCE-DERIVED | Disposition=N/A | Basis: docker-compose.yml shows PostgreSQL; no conflicting store definition found
- Session management: Evidence=UNRESOLVED | Disposition=REQUIRES-USER | Basis: Token format and expiry policy are not specified and affect security posture
- Integration points: Evidence=UNRESOLVED | Disposition=REQUIRES-DISCOVERY | Basis: Calling services may be discoverable from repo interfaces, but are not explicit in the request
- Security requirements: Evidence=UNRESOLVED | Disposition=REQUIRES-USER | Basis: Compliance obligations are not derivable from the request and affect policy and controls
- Deployment target: Evidence=AVAILABLE | Disposition=N/A | Basis: 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

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

Problem: Assumed requirements, will likely need rework

Model asks 20 questions about edge cases before understanding core requirements

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

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.