ad-radicem

name

ad-radicem

description

Use when a task needs problem-space reconstruction before solutioning: ambiguous diagnosis, strategy, architecture, product behavior, agent/RAG/memory/context issues, root-cause analysis, or design decisions. Also use when compressing long agent context into a reusable problem state. Uses a flow from phenomenon to observation distortion, structure, governing variables, constraints, minimum intervention, solution, premise break, and prediction. Do not use for simple facts, rewrites, or direct execution when the solution is already chosen.

Ad Radicem

Ad Radicem is a process-correction skill for moving rootward before solving.

It is not a prompt for longer answers. It prevents a shallow problem frame from being accepted too early.

Core Rule

Never treat the observed phenomenon as the problem.

First reconstruct the problem space. Only then propose a solution.

Core flow:

Phenomenon
-> Observation Distortion
-> Structure
-> Governing Variables
-> Constraints
-> Minimum Intervention Point
-> Solution
-> Premise Break
-> Falsifiable Prediction

If this is too heavy, use Minimal Mode. For non-trivial tasks, do not skip observation distortion, governing variables, constraints, premise break, or prediction.

Use When

Use this skill when one or more are true:

• The user asks for analysis, diagnosis, strategy, design, architecture, root cause, or problem framing.
• The problem is ambiguous, underspecified, or has multiple plausible causes.
• A generic solution list would be easy but likely shallow.
• The task involves product behavior, agents, RAG, memory, context handling, compression, long-running workflows, or system design.
• The task is to compress long agent context, session history, or working state for later use.
• The main risk is premature solutioning rather than lack of domain knowledge.

Do not use this skill when:

• The user asks for a short factual answer.
• The task is a rewrite, translation, format conversion, or direct implementation.
• The solution is already chosen and the task is only execution.
• The problem space has already been reconstructed well enough for the requested action.

Reference Loading

Keep ordinary use lightweight. Load extra files only when needed:

• references/runtime-expanded.md: expanded output contract, review defects, external lenses, and detailed gates.
• references/compression-contract.md: full field-by-field contract for compressing context into problem state.
• references/research-grounding.md: research grounding or design defense.
• references/market-landscape.md: novelty, positioning, adjacent tools, or differentiation.
• references/market-validation.md: market value, buyer relevance, adoption timing, or business case.
• evals/rubric.md: rigorous review of an Ad Radicem output.
• evals/value-metrics.md: value comparison against baseline and terse outputs.
• examples/showcase.md: demonstration or shallow-baseline comparison.
• evals/fixtures/: realistic validation prompts.

Operating Discipline

1. Keep solutions latent until governing variables are named.
2. Separate facts, hypotheses, assumptions, and unknowns.
3. Question the observation before explaining it.
4. Describe structure as relationships and flows, not a cause list.
5. Use constraints to remove easy escapes, not just to list project limits.
6. Make the minimum intervention point more abstract than the concrete solution.
7. Map every solution to the intervention point it implements.
8. Include a premise break for non-trivial tasks.
9. Add a falsifiable prediction or probe.
10. If evidence exists, inspect it before building a causal story.
11. If evidence is absent, label the analysis as hypothesis and name what would change it.
12. If a probe can run now with available tools, run it before final output and report results instead of predictions.
13. For compression, follow the Compression Contract instead of writing a prose summary.

Output Contract

For substantial tasks, return this structure. For smaller tasks, compress it but preserve the reasoning order.

# Ad Radicem Analysis

## 0. Task Boundary
Scope for this pass. Non-scope. Diagnosis, design, planning, strategy, or research.

## 1. Phenomenon
Only what is observed. No inferred causes or solutions.

## 2. Observation Distortion
How the observation may mislead: measurement, sampling, wording, time window,
baseline, salience bias, stale data, or interpretation described as event.

## 3. Structure
Relationships and flows that could produce the phenomenon. State what must be
true for the phenomenon to occur and what removal would weaken it. Mark major
claims as Fact, Hypothesis, or Assumption.

## 4. Governing Variables
Variables that materially move the result. Note impact, operability,
observability, and side effects for important variables.

## 5. Constraints
Record given constraints and user prohibitions verbatim, then add deliberate
constraints that remove shallow answers, such as "do not solve by adding more
context" or "do not rely on human vigilance."

## 6. Minimum Intervention Point
Smallest place to intervene that changes the structure. One abstraction level
above the concrete solution.

## 7. Solution
Specific action mapped to the intervention point and governing variables.

## 8. Premise Break
Change the setup so the original problem no longer needs to be solved as stated.
For incidents that already happened, aim the break at the recurrence class, or
state in one line why no break applies. If the break is viable, compare it to
the solution on cost and reversibility in one or two sentences.

## 9. Falsifiable Prediction
What should be observed if the structure hypothesis is right, and what should
change if the intervention works. What would weaken or disprove either. Define
a small probe or experiment; if it can run now, run it and report the result.

## 10. Residual Risk
Remaining uncertainty, missing evidence, and what to observe before committing harder.

Sections 1-9 follow the core flow; Task Boundary opens it and Residual Risk closes it. Each section must add new analytical state. If it only rephrases an earlier section, revise it.

Compression Contract

When compressing context, do not write a normal summary. Convert raw context into a solvable problem representation with explicit fields: facts, observations, constraints, decisions, open questions, hypotheses, governing variables, minimum intervention point, premise break, evidence needed, and do-not-reopen.

Do not collapse uncertainty into certainty. Do not turn a rejected option into a possible option. Do not drop negations, prohibitions, dates, or versions.

Load references/compression-contract.md for the full field-by-field contract.

Quality Gate

Check each item before final output. If any check fails, stop and revise instead of continuing:

• A solution appeared before governing variables were named.
• A cause was asserted without questioning the observation first.
• Hypotheses are written as facts.
• Structure is a cause list or a generic best-practice list, not relationships and flows.
• Governing variables cannot actually be moved.
• Constraints remove no shallow answer class; given limits alone do not count.
• The intervention point is not more structural than the solution, or a solution does not map to it.
• The premise break is just an alternative implementation.
• No prediction or probe could falsify the analysis, or the analysis cannot say what evidence would change its mind.
• A probe that could run now was left as a prediction.
• Compression dropped constraints, negations, prohibitions, decisions, uncertainty, or rejected paths.

Minimal Mode

If the user needs a concise answer, keep the reasoning compact:

Phenomenon:
Likely distortion:
Structure hypothesis:
Governing variable:
Constraint:
Minimum intervention:
Solution:
Premise break:
Prediction:

Even in Minimal Mode, do not skip observation distortion, governing variables, constraints, premise break, or prediction for non-trivial tasks.