Get the FREE Ultimate OpenClaw Setup Guide →

progressive-loading

Scanned
npx machina-cli add skill athola/claude-night-market/progressive-loading --openclaw
Files (1)
SKILL.md
6.7 KB

Table of Contents

Progressive Loading Patterns

Overview

Progressive loading provides standardized patterns for building skills that load modules dynamically based on context, user intent, and available token budget. This prevents loading unnecessary content while ensuring required functionality is available when needed.

The core principle: Start minimal, expand intelligently, monitor continuously.

When To Use

Use progressive loading when building skills that:

  • Cover multiple distinct workflows or domains
  • Need to manage context window efficiently
  • Have modules that are mutually exclusive based on context
  • Require MECW compliance for long-running sessions
  • Want to optimize for common paths while supporting edge cases

When NOT To Use

  • Project doesn't use the leyline infrastructure patterns
  • Simple scripts without service architecture needs

Quick Start

Basic Hub Pattern

## Progressive Loading

**Context A**: Load `modules/loading-patterns.md` for scenario A
**Context B**: Load `modules/selection-strategies.md` for scenario B

**Always Available**: Core utilities, exit criteria, integration points

Verification: Run the command with --help flag to verify availability.

Context-Based Selection

from leyline import ModuleSelector, MECWMonitor

selector = ModuleSelector(skill_path="my-skill/")
modules = selector.select_modules(
    context={"intent": "git-catchup", "artifacts": ["git", "python"]},
    max_tokens=MECWMonitor().get_safe_budget()
)

Verification: Run the command with --help flag to verify availability.

Hub-and-Spoke Architecture

Hub Responsibilities

  1. Context Detection: Identify user intent, artifacts, workflow type
  2. Module Selection: Choose which modules to load based on context
  3. Budget Management: Verify MECW compliance before loading
  4. Integration Coordination: Provide integration points with other skills
  5. Exit Criteria: Define completion criteria across all paths

Spoke Characteristics

  1. Single Responsibility: Each module serves one workflow or domain
  2. Self-Contained: Modules don't depend on other modules
  3. Context-Tagged: Clear indicators of when module applies
  4. Token-Budgeted: Known token cost for selection decisions
  5. Independently Testable: Can be evaluated in isolation

Selection Strategies

See modules/selection-strategies.md for detailed strategies:

  • Intent-based: Load based on detected user goals
  • Artifact-based: Load based on detected files/systems
  • Budget-aware: Load within available token budget
  • Progressive: Load core first, expand as needed
  • Mutually-exclusive: Load one path from multiple options

Loading Patterns

See modules/loading-patterns.md for implementation patterns:

  • Conditional includes: Dynamic module references
  • Lazy loading: Load on first use
  • Tiered disclosure: Core → common → edge cases
  • Context switching: Change loaded modules mid-session
  • Preemptive unloading: Remove unused modules under pressure

Common Use Cases

  • Multi-Domain Skills: imbue:catchup loads git/docs/logs modules by context
  • Context-Heavy Analysis: Load relevant modules only, defer deep-dives, unload completed
  • Plugin Infrastructure: Mix-and-match infrastructure modules with version checks

Best Practices

  1. Design Hub First: Define all possible contexts and module boundaries
  2. Tag Modules Clearly: Use YAML frontmatter to indicate context triggers
  3. Measure Token Cost: Know the cost of each module for selection
  4. Monitor Loading: Track which modules are actually used
  5. Validate Paths: Verify all context paths have required modules
  6. Document Triggers: Make context detection logic transparent

Module References

  • Selection Strategies: See modules/selection-strategies.md for choosing modules
  • Loading Patterns: See modules/loading-patterns.md for implementation techniques
  • Performance Budgeting: See modules/performance-budgeting.md for token budget model and optimization workflow

Integration with Other Skills

This skill provides foundational patterns referenced by:

  • abstract:modular-skills - Uses progressive loading for skill design
  • conserve:context-optimization - Uses for MECW-compliant loading
  • imbue:catchup - Uses for context-based module selection
  • Plugin authors building multi-workflow skills

Reference in your skill's frontmatter:

dependencies: [leyline:progressive-loading, leyline:mecw-patterns]
progressive_loading: true

Verification: Run the command with --help flag to verify availability.

Exit Criteria

  • Hub clearly defines all module loading contexts
  • Each module is tagged with activation context
  • Module selection respects MECW constraints
  • Token costs measured for all modules
  • Context detection logic documented
  • Loading paths validated for completeness

Troubleshooting

Common Issues

Command not found Ensure all dependencies are installed and in PATH

Permission errors Check file permissions and run with appropriate privileges

Unexpected behavior Enable verbose logging with --verbose flag

Source

git clone https://github.com/athola/claude-night-market/blob/master/plugins/leyline/skills/progressive-loading/SKILL.mdView on GitHub

Overview

Progressive loading standardizes dynamic module loading based on context, user intent, and a token budget. It starts minimal, expands intelligently, and monitors performance to ensure MECW compliance in long-running sessions, using a hub to coordinate context-driven module selection and on-demand loading.

How This Skill Works

At runtime, a Hub detects context signals (intent, artifacts, workflow type) and uses ModuleSelector to pick relevant modules. MECWMonitor enforces a safe token budget before loading, ensuring compliance, while spokes remain self-contained and context-tagged so only applicable modules are loaded on demand.

When to Use It

  • When building skills with multiple distinct workflows or domains
  • When you need to manage the context window efficiently
  • When modules are mutually exclusive based on context
  • When long-running sessions require MECW compliance
  • When you want to optimize for common paths while supporting edge cases

Quick Start

  1. Step 1: Identify context signals and wire up Hub, ModuleSelector, and MECWMonitor.
  2. Step 2: Use selector.select_modules(context, max_tokens=budget) to choose relevant modules.
  3. Step 3: Load the selected modules on-demand and verify functionality with a quick test (e.g., --help).

Best Practices

  • Define clear context signals and thresholds for module loading.
  • Keep spokes self-contained with single responsibility for each module.
  • Tag modules with context indicators and token costs for accurate selection.
  • Validate budgets before each load and monitor token usage continuously.
  • Test module-loading in isolation and verify integration in real scenarios.

Example Use Cases

  • A chat assistant uses Context A to load modules/loading-patterns.md for a specific workflow and Context B to load modules/selection-strategies.md for another workflow.
  • A git-catchup workflow loads the relevant code/docs modules based on detected user intent and artifacts.
  • A multi-domain helpdesk loads domain-specific modules only when the user's context matches that domain.
  • A coding assistant selects modules based on detected language and tooling to optimize token usage.
  • An MECW-aware session loads specialized modules on demand, staying within the safe token budget.

Frequently Asked Questions

Add this skill to your agents

Related Skills

Sponsor this space

Reach thousands of developers