skills/resource-bounded-planning/SKILL.md
Frameworks for designing agents that must reason and act under time pressure, limited computational resources, and changing environments — based on Bratman, Israel, and Pollack's foundational BDI architecture
npx skillsauth add curiositech/windags-skills resource-bounded-planningInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Design and implement agents that balance deliberation depth against execution urgency — making "good enough" decisions under time pressure while maintaining adaptability to change.
IF: Domain has recurring decisions + Time pressure exists + Information is incomplete
├─ High uncertainty about environment changes
│ └─ Commit to high-level structure only (defer implementation details)
├─ Moderate uncertainty with recurring patterns
│ └─ Commit to partial plan with 2-3 refinement checkpoints
└─ Low uncertainty with established patterns
└─ Commit to detailed plan with monitoring triggers
Cost-Benefit Formula: Commit when (Expected_Deliberation_Savings × Recurrence_Rate) > (Revision_Cost × Uncertainty_Factor)
IF: New incompatible option detected
├─ Expected value > Current plan value + (Override_threshold × Deliberation_cost)
│ └─ TRIGGER: Begin costly reconsideration
├─ Expected value > Current plan value but < Override threshold
│ └─ FILTER: Log opportunity but maintain current commitment
└─ Expected value ≤ Current plan value
└─ FILTER: Ignore option completely
Target Override Frequency: 10-20% of detected options (adjust threshold accordingly)
IF: Planning horizon analysis needed
├─ Execution time < 24 hours
│ └─ Specify to action level (full detail required)
├─ Execution time 1-30 days
│ └─ Specify to task level (keep method flexibility)
├─ Execution time > 30 days
│ └─ Specify to goal level only (maximum adaptability)
Refinement Trigger: When means-end coherence gap blocks next action OR dependency requires specification
IF: Agent coordination required
├─ Shared resource conflicts detected
│ └─ Negotiate commitment revision (cost = deliberation + coordination overhead)
├─ Goal conflicts detected but no resource overlap
│ └─ Maintain separate commitments with monitoring
└─ Complementary goals detected
└─ Establish consistency constraints (shared assumptions + checkpoint synchronization)
Consistency Check Frequency: Every N actions where N = 1/(Coordination_criticality × Change_rate)
Detection Rule: If deliberation time > 2× action time OR override frequency > 30% of options Symptoms: Constantly reconsidering plans, thrashing between options, missing deadlines Diagnosis: Override threshold too low, filter mechanism too weak Fix: Increase override threshold by 20-30%, strengthen filter criteria, set hard deliberation deadlines
Detection Rule: If plan execution fails due to assumption violations > 2× per planning cycle Symptoms: Missing significant opportunities, executing invalid plans, inflexible to change Diagnosis: Override threshold too high, monitoring inadequate Fix: Decrease override threshold by 15-25%, add assumption monitoring, implement adaptation triggers
Detection Rule: If plan details change > 40% before execution OR refinement cost > initial planning cost Symptoms: Wasted computation on obsolete details, reduced flexibility, high revision overhead Diagnosis: Committing to unnecessary detail too early Fix: Defer specification until means-end coherence requires OR execution approaches
Detection Rule: If coordination overhead > 25% of productive work time Symptoms: Agents constantly negotiating, inconsistent assumptions across agents, deadlock states Diagnosis: Consistency requirements too strict OR communication protocols inefficient Fix: Relax non-critical consistency constraints, implement local consistency checking, batch coordination updates
Detection Rule: If deliberation cost exceeds action value for same decision type > 3 consecutive times Symptoms: Over-analyzing low-stakes decisions, missing action windows, computational resource waste Diagnosis: Treating all decisions as equally important Fix: Implement decision importance classification, set deliberation budgets per decision class, use satisficing for low-stakes choices
Scenario: Three AI agents managing a data center during peak load. Agent A (scheduler), Agent B (resource allocator), Agent C (performance monitor). Sudden 300% traffic spike detected.
Novice Approach: Each agent recomputes optimal strategy independently
Expert Application:
Commitment Formation (T+2 seconds):
Consistency Check (T+3 seconds):
Execution with Refinement (T+4 to T+600):
Override Decision (T+300):
Measurable Outcomes:
Scenario: AI coding assistant planning implementation of new feature. Requirements partially specified, 2-week deadline, dependencies uncertain.
Trade-off Analysis:
Option 1: Fully specify all implementation details upfront
Option 2: Commit only to architecture, defer all implementation
Expert Choice - Option 3: Structural partiality with refinement triggers
Execution:
T+0: Form partial plan (4 hours)
T+3 days: First refinement trigger
T+8 days: Performance monitoring trigger
Quality Results:
Planning Quality Checklist:
Execution Quality Checklist:
Calibration Quality Indicators:
This skill is NOT for:
Delegate to other skills when:
Warning signs you're misapplying this skill:
data-ai
license: Apache-2.0 NOT for unrelated tasks outside this domain.
development
Use when designing caching strategies (cache-aside, write-through, write-behind), implementing distributed locks, building rate limiters, leaderboards, real-time streams (XADD/consumer groups), pub/sub, or tuning eviction policies. Triggers: thundering-herd on cache miss, dogpile on key expiry, Redlock vs SET-NX-PX choice, sliding-window rate limiter, hot-key on a single cluster slot, big-key blowup, MULTI/EXEC across slots, KEYS in production. NOT for Redis Cluster operations/admin (different domain), embedded KV (SQLite, leveldb), in-process LRU caches, or Memcached.
tools
Drawing the `'use client'` boundary correctly in React Server Components apps (Next.js App Router, RSC frameworks) — leaf-pushing, slot composition, serialization rules, and environment poisoning prevention. Grounded in react.dev and Next.js 16 docs.
development
Use when designing rate limiting for an API, choosing between token bucket / sliding window / leaky bucket / fixed window, implementing it in Redis, deciding edge (Cloudflare/Upstash) vs origin enforcement, sizing per-user vs per-IP vs per-endpoint quotas, returning the right 429 response with Retry-After, or fixing the boundary-burst bug in fixed-window limiters. Triggers: 429 too many requests, INCR + EXPIRE, ZADD + ZREMRANGEBYSCORE + ZCARD, X-RateLimit-Remaining header, Cloudflare WAF rate limiting rules, Upstash @upstash/ratelimit, leaky bucket shaping vs policing, distributed rate limiter consistency. NOT for DDoS mitigation specifically (different scale), CAPTCHA / bot management, full WAF design, or per-user quota billing.