early-filter-optimization
A performance optimization principle focused on filtering or pruning data and tasks as early as possible to save resources.
Install
mkdir -p .claude/skills/early-filter-optimization && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/15349" && unzip -o skill.zip -d .claude/skills/early-filter-optimization && rm skill.zipInstalls to .claude/skills/early-filter-optimization
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Cross-domain early-filtering paradigm for reducing cognitive and computational load in data pipelines, AI context, and human attentionKey capabilities
- →Reduce data processing by filtering early
- →Optimize SQL queries with pre-filtering
- →Improve Spark performance with predicate pushdown
- →Reduce API bandwidth with field selection
- →Manage AI context by loading on trigger
- →Defer computation until needed
How it works
This skill applies the principle of early filtering to reduce cognitive and computational load by processing only necessary data and respecting system readiness.
Inputs & outputs
When to use early-filter-optimization
- →Optimizing SQL performance
- →Reducing AI context load
- →Improving pipeline efficiency
About this skill
Domain Knowledge: Early Filter Optimization
Domain: Cross-Domain Performance Optimization Mastery Level: Applied (Real-world validation) Created: 2026-01-22 Updated: 2026-01-22 Source: Meditation consolidation from SQL optimization + architecture streamlining session
Core Principles
1. Early Filtering
"Don't process what you don't need. Filter early, load lazy, prune aggressively."
This principle emerged from parallel optimization work in data engineering and cognitive architecture, revealing universal applicability.
2. System Readiness (Added 2026-01-22 Evening)
"Don't race the system. Respect its readiness. When in doubt, stage and wait."
Complements Early Filtering by addressing temporal boundaries rather than data boundaries.
| Principle | Focus | Question |
|---|---|---|
| Early Filter | Data boundaries | What to process? |
| System Readiness | Temporal boundaries | When to proceed? |
Pattern: The Early Filter Paradigm
Manifestations Across Domains
| Domain | Anti-Pattern | Optimized Pattern | Improvement |
|---|---|---|---|
| SQL/Data | Full table scan, filter after | CTE pre-filter, join reduced set | 99%+ reduction |
| Spark | Load all data, filter in memory | Predicate pushdown, partition pruning | Order of magnitude |
| API Design | Return all fields, paginate client-side | Field selection, server pagination | Bandwidth + latency |
| AI Context | Load all instruction files always | Scope with applyTo, load on trigger | Reduced token overhead |
| Human Attention | Try to hold everything in mind | Externalize, reference on demand | Cognitive capacity |
Implementation Strategies
- Push Filters Down: Move WHERE clauses into joins, use partition keys
- Scope Activation: Use patterns/triggers instead of global loading
- Lazy Evaluation: Don't compute until value is actually needed
- Reference vs. Copy: Point to source rather than duplicating content
Case Study: UDP Commercial Query (2026-01-22)
Before
-- CTE joins against 18M row dimension table
LEFT JOIN vwDimServiceOfferingMaster so -- 18,094,691 rows
ON sr.ServiceOfferingMasterKey = so.ServiceOfferingMasterKey
After
-- Pre-filter dimension to only relevant keys
WITH CTE_UsedServiceOfferings AS (
SELECT DISTINCT ServiceOfferingMasterKey
FROM vwFactSupportServiceRequest
WHERE ClosedTimeKey >= 20240101 -- Only 2,474 unique keys used
)
-- Then join against filtered set
LEFT JOIN CTE_FilteredServiceOffering so
ON sr.ServiceOfferingMasterKey = so.ServiceOfferingMasterKey
Result: 7,300x reduction in dimension rows scanned
Case Study: Copilot Instruction Files (2026-01-22)
Before
# In each .instructions.md file
applyTo: "**/*" # Loaded in EVERY conversation
After
# No applyTo - files read only when triggered
description: "..." # Available but not auto-loaded
Result: 13 files removed from default context, loaded only via trigger keywords in main copilot-instructions.md
Applicability Checklist
When optimizing any system, ask:
- What is the smallest necessary input? (Filter early)
- What can be deferred? (Lazy load)
- What is duplicated unnecessarily? (Reference instead)
- What never gets used? (Prune aggressively)
- Where is the bottleneck? (Focus optimization there)
When not to use it
- →When the system's readiness is not a factor
- →When the data boundaries are not relevant for optimization
- →When the goal is to process all available data
Limitations
- →The skill focuses on reducing load through filtering and readiness checks
- →The skill does not address all types of performance bottlenecks
- →The skill requires identifying data and temporal boundaries
How it compares
This skill systematically applies early filtering and system readiness principles across diverse domains, unlike ad-hoc optimization efforts.
Compared to similar skills
early-filter-optimization side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| early-filter-optimization (this skill) | 0 | 3mo | No flags | Intermediate |
| spark-optimization | 4 | 2mo | No flags | Advanced |
| clickhouse-io | 6 | 4mo | Review | Advanced |
| data-engineering | 0 | 8mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by fabioc-aloha
View all by fabioc-aloha →You might also like
spark-optimization
wshobson
Optimize Apache Spark jobs with partitioning, caching, shuffle optimization, and memory tuning. Use when improving Spark performance, debugging slow jobs, or scaling data processing pipelines.
clickhouse-io
affaan-m
ClickHouse database patterns, query optimization, analytics, and data engineering best practices for high-performance analytical workloads.
data-engineering
mazelb
|
caching-strategies
dadbodgeoff
Implement multi-layer caching with Redis, in-memory, and HTTP caching. Covers cache invalidation, stampede prevention, and cache-aside patterns.
find-hypertable-candidates
timescale
Use this skill to analyze an existing PostgreSQL database and identify which tables should be converted to Timescale/TimescaleDB hypertables. **Trigger when user asks to:** - Analyze database tables for hypertable conversion potential - Identify time-series or event tables in an existing schema - Evaluate if a table would benefit from Timescale/TimescaleDB - Audit PostgreSQL tables for migration to Timescale/TimescaleDB/TigerData - Score or rank tables for hypertable candidacy **Keywords:** hypertable candidate, table analysis, migration assessment, Timescale, TimescaleDB, time-series detection, insert-heavy tables, event logs, audit tables Provides SQL queries to analyze table statistics, index patterns, and query patterns. Includes scoring criteria (8+ points = good candidate) and pattern recognition for IoT, events, transactions, and sequential data.
design
Hainrixz
Greenfield database design — pick the right engine for a new project, compare it against the boring default, and hand back a starter data model with a diagram. Recommendation mode (module M0); never scored, never destructive. Use when the user is starting fresh and asks what database to use, how to