skills/cycle-analysis-of-directed-acyclic-graph/SKILL.md
Analyze hierarchical DAG-like systems by separating undirected substrate from ordering metadata, then classifying diamonds, mixers, shortcuts, and hidden cycle structure. Use for workflow architecture, citation or genealogy DAG comparison, and information-flow diagnosis. NOT for ordinary cycle detection in arbitrary graphs, one-node runtime debugging, or systems with no real ordering constraint.
npx skillsauth add curiositech/windags-skills cycle-analysis-of-directed-acyclic-graphInstall 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.
Use this skill when a system looks acyclic in its directed form, but you need to understand the hidden cycle structure that actually governs resilience, integration, and information flow.
This skill is not the primary tool for:
The undirected substrate contains the real topology. The direction labels encode an external ordering constraint. "Acyclic" only means the directions respect the ordering; it does not mean the substrate lacks cycles.
After the right contractions, cycles fall into four classes: feedback loops, shortcuts, diamonds, and mixers. In transitively reduced DAGs, the informative survivors are diamonds and mixers.
Transitive reduction removes edges that add no new information path. It helps separate real organizational structure from shortcut clutter, but it is an analytical lens, not an automatic design prescription.
Antichains identify nodes that are incomparable under the ordering. They tell you where information is parallel, where it converges, and why a cycle behaves like a diamond or a mixer.
Two systems can have similar raw cycle counts but different information-processing behavior because the cycles sit at different heights, stretches, and source-sink relationships.
See the expanded visual inventory in diagrams/INDEX.md.
flowchart TD
A[Hierarchical graph to analyze] --> B{Real ordering constraint present?}
B -->|No| C[Use ordinary graph analysis instead]
B -->|Yes| D[Separate undirected substrate from direction metadata]
D --> E{Need essential structure?}
E -->|Yes| F[Compute or reason about transitive reduction]
E -->|No| G[Inspect full substrate cycles]
F --> H[Classify diamonds and mixers]
G --> I[Classify full cycle inventory]
H --> J[Interpret resilience vs integration roles]
I --> J
You compare hierarchies using degree, clustering, or raw cycle counts and miss the fact that cycle position in the ordering is what changes function.
You assume DAGs cannot contain meaningful cyclic organization. That collapses ordering constraints into topology and hides the very structure you are trying to study.
You treat every alternative path as resilience. Some are eliminable shortcuts; others are genuinely informative parallel routes.
You describe hierarchy in terms of "layers" without checking incomparability structure. That loses the distinction between integration across levels and parallelism within a level.
You let the graph representation stand in for the full system, forgetting temporal dynamics, stochasticity, incentives, or external interventions that are outside the graph.
A multi-agent workflow graph looks over-connected. Using the substrate-plus-metadata lens shows that some extra edges are transitively reducible shortcuts, while a smaller set forms diamonds that preserve alternative recovery routes when one branch stalls. The redesign should prune shortcuts without destroying resilience.
Two hierarchical networks have similar size and edge density. Raw graph metrics say they are close; cycle analysis shows one concentrates mixer structures high in the hierarchy while the other mostly has local diamonds. The first is integration-heavy, the second is redundancy-heavy, which explains different diffusion behavior.
| File | Load when... |
| --- | --- |
| references/when-does-dag-analysis-apply.md | You need to check the boundary conditions before using this framework. |
| references/dag-decomposition-for-hierarchical-reasoning.md | You want the formal decomposition between substrate and ordering metadata. |
| references/four-cycle-classes-information-processing.md | You need the complete taxonomy and information-role interpretation of each cycle class. |
| references/transitive-reduction-information-minimization.md | You are deciding whether transitive reduction clarifies or oversimplifies the hierarchy. |
| references/antichains-and-hierarchical-coordinates.md | You need the antichain view for positioning cycles inside the hierarchy. |
| references/metadata-localizes-topology.md | Similar topologies behave differently and you need the metadata story. |
You have internalized this skill if you naturally ask:
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.