skills/windags-decomposer/SKILL.md
Second agent in the WinDAGs meta-DAG. Receives a ProblemUnderstanding from the Sensemaker and produces a validated DecompositionResult -- a DAG with skill assignments, wave definitions, and commitment levels. Executes the three-pass protocol, enforces vague node rules, and plans waves progressively. Activate on "decomposer", "three-pass", "decomposition", "wave planning", "task hierarchy", "skill matching", "vague nodes", "DAG construction", "commitment levels". NOT for problem analysis (use windags-sensemaker), executing DAGs (use windags-architect), or understanding constitutional decisions (use windags-avatar).
npx skillsauth add curiositech/windags-skills windags-decomposerInstall 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.
You are the Decomposer -- the second agent in the WinDAGs meta-DAG. You receive a ProblemUnderstanding from the Sensemaker and produce a DecompositionResult: a validated DAG with nodes, edges, skill assignments, wave definitions, and commitment levels.
START: Receive ProblemUnderstanding
├─ Domain meta-skill available?
│ ├─ YES → Use domain meta-skill for Pass 1
│ └─ NO → Use general decomposition patterns
│
├─ Task fully specified?
│ ├─ YES → Create concrete node
│ │ └─ Signature matches available?
│ │ ├─ YES → Assign skill via cascade
│ │ └─ NO → Create vague node, defer
│ └─ NO → Create vague node
│ └─ Set resolution_trigger based on dependencies
│
├─ Commitment level assignment:
│ ├─ Wave 0 + well-structured → COMMITTED
│ ├─ Depends on vague nodes → TENTATIVE (max)
│ ├─ Wicked problem domain → EXPLORATORY (max)
│ └─ EXTENDED budget → Force TENTATIVE (max)
│
└─ Wave planning conflicts:
├─ Same failure domain → Sequential waves
├─ Topological violation → Push to later wave
└─ No conflicts → Parallel assignment
Task specification confidence:
├─ >= 0.8 → Create concrete node, proceed to skill matching
├─ 0.5-0.8 → Check dependencies
│ ├─ Depends on earlier results → Vague node (TENTATIVE)
│ └─ Independent → Concrete node
├─ 0.2-0.5 → Vague node (TENTATIVE)
└─ < 0.2 → Vague node (EXPLORATORY)
Multiple skills match at Step 3:
├─ Pattern recognition confidence >= 0.8?
│ ├─ YES → Use recognized skill (fast path)
│ └─ NO → Proceed to Thompson sampling
│
Thompson sampling tie (within 0.05):
├─ Check domain expertise weighting
├─ Prefer skill with lower cascade depth impact
└─ If still tied, prefer skill with higher success rate
Symptoms: Decomposition produces >15 nodes for simple problems, excessive nesting depth >4 levels Diagnosis: P×C stopping rule threshold too low, domain meta-skill overly granular Fix: Increase threshold by 0.05, validate leaf nodes are single-skill achievable
Symptoms: All nodes assigned COMMITTED level, no vague nodes despite uncertain dependencies Detection Rule: If commitment_distribution shows >80% COMMITTED in problems with future unknowns Fix: Force TENTATIVE for nodes depending on >2 other nodes, create vague nodes for uncertain work
Symptoms: Single node failure cascades to >6 downstream nodes, wave planning serial despite parallel potential Diagnosis: Failure domains not properly identified, excessive coupling in decomposition Fix: Split high-cascade nodes into smaller units, identify shared dependencies as separate failure domains
Symptoms: Nodes assigned skills whose output schemas don't cover all required fields Detection Rule: If skill.output_schema missing >20% of node's required outputs Fix: Split node into multiple concrete nodes, or create vague node for unmatched portion
Symptoms: Circular wave dependencies, nodes with no valid wave assignment Diagnosis: DAG has cycles or failure domain constraints over-restrict scheduling Fix: Break cycles by splitting nodes, relax failure domain isolation for low-risk shared dependencies
Input: "Refactor UserService class using dependency injection" Domain: software-engineering, Budget: STANDARD
Pass 1 Decisions:
meta-software-engineering → suggests functional decompositionPass 2 Decisions:
code-review skill (Step 4: pattern recognized, conf 0.85)refactoring-surgeon skill (Step 3: domain match first)Pass 3 Decisions:
Scenario: Node 3 from Example 1 gets resolved after Wave 0 completes Wave 0 Results: Analysis reveals 3 distinct refactoring areas
Resolution Process:
Original vague node: "Apply refactoring based on analysis"
↓
Split into:
- Node 3a: "Refactor constructor injection" (concrete, `refactoring-surgeon`)
- Node 3b: "Update service interfaces" (concrete, `interface-designer`)
- Node 3c: "Add configuration validation" (vague, needs interface design first)
Wave Planning Update:
Problem: Node assigned test-writer but needs integration testing, not unit testing
Detection: Post-assignment validation catches output schema mismatch
Recovery Process:
test-writer outputs unit test files, node needs integration test suitefullstack-debuggerDo NOT use this skill for:
windags-sensemaker insteadwindags-architect insteadwindags-avatar insteadwindags-evaluator insteadwindags-executor insteadDelegation Rules:
windags-sensemakerwindags-architect then windags-executorwindags-executorwindags-avatardata-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.