TRIZ Oracle
The contradiction test
"If I make it more X, it becomes less Y." If yes — TRIZ applies.
If not a genuine tension, use a different tool (see below).
Workflow
Copy this checklist and check off as you go:
Contradiction Analysis:
- [ ] 1. State the contradiction: "improving X worsens Y"
- [ ] 2. Map to TRIZ parameters — see [parameters.md](parameters.md)
- [ ] 3. Run: script/solve.nu "X" "Y"
- [ ] 4. Review recommended principles — see [principles.md](principles.md)
- [ ] 5. Apply: write the specific solution using the best principle
- [ ] 6. Verify: does it actually resolve the tension without introducing a worse one?
Feedback loop:
- Contradiction unclear → run
script/whys.nu first
- Parameter must be X AND not-X simultaneously → use references/physical_contradictions.md instead of the matrix
- Empty matrix cell → reframe the parameters; see references/examples.md for analogies
- Principle doesn't fit the domain → try the next one in the recommendation list
- None fit → run
script/fmea.nu PRINCIPLE_ID to understand failure modes
- Contradiction keeps recurring → check references/evolution_trends.md — may be structural
- Unsure how deep to search → check references/innovation_levels.md first
Scripts
| Script |
Use |
script/solve.nu "X" "Y" |
Matrix lookup + principle application |
script/solve.nu "X" "Y" -c "context" |
With situational context |
script/solve.nu "X" "Y" --json |
Machine-readable output |
script/whys.nu |
5 Whys drill → articulate contradiction interactively |
script/whys.nu --json |
Whys output with ready solve_cmd field |
script/fmea.nu 35 |
Failure mode analysis for principle 35 |
script/fmea.nu --stdin |
Pipe from script/solve.nu --json |
script/lookup.nu "speed" |
Find matching parameter by keyword |
script/lookup.nu --principle 35 |
Explain a principle |
Scripts are executable (chmod +x). Run from the skill directory or by full path.
Core architectural rule
The matrix lookup is always first. LLM applies the principle after lookup.
Never ask the LLM to classify the contradiction before the lookup.
Quick reference — top principles for software
| # |
Principle |
Software pattern |
| 1 |
Segmentation |
Microservices, feature flags, namespaces |
| 2 |
Extraction |
Separate config from code; pure functions |
| 5 |
Combining |
Batch operations; co-location |
| 6 |
Universality |
One format, many consumers (e.g. Iceberg) |
| 10 |
Preliminary action |
Schema migrations before deploys; pre-warming |
| 13 |
Inversion |
Pull not push; reactive not polling |
| 15 |
Dynamics |
Adaptive timeouts; circuit breakers |
| 23 |
Feedback |
Observability gates; acceptance criteria in spec |
| 24 |
Intermediary |
Message queues; API gateways |
| 25 |
Self-service |
Self-healing systems; auto-remediation |
| 35 |
Parameter changes |
Feature flags; runtime configuration |
| 40 |
Composite materials |
Tiered storage; hybrid consistency models |
Common software contradictions — cheatsheet
Real matrix cell values. Use when triz binary is unavailable.
Format: improving → worsening: principles (in priority order)
| Improving |
Worsening |
Principles |
Key idea |
| Speed (9) |
Reliability (27) |
11, 35, 27, 28 |
Cushion; param change; copy of object |
| Speed (9) |
System complexity (36) |
10, 28, 4, 34 |
Preliminary action; copies; discard/recover |
| Speed (9) |
Build/test time (32) |
12, 36, 18, 31 |
Equipotentiality; phase change; thermal expansion |
| Speed (9) |
Automation coverage (38) |
13, 35, 8, 1 |
Inversion; param change; anti-weight; segmentation |
| Reliability (27) |
Adaptability (35) |
3, 35, 10, 40 |
Local quality; param change; prelim action; composite |
| Reliability (27) |
Build time (32) |
35, 3, 22, 39 |
Param change; local quality; convert harm to benefit |
| Automation (38) |
Reliability (27) |
11, 2, 13, 39 |
Cushion; extraction; inversion; pneumatic/hydraulic |
| Automation (38) |
System complexity (36) |
35, 28, 6, 37 |
Param change; copies; universality; thermal expansion |
| Adaptability (35) |
System complexity (36) |
24, 26, 28, 18 |
Intermediary; copying; copies; mediation |
| System complexity (36) |
Reliability (27) |
1, 24, 6, 35 |
Segmentation; intermediary; universality; param change |
| Ease of operation (33) |
System complexity (36) |
35, 1, 3, 24 |
Param change; segmentation; local quality; intermediary |
| Observability (18) |
System complexity (36) |
2, 35 |
Extraction; param change |
How to read: improving Speed while worsening Reliability → try P11 (Cushion/Beforehand compensation) first, then P35 (Parameter changes), etc.
Without the binary: look up the improving/worsening pair above, then read the principle definition from references/principles.md.
References (load on demand)
| File |
Load when |
| references/principles.md |
Need full 40 principles with approach/sub-principles |
| references/parameters.md |
Need full 39 parameters to map a concept |
| references/examples.md |
Need domain analogies for an empty matrix cell |
| references/physical_contradictions.md |
Parameter must be X AND not-X simultaneously |
| references/evolution_trends.md |
Contradiction keeps recurring; predicting next bottleneck |
| references/innovation_levels.md |
Calibrating search depth; setting expectations |
When TRIZ does not apply
| Situation |
Better tool |
| Merge conflict |
Understand semantic intent; resolve manually |
| Which library to use |
Capability matrix comparison |
| Bug in code |
Systematic debugging; read the error |
| Naming |
User research; naming criteria checklist |
| Priority between features |
Planning poker; value/effort matrix |
| Two options, no tension |
Just pick one |
1---2name: triz3description: TRIZ contradiction matrix oracle for software and systems design. Use when improving one quality worsens another — speed vs correctness, isolation vs sharing, autonomy vs control, simplicity vs completeness. Trigger phrases: "tradeoff", "tension between", "can't have both", "worsens when", "at the cost of", "faster but less reliable", "more isolated but harder to share". Not for bugs, merge conflicts, or tool choices. Prerequisite: triz binary must be installed (run `triz doctor` to verify).4---56# TRIZ Oracle78## The contradiction test910"If I make it more X, it becomes less Y." If yes — TRIZ applies.11If not a genuine tension, use a different tool (see below).1213## Workflow1415Copy this checklist and check off as you go:1617```18Contradiction Analysis:19- [ ] 1. State the contradiction: "improving X worsens Y"20- [ ] 2. Map to TRIZ parameters — see [parameters.md](parameters.md)21- [ ] 3. Run: script/solve.nu "X" "Y"22- [ ] 4. Review recommended principles — see [principles.md](principles.md)23- [ ] 5. Apply: write the specific solution using the best principle24- [ ] 6. Verify: does it actually resolve the tension without introducing a worse one?25```2627**Feedback loop:**28- Contradiction unclear → run `script/whys.nu` first29- Parameter must be X AND not-X simultaneously → use [references/physical_contradictions.md](references/physical_contradictions.md) instead of the matrix30- Empty matrix cell → reframe the parameters; see [references/examples.md](references/examples.md) for analogies31- Principle doesn't fit the domain → try the next one in the recommendation list32- None fit → run `script/fmea.nu PRINCIPLE_ID` to understand failure modes33- Contradiction keeps recurring → check [references/evolution_trends.md](references/evolution_trends.md) — may be structural34- Unsure how deep to search → check [references/innovation_levels.md](references/innovation_levels.md) first3536## Scripts3738| Script | Use |39|--------|-----|40| `script/solve.nu "X" "Y"` | Matrix lookup + principle application |41| `script/solve.nu "X" "Y" -c "context"` | With situational context |42| `script/solve.nu "X" "Y" --json` | Machine-readable output |43| `script/whys.nu` | 5 Whys drill → articulate contradiction interactively |44| `script/whys.nu --json` | Whys output with ready `solve_cmd` field |45| `script/fmea.nu 35` | Failure mode analysis for principle 35 |46| `script/fmea.nu --stdin` | Pipe from `script/solve.nu --json` |47| `script/lookup.nu "speed"` | Find matching parameter by keyword |48| `script/lookup.nu --principle 35` | Explain a principle |4950Scripts are executable (`chmod +x`). Run from the skill directory or by full path.5152## Core architectural rule5354The matrix lookup is always first. LLM applies the principle after lookup.55Never ask the LLM to classify the contradiction before the lookup.5657## Quick reference — top principles for software5859| # | Principle | Software pattern |60|---|-----------|-----------------|61| 1 | Segmentation | Microservices, feature flags, namespaces |62| 2 | Extraction | Separate config from code; pure functions |63| 5 | Combining | Batch operations; co-location |64| 6 | Universality | One format, many consumers (e.g. Iceberg) |65| 10 | Preliminary action | Schema migrations before deploys; pre-warming |66| 13 | Inversion | Pull not push; reactive not polling |67| 15 | Dynamics | Adaptive timeouts; circuit breakers |68| 23 | Feedback | Observability gates; acceptance criteria in spec |69| 24 | Intermediary | Message queues; API gateways |70| 25 | Self-service | Self-healing systems; auto-remediation |71| 35 | Parameter changes | Feature flags; runtime configuration |72| 40 | Composite materials | Tiered storage; hybrid consistency models |7374## Common software contradictions — cheatsheet7576Real matrix cell values. Use when `triz` binary is unavailable.77Format: **improving → worsening**: principles (in priority order)7879| Improving | Worsening | Principles | Key idea |80|-----------|-----------|-----------|----------|81| Speed (9) | Reliability (27) | 11, 35, 27, 28 | Cushion; param change; copy of object |82| Speed (9) | System complexity (36) | 10, 28, 4, 34 | Preliminary action; copies; discard/recover |83| Speed (9) | Build/test time (32) | 12, 36, 18, 31 | Equipotentiality; phase change; thermal expansion |84| Speed (9) | Automation coverage (38) | 13, 35, 8, 1 | Inversion; param change; anti-weight; segmentation |85| Reliability (27) | Adaptability (35) | 3, 35, 10, 40 | Local quality; param change; prelim action; composite |86| Reliability (27) | Build time (32) | 35, 3, 22, 39 | Param change; local quality; convert harm to benefit |87| Automation (38) | Reliability (27) | 11, 2, 13, 39 | Cushion; extraction; inversion; pneumatic/hydraulic |88| Automation (38) | System complexity (36) | 35, 28, 6, 37 | Param change; copies; universality; thermal expansion |89| Adaptability (35) | System complexity (36) | 24, 26, 28, 18 | Intermediary; copying; copies; mediation |90| System complexity (36) | Reliability (27) | 1, 24, 6, 35 | Segmentation; intermediary; universality; param change |91| Ease of operation (33) | System complexity (36) | 35, 1, 3, 24 | Param change; segmentation; local quality; intermediary |92| Observability (18) | System complexity (36) | 2, 35 | Extraction; param change |9394**How to read:** improving Speed while worsening Reliability → try P11 (Cushion/Beforehand compensation) first, then P35 (Parameter changes), etc.9596**Without the binary:** look up the improving/worsening pair above, then read the principle definition from [references/principles.md](references/principles.md).9798## References (load on demand)99100| File | Load when |101|------|-----------|102| [references/principles.md](references/principles.md) | Need full 40 principles with approach/sub-principles |103| [references/parameters.md](references/parameters.md) | Need full 39 parameters to map a concept |104| [references/examples.md](references/examples.md) | Need domain analogies for an empty matrix cell |105| [references/physical_contradictions.md](references/physical_contradictions.md) | Parameter must be X AND not-X simultaneously |106| [references/evolution_trends.md](references/evolution_trends.md) | Contradiction keeps recurring; predicting next bottleneck |107| [references/innovation_levels.md](references/innovation_levels.md) | Calibrating search depth; setting expectations |108109## When TRIZ does not apply110111| Situation | Better tool |112|-----------|-------------|113| Merge conflict | Understand semantic intent; resolve manually |114| Which library to use | Capability matrix comparison |115| Bug in code | Systematic debugging; read the error |116| Naming | User research; naming criteria checklist |117| Priority between features | Planning poker; value/effort matrix |118| Two options, no tension | Just pick one |
ryanmaclean