Inspect, unpack, edit, sign, and repack Ren'Py save files. Use when working with Ren'Py .save archives, save metadata JSON, screenshot/extra_info/log/signatures entries, machine save-token keys, or when a user asks to modify or repair a Ren'Py savegame.

2026-07-040

csharp-object-design

MovGP0/Skills

correct modelling of C# datastructures for maintainable code

2026-07-030

dotnet-pinvoke

MovGP0/Skills

Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.

2026-07-030

activity-tracing

MovGP0/Skills

Guides activity tracing with generated ActivitySources, tags, parent activities, exception status handling, and registration. Use when adding or reviewing OpenTelemetry activity tracing in Bendex flows.

2026-06-300

code-analysis-warnings

MovGP0/Skills

Microsoft code analysis CA warning meanings and examples

2026-06-300

compiler-warnings

MovGP0/Skills

Routing guide for enabled compiler and analyzer warnings in this Bendex solution

2026-06-300

name	nullability-warnings
description	How to fix enabled C# nullable reference type compiler warnings (CS8xxx)

Nullable compiler warnings

Use this skill when the build reports nullable-reference diagnostics such as CS8602, CS8618, CS8625, or nullable contract mismatches on overrides, interfaces, delegates, partial methods, and attributes.

Source reference: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/nullable-warnings Resolution guide: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/null-safety/common-tasks/resolve-warnings

Fixing strategy

Prefer making the nullability contract true over suppressing the warning. The goal is to make the code null-handling intent explicit.
First classify the expression null-state: not-null means safe to use; maybe-null needs a check, annotation, initialization, or contract change.
Add a guard clause, is not null pattern, ?., ??, or ??= when the warning is caused by dereferencing or passing a maybe-null value.
Add or remove ? when the API contract is wrong. Use ? when missing data is a valid domain state; keep the type non-nullable when callers may rely on a value.
Use nullable static-analysis attributes such as [NotNullWhen], [NotNullIfNotNull], [MemberNotNull], and [DoesNotReturn] when helper methods change null-state in a way the compiler cannot infer.
Initialize non-nullable members through constructor parameters, primary constructors, required init properties, or a meaningful declaration default. Do not invent sentinel defaults like "N/A" just to silence CS8618.
Verify the project nullable setting when warnings look inconsistent. In this repo, Directory.Build.props enables nullable with <Nullable>enable</Nullable>.
Use the null-forgiving operator ! only when a local invariant is already guaranteed and cannot be expressed cleanly to the compiler.
For overrides, interface implementations, delegates, and partial methods, align the implementation with the contract instead of changing only the implementation.