System Overview
Proxy Pattern Architecture
RTK uses a command proxy architecture that sits between the user and underlying CLI tools:Key Components
Design Principles
- Single Responsibility: Each module handles one command type
- Minimal Overhead: ~5-15ms proxy overhead per command
- Exit Code Preservation: CI/CD reliability through proper exit code propagation
- Fail-Safe: If filtering fails, fall back to original output
- Transparent: Users can always see raw output with
-vflags
Command Lifecycle
Six-Phase Execution Flow
1
PARSE
Clap parser extracts command, arguments, and global flags:
2
ROUTE
Main.rs matches the command enum and routes to the appropriate module:
3
EXECUTE
Module executes the underlying command and captures output:
4
FILTER
Module applies filtering strategy based on command type:
5
Filtered output is displayed to the user:
6
TRACK
Token savings are recorded in SQLite database:
Verbosity Levels
Module Organization
Module Categories
RTK has 51 total modules organized into categories:Command Module Pattern
Each command module follows a standard pattern:Filtering Strategies
Strategy Matrix
RTK uses 12 different filtering strategies optimized for different output types:1. Stats Extraction (90-99% reduction)
2. Error Only (60-80% reduction)
3. Grouping by Pattern (80-90% reduction)
4. Deduplication (70-85% reduction)
5. Structure Only (80-95% reduction)
6. Code Filtering (20-90% reduction)
7. Failure Focus (94-99% reduction)
8-12. Additional Strategies
- Tree Compression (ls): Flat list → hierarchy (50-70%)
- Progress Filtering (wget, pnpm): Strip ANSI bars (85-95%)
- JSON/Text Dual Mode (ruff, pip): JSON when available (80%+)
- State Machine Parsing (pytest): Track test state (90%+)
- NDJSON Streaming (go test): Line-by-line JSON (90%+)
See ARCHITECTURE.md lines 308-413 for detailed filtering strategy descriptions with visual diagrams.
Core Design Patterns
1. Package Manager Detection (JS/TS modules)
- Preserves CWD correctly
- Works in monorepo structures
- Uses project-local dependencies
- Consistent CI/CD behavior
2. Lazy Static Regex
3. Exit Code Preservation
Token Tracking System
RTK tracks token savings in a SQLite database:Token Estimation
Automatic Cleanup
HISTORY_DAYS constant)
Configuration System
Two-Tier Configuration
-
User Settings (
~/.config/rtk/config.toml) -
LLM Integration (
CLAUDE.md)- Global:
~/.config/rtk/CLAUDE.md - Local:
./CLAUDE.md(project-specific) - Created by:
rtk init [--global]
- Global:
Performance Characteristics
Targets
Optimizations
- Zero async overhead: Single-threaded, no tokio
- Lazy regex compilation: Compile once, reuse forever
- Minimal allocations: Borrow over clone
- No startup I/O: Config loaded on-demand
- LTO + strip: Link-time optimization + symbol stripping
Error Handling
RTK usesanyhow::Result<()> for error propagation:
- Always use
.context("description")with? - Never use
.unwrap()in production code - Graceful degradation: If filter fails, fallback to raw command
- Preserve exit codes for CI/CD reliability
Next Steps
- Building RTK - Build from source
- Testing Guide - Testing strategy and TDD workflow
- Adding Commands - Implement new filters
