feat: improve skill scores for dotnet-skills

.github/workflows/skill-review.yml

@@ -0,0 +1,22 @@
+# Tessl Skill Review — runs on PRs that change any SKILL.md; posts scores as one PR comment.
+# Docs: https://github.com/tesslio/skill-review
+name: Tessl Skill Review
+
+on:
+  pull_request:
+    branches: [main]
+    paths:
+      - "**/SKILL.md"
+
+jobs:
+  review:
+    runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+      - uses: tesslio/skill-review@main
+      # Optional quality gate (off by default — do not enable unless user asked):
+      # with:
+      #   fail-threshold: 70

skills/dotnet-entity-framework6/SKILL.md

@@ -1,41 +1,80 @@
 ---
 name: dotnet-entity-framework6
-version: "1.0.0"
-category: "Data"
-description: "Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step."
+version: "1.0.1"
+category: "Data, Distributed, and AI"
+description: "Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. Use when working in an EF6 codebase or planning a data layer migration."
 compatibility: "Requires EF6 or a transition plan from EF6 to EF Core or modern .NET."
 ---
 
 # Entity Framework 6
 
 ## Trigger On
 
-- working in an EF6 codebase
-- deciding whether to keep EF6, move to modern .NET, or port to EF Core
+- working in an EF6 codebase on .NET Framework or modern .NET
+- deciding whether to keep EF6, move to modern .NET runtime, or port to EF Core
 - reviewing EDMX, code-first, or legacy ASP.NET/WPF/WinForms data access
+- planning a data layer migration strategy
 
 ## Workflow
 
-1. Treat EF6 as stable and supported but no longer the innovation path; do not promise EF Core-only features to EF6 applications.
-2. Decide separately between runtime migration and ORM migration; moving to modern .NET can happen before or without moving to EF Core.
-3. Review advanced mapping usage, lazy loading, stored procedures, and designer-driven models before planning a port because these often drive migration cost.
-4. Prefer small, validated migration slices rather than big-bang rewrites of the data layer.
-5. Use `dotnet-entity-framework-core` only when the app is actually ready to adopt EF Core patterns and provider support.
-6. Keep performance and behavior checks close to the real database provider, not only mock or in-memory tests.
+1. **Audit current EF6 usage** before planning any migration. Identify which features the codebase depends on:
+   ```csharp
+   // Common EF6-specific patterns to inventory:
+   // - EDMX designer models (check for *.edmx files)
+   // - ObjectContext vs DbContext usage
+   // - Lazy loading with virtual navigation properties
+   // - Database.SqlQuery<T>() for raw SQL
+   // - Stored procedure mappings in model
+   // - Spatial types (DbGeography, DbGeometry)
+   ```
+2. **Decide runtime vs ORM migration separately:**
+
+   | Path | When to use |
+   |------|-------------|
+   | Keep EF6 on .NET Framework | Legacy app with no runtime pressure |
+   | EF6 on modern .NET | Runtime upgrade needed, ORM migration too risky |
+   | EF6 → EF Core | Clean data layer, no EDMX, minimal stored-procedure mapping |
+
+3. **For maintenance work** — keep EF6 stable:
+   - use repository + unit of work patterns to isolate data access (see references/patterns.md)
+   - prefer `DbContext` over `ObjectContext` for new code
+   - use `AsNoTracking()` for read-only queries
+   - configure concurrency tokens with `[ConcurrencyCheck]` or `IsRowVersion()`
+4. **For migration work** — validate each slice:
+   - map EF6 features to EF Core equivalents (see references/migration.md)
+   - migrate one bounded context at a time, not the entire data layer
+   - run integration tests against the real database provider, not InMemory
+   - verify: `dotnet ef migrations add` succeeds, queries produce equivalent results, lazy loading behavior matches expectations
+5. **Do not promise EF Core features to EF6 codebases** — EF6 is stable and supported but not on the innovation path. Keep expectations realistic.
+
+```mermaid
+flowchart LR
+  A["Audit EF6 usage"] --> B{"EDMX or complex mappings?"}
+  B -->|Yes| C["High migration cost — consider keeping EF6"]
+  B -->|No| D["Evaluate EF Core migration"]
+  D --> E["Migrate one context at a time"]
+  E --> F["Integration test against real DB"]
+  C --> G["Modernize runtime only"]
+  F --> H["Validate query equivalence"]
+  G --> H
+```
 
 ## Deliver
 
-- realistic EF6 maintenance or migration guidance
+- realistic EF6 maintenance or migration guidance based on actual codebase audit
 - clear separation between runtime upgrade and ORM upgrade work
+- bounded migration slices with concrete validation checkpoints
 - reduced risk for legacy data access changes
 
 ## Validate
 
-- migration assumptions are backed by real feature usage
-- EF6-only features are identified early
-- the proposed path avoids avoidable churn
+- EF6 feature inventory is complete before migration planning starts
+- migration assumptions are backed by real feature usage, not guesses
+- EF6-only features (EDMX, spatial types, ObjectContext patterns) are identified early
+- integration tests run against the real database provider, not mocks or InMemory
+- the proposed path avoids unnecessary churn in stable data access code
 
 ## References
 
-- [EF6 to EF Core Migration Guide](references/migration.md) - decision framework, migration approaches, feature mapping, and common pitfalls when moving from EF6 to EF Core
-- [EF6 Maintenance Patterns](references/patterns.md) - repository and unit of work patterns, query optimization, concurrency handling, auditing, and testing strategies for EF6 codebases
+- references/migration.md - decision framework, migration approaches, EF6-to-EF Core feature mapping, and common pitfalls
+- references/patterns.md - repository and unit of work patterns, query optimization, concurrency handling, auditing, and testing strategies for EF6 codebases

skills/dotnet-managedcode-orleans-graph/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: dotnet-managedcode-orleans-graph
-version: "1.0.0"
-category: "Distributed"
-description: "Use ManagedCode.Orleans.Graph when a distributed .NET application models graph-oriented relationships or traversal logic on top of Orleans grains and graph-aware integration patterns."
+version: "1.0.1"
+category: "Data, Distributed, and AI"
+description: "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."
 compatibility: "Requires a .NET application that integrates ManagedCode.Orleans.Graph or evaluates graph-style modeling with Orleans."
 ---
 
@@ -11,36 +11,83 @@ compatibility: "Requires a .NET application that integrates ManagedCode.Orleans.
 ## Trigger On
 
 - integrating `ManagedCode.Orleans.Graph` into an Orleans-based system
-- modeling graph relationships, edges, or traversal behavior with Orleans
-- reviewing graph-oriented distributed workflows
-- documenting how graph operations fit into an Orleans application
+- 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. Confirm the application really has graph-style relationships or traversal needs.
-2. Identify which graph concerns belong in the library integration:
-   - node representation
-   - relationship management
-   - traversal or lookup patterns
-3. Keep Orleans runtime concerns explicit and avoid disguising a normal CRUD model as a graph problem.
-4. Document how graph operations interact with grain identity, persistence, and distributed execution.
-5. Validate the actual traversal or relationship scenarios the application depends on.
+1. **Install the library:**
+   ```bash
+   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:**
+   ```csharp
+   // 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:**
+   ```csharp
+   // 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.
 
 ```mermaid
 flowchart LR
-  A["Application graph request"] --> B["ManagedCode.Orleans.Graph integration"]
-  B --> C["Orleans grain graph model"]
-  C --> D["Traversal, relationship, or query result"]
+  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
 
-- guidance on when Orleans.Graph is the right abstraction
-- recommendations for keeping graph modeling explicit
-- verification expectations for the graph flows the application actually runs
+- 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 real graph problem, not a generic relational one
+- the application has a genuine graph problem, not a generic relational one
 - graph integration does not blur grain identity and traversal concerns
-- validation covers real traversal or relationship flows, not only setup code
+- 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