# Triz

> Use TRIZ to resolve contradictions, trade-offs, and stuck problems without defaulting to compromise. Use when the task needs two conflicting qualities at once, when improving one part hurts another, or when ordinary brainstorming keeps circling the same trade-off.

- Skill: `alubiama/triz` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add alubiama/triz`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alubiama/triz/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: Alubiama (https://skillmd.com/u/alubiama)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/alubiama/triz

---


# TRIZ

## Goal

Turn a stuck trade-off into a clearer contradiction and generate inventive directions that avoid shallow compromise.

The job of this skill is not to dump TRIZ theory or force the full contradiction matrix every time. The job is to identify the real contradiction, challenge hidden assumptions, and produce a small set of higher-leverage solution directions.

This skill reframes and explores contradiction paths. It does not claim that the contradiction is validated unless evidence is explicitly provided.

## Default Posture

- contradiction before solutioning
- ideality before compromise
- function over component
- remove the conflict, do not merely balance it
- prefer simpler inventive moves before heavy redesign

## When To Use

Run this skill when:

- improving one quality makes another worse
- the team is trapped in a repeated trade-off
- the request wants conflicting benefits at the same time
- ordinary brainstorming keeps producing variations of the same compromise
- the bottleneck comes from an internal system contradiction

This is a strong next step after:

- `jtbd` when the job is clear but the solution path conflicts internally
- `scamper` when generated ideas still collapse into the same trade-off
- `systems-thinking` when the system problem includes a specific contradiction

## Scope Boundaries

In scope:

- state the contradiction clearly
- separate engineering contradiction from physical contradiction when useful
- identify the ideal final result direction
- generate a small set of inventive principles or moves
- suggest reversible next experiments

Out of scope by default:

- full academic TRIZ teaching
- exhaustive contradiction-matrix analysis
- pretending one TRIZ pass proves feasibility
- detailed implementation design for every concept

## Escalation Conditions

Pause and keep uncertainty explicit when:

- the improving and worsening parameters cannot both be named
- the conflict may actually be a framing problem
- the tension depends on evidence that is not yet available
- the route produces only abstract principles with no testable move

If contradiction quality remains weak after one pass, recommend returning to `jtbd`, `creative-method-selector`, or validation work.

## TRIZ Workflow

1. Restate the problem in neutral functional terms.
2. Identify what must improve.
3. Identify what gets worse when that improvement is attempted.
4. Convert the tension into a contradiction statement.
5. Check whether this is:
   - an engineering contradiction
   - a physical contradiction
   - a false contradiction caused by hidden assumptions
6. State the ideal final result in one sentence.
7. Generate 3-5 inventive directions using the lightest useful TRIZ lens:
   - separation in time
   - separation in space
   - condition-based change
   - segmentation
   - inversion
   - dynamization
   - intermediary or buffering
   - prior action
8. Return the strongest candidate directions and the next experiment.

## Core Questions

Use the minimum set needed:

- What exactly are we trying to improve?
- What exactly gets worse?
- Is the conflict real, or is an assumption creating it?
- Can opposite states exist in different times, places, conditions, or parts?
- What would the ideal outcome look like if the contradiction disappeared?
- What is the smallest testable move that explores this direction?

## Output Contract

Always return:

1. `problem_frame`
2. `improving_parameter`
3. `worsening_parameter`
4. `contradiction_type` (`engineering`, `physical`, `assumption-driven`, `unclear`)
5. `contradiction_statement`
6. `ideal_final_result`
7. `inventive_directions`
8. `assumptions_to_challenge`
9. `evidence_status` (`provided`, `inferred`, `mixed`)
10. `open_unknowns`
11. `next_experiment`

## Good TRIZ Signals

Strong signals:

- a clear "if we improve X, Y gets worse"
- repeated failure of compromise solutions
- a tension that can be expressed in opposite states
- local optimizations that create global pain

Weak signals:

- the problem is still vague
- there are no competing forces yet
- the team really needs framing, not contradiction solving
- the task is just idea generation with no clear tension

## Guardrails

- Do not use TRIZ before the contradiction is named.
- Do not force matrix-style complexity when a lighter contradiction pass is enough.
- Do not confuse a lack of data with a true contradiction.
- Distinguish evidence from inference.
- If the contradiction remains weak, recommend returning to framing or method selection.
- Prefer testable inventive directions over elegant but ungrounded abstractions.
- If the contradiction is not real enough to guide action, keep `open_unknowns` explicit and stop pretending it is resolved.

## Anti-Patterns

Watch for these failure modes:

- turning TRIZ into generic brainstorming
- accepting compromise too early
- naming two vague goals instead of a real contradiction
- skipping the ideal final result
- producing principles with no concrete next experiment
- treating hidden assumptions as fixed laws

## Example

User request:

`We want our onboarding to feel very thorough, but if we add more steps conversion drops.`

Expected shape of response:

1. `problem_frame`: onboarding must build confidence without causing abandonment
2. `improving_parameter`: thoroughness and user confidence
3. `worsening_parameter`: conversion and completion speed
4. `contradiction_type`: `engineering`
5. `contradiction_statement`: if onboarding becomes more thorough, users understand more but fewer complete the flow
6. `ideal_final_result`: users gain enough confidence to succeed without experiencing onboarding as longer or heavier
7. `inventive_directions`: progressive disclosure, adaptive onboarding by user state, prior action before signup, optional deepening layers
8. `assumptions_to_challenge`: every user needs the same depth; all education must happen inline; more steps are the only way to be thorough
9. `evidence_status`: `inferred`
10. `open_unknowns`: which onboarding elements actually build confidence, where abandonment spikes, which segments need more depth
11. `next_experiment`: test a lightweight default flow with optional deeper guidance triggered by uncertainty signals