Skip to content
cccskills
FreePublished on GitHub

managedcode-orleans-graph

Integrate ManagedCode.Orleans.Graph into an Orleans-based .NET application for graph-oriented relationships, edge management, and traversal logic on top of Orleans grains. Use when the application models graph structures in a distributed Orleans system.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md3.7 KB
  • manifest.json107 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

ManagedCode.Orleans.Graph

Trigger On

  • integrating ManagedCode.Orleans.Graph into an Orleans-based system
  • modeling graph relationships, edges, or traversal behavior with Orleans grains
  • reviewing graph-oriented distributed workflows on top of Orleans
  • deciding whether a graph abstraction is the right fit vs relational modeling

Workflow

  1. Install the library:
    dotnet add package ManagedCode.Orleans.Graph
    
  2. Confirm the application has a real graph problem — node-to-node relationships, directed/undirected edges, or traversal queries. If the data is tabular or hierarchical, prefer standard Orleans grain patterns instead.
  3. Model graph entities as grains:
    • nodes map to grain identities
    • edges represent relationships between grains
    • traversal operations query across grain boundaries
  4. Implement graph operations:
    // Define a graph grain interface
    public interface IGraphGrain : IGrainWithStringKey
    {
        Task AddEdge(string targetId, string edgeType);
        Task<IReadOnlyList<string>> GetNeighbors(string edgeType);
        Task<bool> HasEdge(string targetId, string edgeType);
        Task RemoveEdge(string targetId, string edgeType);
    }
    
  5. Keep Orleans runtime concerns explicit:
    • grain identity determines the node identity
    • persistence provider stores edge state
    • grain activation lifecycle affects traversal latency
  6. Add traversal logic for multi-hop queries:
    // Breadth-first traversal across grains
    public async Task<IReadOnlyList<string>> TraverseAsync(
        IGrainFactory grainFactory, string startId, string edgeType, int maxDepth)
    {
        var visited = new HashSet<string>();
        var queue = new Queue<(string Id, int Depth)>();
        queue.Enqueue((startId, 0));
    
        while (queue.Count > 0)
        {
            var (currentId, depth) = queue.Dequeue();
            if (!visited.Add(currentId) || depth >= maxDepth) continue;
    
            var grain = grainFactory.GetGrain<IGraphGrain>(currentId);
            var neighbors = await grain.GetNeighbors(edgeType);
            foreach (var neighbor in neighbors)
                queue.Enqueue((neighbor, depth + 1));
        }
        return visited.ToList();
    }
    
  7. Validate that traversal and relationship operations work against real Orleans clusters, not only unit tests with mock grain factories.
flowchart LR
  A["Graph request"] --> B["Resolve node grain"]
  B --> C["Query edges from grain state"]
  C --> D{"Traversal needed?"}
  D -->|Yes| E["Multi-hop grain calls"]
  D -->|No| F["Return direct neighbors"]
  E --> G["Aggregate results"]
  F --> G

Deliver

  • concrete guidance on when Orleans.Graph is the right abstraction vs standard grain patterns
  • graph grain interface patterns with edge management
  • traversal implementation that respects Orleans distributed execution
  • verification expectations for real graph flows

Validate

  • the application has a genuine graph problem, not a generic relational one
  • graph integration does not blur grain identity and traversal concerns
  • edge persistence is configured for the correct Orleans storage provider
  • traversal operations are tested against a real Orleans cluster, not only mocks
  • multi-hop queries have bounded depth to prevent runaway grain activations

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use a repo-root `.editorconfig` to configure free .NET analyzer and style rules. Use when a .NET repo needs rule severity, code-style options, section layout, or analyzer ownership made explicit. Nested `.editorconfig` files are allowed when they serve a clear subtree-specific purpose.

The English summary is being prepared. Showing the original description.

managedcode/Orleans.RateLimiting30Updated Oct 11, 2026

Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.

The English summary is being prepared. Showing the original description.

managedcode/Orleans.RateLimiting30Updated Oct 11, 2026

Use the open-source free `ArchUnitNET` library for architecture rules in .NET tests. Use when a repo needs richer architecture assertions than lightweight fluent rule libraries usually provide.

The English summary is being prepared. Showing the original description.

managedcode/Orleans.RateLimiting30Updated Oct 11, 2026

Use the free built-in .NET SDK analyzers and analysis levels with gradual Roslyn warning promotion. Use when a .NET repo needs first-party code analysis, `EnableNETAnalyzers`, `AnalysisLevel`, or warning-as-error policy wired into build and CI.

The English summary is being prepared. Showing the original description.

managedcode/Orleans.RateLimiting30Updated Oct 11, 2026

Use free built-in .NET maintainability analyzers and code metrics configuration to find overly complex methods and coupled code. Use when a repo needs cyclomatic complexity checks, maintainability thresholds, or complexity-driven refactoring gates.

The English summary is being prepared. Showing the original description.

managedcode/Orleans.RateLimiting30Updated Oct 11, 2026

Calculates CRAP (Change Risk Anti-Patterns) score for .NET methods, classes, or files. Use when the user asks to assess test quality, identify risky untested code, compute CRAP scores, or evaluate whether complex methods have sufficient test coverage. Requires code coverage data (Cobertura XML) and cyclomatic complexity analysis. DO NOT USE FOR: writing tests, general test execution unrelated to coverage/CRAP analysis, or general code coverage reporting without CRAP context.

The English summary is being prepared. Showing the original description.

managedcode/Orleans.RateLimiting30Updated Oct 11, 2026

See all skills by managedcode

Report a problem with this skill