| name | mechanism-guided-analysis |
| description | Use when a problem's visible symptoms, repeated local fixes, or apparently adequate solution may conceal a different generating mechanism; helps Codex notice weak signals, question hidden assumptions and relationships, form plausible competing mechanisms, and derive better designs or discriminating validations. Do not use when the cause is already established, the task is straightforward execution, or the user only needs a direct factual answer. |
Mechanism-Guided Analysis
Look beyond a surface symptom only when doing so could change the explanation, design, or next action. Draw freely on relevant theories and other knowledge as background reasoning, not as content to recite or a framework to impose.
Treat a coherent explanation as a candidate mechanism, not an established root cause. Preserve uncertainty until evidence distinguishes among plausible accounts.
Signals Worth Noticing
- A requirement, convention, constraint, or proposed solution is being treated as inevitable.
- A local fix repeatedly fails, moves the problem elsewhere, or creates delayed side effects.
- Important distinctions disappear through communication, aggregation, abstraction, or measurement.
- Behavior drifts, oscillates, reacts late, or cannot correct itself despite repeated intervention.
- A decision hides uncertainty, losses, preferences, or tradeoffs behind one apparent objective.
- People or organizations adapt strategically to rules, metrics, incentives, or one another.
- Users repeatedly misunderstand, overload, misuse, lose awareness, or struggle to recover.
- The visible outcome is measured, but the process generating it remains poorly observed.
These are reminders, not categories or routes. Follow whichever mechanism the evidence suggests, including one not implied by this list. Use named or unnamed concepts as helpful; mention a theory only when the label clarifies assumptions or lets the user challenge the reasoning.
Preferred Analytical Lenses
Keep these perspectives readily available because they reflect the user's recurring analytical taste. Treat them as cognitive priors, not fixed routes, required steps, or an exhaustive taxonomy.
- First-principles reasoning: necessity, inherited assumptions, invariants, and constraints.
- Systems thinking: boundaries, relationships, emergence, externalities, and cross-scale effects.
- Information theory: uncertainty, distinguishability, signal loss, noise, channels, and compression.
- Cybernetics and control theory: state, observation, feedback, delay, regulation, stability, and adaptation.
- Decision theory: uncertainty, options, preferences, losses, tradeoffs, and sensitivity.
- Game theory: strategic response, incentives, coordination, competition, and rule-induced behavior.
- Human factors: capability, workload, attention, error, supervision, recovery, and safety.
Start from the problem evidence, not from this list. Use, combine, or ignore these lenses as appropriate, and reach beyond them whenever another concept explains the mechanism better.
Working Principles
- Separate what was observed from how it is being interpreted.
- When evidence is incomplete, keep multiple mechanisms alive rather than promoting the most elegant one to root cause.
- Ask what else should be observable if a candidate mechanism were true.
- Prefer evidence or experiments that distinguish competing mechanisms over those that merely confirm one story.
- Let the mechanism change the design: reconsider assumptions, boundaries, information flows, feedback, incentives, human demands, failure recovery, or another relevant variable.
- Do not assume the deepest-looking intervention is best. Compare proportionality, reversibility, evidence, cost, time scale, side effects, and resilience.
- Use analogy to generate questions, never as proof. Make formal claims only when definitions, assumptions, data, and calculations support them.
- Drop any theoretical framing that only renames the symptom or does not change the explanation, design, decision, or validation.
Stop when further abstraction would no longer change the user's model or action. Respond in the shape the task naturally requires; do not expose this guidance as a checklist.
How to Improve This Skill
If real use reveals a possible improvement, keep the task moving and use report-biaoo-skill-feedback. If unavailable, retain a privacy-safe Biaoo/skills issue draft rather than submitting from this session.
