TRIZ Analysis — Rust Edition

Systematic innovation audit for Rust codebases, workspace architectures, and CI/CD pipelines.

Input Requirements

• Target Scope: The specific directory, pipeline, or framework to analyze (e.g., crates/, scripts/, .github/workflows/, agent-coordination).
• Language Focus: Rust-specific patterns (ownership, async, traits, lifetimes).

Output Convention

All agent-generated analysis must be written to analysis/ using:

analysis/triz-<scope>-YYYY-MM-DD.md

Example: analysis/triz-scripts-2026-06-18.md

Audit Process

1. SCOPE SCAN: Examine the target scope for existing pain points or trade-offs.
2. CONTRADICTION DISCOVERY: Identify technical contradictions: "Improving [X] in this scope causes [Y] to worsen."
3. PRINCIPLE MAPPING: Map discovered contradictions to TRIZ inventive principles.
4. INNOVATION ROADMAP: Propose specific Rust-idiomatic changes based on TRIZ resolutions.
5. REPORT: Document findings in analysis/.

Core Protocol

Contradiction-First Approach

1. SCAN the scope
2. IDENTIFY contradiction: "Improving [X] causes [Y] to worsen"
3. CHECK if contradiction is real or apparent
4. RESOLVE using separation principles
5. DOCUMENT findings in analysis/

Ideal Final Result (IFR) for Rust Audits

"The ideal Rust system performs its function with minimal unsafe code, unnecessary cloning, and contention"

1. What is the ideal outcome for this scope?
2. What prevents reaching it? (current type/ownership/CI constraints)
3. Which constraints are real vs assumed?
4. Could the borrow checker enforce correctness instead of runtime checks?

Contradiction Matrix (Rust-Specific)

Tokio-Specific Audit Rules

When auditing async Rust, do not treat spawn_blocking as a universal optimization. Determine whether work is blocking, short bounded CPU work, sustained CPU work, or latency-sensitive. Consider scheduler fairness, coordination overhead, blocking-pool pressure, batching, and isolation.

Check for:

• unbounded tokio::spawn fan-out
• queues without deliberate backpressure
• locks held across .await
• expensive work while holding a lock
• repeatedly-ready loops that monopolize workers
• fragmented small I/O operations
• claims of performance without representative benchmarks

For detailed Tokio performance guidance, invoke the tokio-performance skill.

Software Contradiction Matrix (General)

Separation Principles (Rust Mapping)

Integration with Other Skills

• tokio-performance: Apply for Tokio scheduling, fairness, contention, blocking, and bounded-concurrency analysis.
• agent-coordination: Orchestrate as a swarm sub-task where multiple agents analyze different crates or pipelines in parallel.
• task-decomposition: Use to break a large workspace audit into smaller scoped TRIZ analyses.
• anti-ai-slop: Apply after TRIZ resolutions to keep the rewrite idiomatic and not boilerplate-heavy.

Quality Checklist

• Target scope clearly defined
• Discovered contradictions explicitly stated
• Recommendations mapped to TRIZ inventive principles
• Rust-idiomatic pattern suggested (not just generic advice)
• Findings saved to analysis/triz-<scope>-YYYY-MM-DD.md
• Async recommendations are workload-aware rather than cargo-cult patterns

Rationalizations

Red Flags

• Skipping the contradiction statement and jumping straight to solutions
• Defining contradictions too vaguely to map to specific principles
• Not saving findings to analysis/ as specified
• Proposing non-idiomatic Rust or speculative optimization without measurement
• Treating spawn_blocking, yield_now, locks, or extra runtimes as universal performance fixes

Reference Files

• The Rust Performance Book
• Rust API Guidelines
• Tokio tutorial
• Principles for Fast Tokio Applications

Related Skills

• tokio-performance - Tokio scheduling, fairness, contention, blocking, I/O, and concurrency audits
• triz-solver - Apply TRIZ principles to solve specific problems
• task-decomposition - Break audits into scoped sub-tasks
• goap-agent - Use TRIZ in Phase 1 (Analyze) of GOAP
• anti-ai-slop - Audit rewritten code for boilerplate and over-abstraction