@cubis/foundry 0.3.71 → 0.3.72

package/workflows/powers/cpp-pro/references/template-and-concepts-patterns.md

@@ -0,0 +1,205 @@
+# Template and Concepts Patterns
+
+## Concepts (C++20/23)
+
+Concepts replace SFINAE with readable, composable constraints.
+
+```cpp
+#include <concepts>
+
+// Basic concept usage
+template<std::integral T>
+T add(T a, T b) { return a + b; }
+
+// Custom concept
+template<typename T>
+concept Serializable = requires(T t, std::ostream& os) {
+    { t.serialize(os) } -> std::same_as<void>;
+    { T::deserialize(os) } -> std::same_as<T>;
+};
+
+// Use in function template
+template<Serializable T>
+void save(const T& obj, const std::filesystem::path& path) {
+    std::ofstream file(path);
+    obj.serialize(file);
+}
+
+// Concept with multiple requirements
+template<typename T>
+concept Hashable = requires(T a) {
+    { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>;
+    requires std::equality_comparable<T>;
+};
+
+// Constrained auto
+void process(std::ranges::range auto&& r) {
+    for (auto&& elem : r) {
+        // works with any range
+    }
+}
+```
+
+## Concept Composition
+
+```cpp
+// Combine concepts with &&, ||
+template<typename T>
+concept Numeric = std::integral<T> || std::floating_point<T>;
+
+template<typename T>
+concept OrderedNumeric = Numeric<T> && std::totally_ordered<T>;
+
+// Subsumption — more constrained overload wins
+template<std::integral T>
+void process(T val) { /* integral-specific */ }
+
+template<Numeric T>
+void process(T val) { /* fallback for floating point */ }
+
+// int → matches std::integral (more constrained), calls first overload
+// double → matches Numeric, calls second overload
+```
+
+## Variadic Templates
+
+```cpp
+// Fold expressions (C++17) — clean variadic operations
+template<typename... Args>
+auto sum(Args... args) {
+    return (args + ...); // right fold
+}
+
+// Print all arguments
+template<typename... Args>
+void print_all(Args&&... args) {
+    ((std::cout << args << " "), ...); // comma fold
+    std::cout << "\n";
+}
+
+// Constrained variadic
+template<std::convertible_to<std::string_view>... Args>
+std::string join(std::string_view sep, Args&&... args) {
+    std::string result;
+    ((result += std::string(args) + std::string(sep)), ...);
+    if (!result.empty()) result.resize(result.size() - sep.size());
+    return result;
+}
+```
+
+## `constexpr` and `consteval`
+
+```cpp
+// constexpr — evaluable at compile time or runtime
+constexpr int factorial(int n) {
+    if (n <= 1) return 1;
+    return n * factorial(n - 1);
+}
+
+constexpr int ct = factorial(10);  // computed at compile time
+int rt = factorial(runtime_val);    // computed at runtime
+
+// consteval — MUST be evaluated at compile time
+consteval int compile_time_only(int n) {
+    return n * n;
+}
+
+constexpr int x = compile_time_only(5); // OK
+// int y = compile_time_only(runtime_val); // ERROR: not a constant expression
+
+// constexpr containers (C++20)
+constexpr auto make_primes() {
+    std::array<int, 5> primes{};
+    // ... sieve algorithm
+    return primes;
+}
+constexpr auto primes = make_primes(); // computed at compile time
+
+// if constexpr — compile-time branching
+template<typename T>
+auto to_string(const T& val) {
+    if constexpr (std::is_arithmetic_v<T>) {
+        return std::to_string(val);
+    } else if constexpr (std::is_same_v<T, std::string>) {
+        return val;
+    } else {
+        static_assert(false, "unsupported type");
+    }
+}
+```
+
+## CTAD (Class Template Argument Deduction)
+
+```cpp
+// Deduction guides — compiler deduces template arguments
+std::vector v = {1, 2, 3};        // deduces vector<int>
+std::pair p = {"hello", 42};      // deduces pair<const char*, int>
+std::optional o = 3.14;           // deduces optional<double>
+
+// Custom deduction guide
+template<typename T>
+struct Wrapper {
+    T value;
+    Wrapper(T v) : value(std::move(v)) {}
+};
+
+// Deduction guide for string literals
+Wrapper(const char*) -> Wrapper<std::string>;
+
+auto w = Wrapper("hello"); // deduces Wrapper<std::string>, not Wrapper<const char*>
+```
+
+## Type Traits and `static_assert`
+
+```cpp
+#include <type_traits>
+
+// Compile-time type validation
+template<typename T>
+class Container {
+    static_assert(std::is_nothrow_move_constructible_v<T>,
+        "Container requires nothrow movable types for exception safety");
+    static_assert(!std::is_reference_v<T>,
+        "Container cannot store references — use reference_wrapper");
+    // ...
+};
+
+// Conditional types
+template<typename T>
+using storage_type = std::conditional_t<
+    sizeof(T) <= sizeof(void*),
+    T,                    // small: store by value
+    std::unique_ptr<T>    // large: store by pointer
+>;
+```
+
+## CRTP (Curiously Recurring Template Pattern)
+
+Static polymorphism without virtual dispatch overhead.
+
+```cpp
+template<typename Derived>
+class Comparable {
+public:
+    bool operator!=(const Derived& other) const {
+        return !(static_cast<const Derived&>(*this) == other);
+    }
+    bool operator>(const Derived& other) const {
+        return other < static_cast<const Derived&>(*this);
+    }
+    // Derived must implement operator== and operator<
+};
+
+class Temperature : public Comparable<Temperature> {
+    double celsius_;
+public:
+    explicit Temperature(double c) : celsius_(c) {}
+
+    bool operator==(const Temperature& other) const {
+        return celsius_ == other.celsius_;
+    }
+    bool operator<(const Temperature& other) const {
+        return celsius_ < other.celsius_;
+    }
+};
+```

package/workflows/powers/csharp-pro/POWER.md

@@ -2,42 +2,67 @@
 ---
 inclusion: manual
 name: "csharp-pro"
-description: "Use for modern C# backend/application engineering with C# 14 and .NET 10-era production practices."
+description: "Use for modern C# backend/application engineering with C# 15 and .NET 11-era production practices."
 license: MIT
 metadata:
-  version: "1.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "csharp"
-  baseline: "C# 14 / .NET 10"
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # C# Pro
 
-## When to use
+## Purpose
+
+Expert-level guidance for modern C# backend and application engineering. Covers async/await patterns with cancellation, nullable reference types, records, dependency injection lifetimes, and production diagnostics using current .NET practices.
+
+## When to Use
 
 - Building APIs, workers, and services in .NET.
 - Refactoring legacy C# into modern, testable architecture.
 - Improving async correctness and operational resilience.
 
-## Core workflow
+## Instructions
+
+1. **Confirm target framework and language version** — establish .NET version (.NET 11 LTS, etc.) and C# language version constraints before choosing features.
+
+2. **Define clean contracts with modern types** — use `record` for immutable DTOs and value objects. Use `record struct` for small value types to avoid heap allocation. Use primary constructors (C# 12+) for concise DI. Prefer `sealed` on classes not designed for inheritance. Use pattern matching (`is`, `switch` expressions) instead of type-checking cascades.
+
+3. **Enable nullable reference types project-wide** — set `<Nullable>enable</Nullable>` and treat warnings as errors. Use null-forgiving (`!`) only at boundaries with external proof (deserialization, DI resolution). Use `required` modifier on properties that must be set at construction. Use `[NotNullWhen]` and `[MaybeNullWhen]` on bool-returning try-pattern methods.
+
+4. **Implement async-first I/O with CancellationToken propagation** — every public async method takes `CancellationToken` as its last parameter. Use `ConfigureAwait(false)` in library code. Use `ValueTask<T>` when the common path completes synchronously. Use `await using` for `IAsyncDisposable` resources. Do not use `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()` in request paths because it causes threadpool starvation and deadlocks.
+
+5. **Wire dependency injection with explicit lifetimes** — `Transient` for stateless, `Scoped` for per-request, `Singleton` for shared. Do not inject `Scoped` services into `Singleton` because it causes captive dependency and stale data. Use `IOptions<T>` / `IOptionsSnapshot<T>` / `IOptionsMonitor<T>` for configuration with proper reload semantics. Use `IServiceScopeFactory` when a Singleton needs to create scoped work.
+
+6. **Handle errors consistently at boundaries** — use `IExceptionHandler` (ASP.NET 8+) or middleware for error-to-response mapping. Throw domain exceptions for business rule violations; use `Result<T>` patterns for expected failures. Use `ActivitySource` and `Activity` for distributed tracing. Log exceptions at the boundary, not at every catch. Do not catch `Exception` in deep code without rethrowing because it swallows unexpected errors.
+
+7. **Observe and diagnose** — use structured logging (Serilog, Microsoft.Extensions.Logging) with request/job correlation IDs. Use `dotnet-counters`, `dotnet-trace`, and `dotnet-dump` for runtime diagnostics. Do not expose stack traces in production.
+
+8. **Optimize with measurement** — use `dotnet-trace` or BenchmarkDotNet to identify allocation hotspots before changing data structures. Use `Span<T>`, `ReadOnlySpan<T>`, and `Memory<T>` for zero-copy slicing in hot paths. Use `ArrayPool<T>.Shared` over repeated allocations. Use `FrozenDictionary` / `FrozenSet` (.NET 8+) for read-heavy lookup tables.
+
+9. **Validate with tests and analyzers** — use Roslyn analyzers and `dotnet test`. Bound retries and timeouts explicitly for network and queue work. Do not build fat controllers with mixed business logic and persistence because it resists testing. Do not use `string` concatenation in loops because `StringBuilder` or interpolated string handlers are more efficient. Do not ignore `CancellationToken` in long-running operations because it makes services unresponsive to shutdown. Do not use global static mutable state in multi-request services because it creates race conditions — use DI with proper lifetimes.
+
+## Output Format
+
+Produces C# code using records, nullable reference types, async/await with cancellation, and explicit DI lifetimes. Includes structured error handling and pattern matching where applicable.
+
+## References
 
-1. Confirm target framework/runtime constraints.
-2. Define clean contracts (DTOs, domain, persistence boundaries).
-3. Implement async-first I/O and cancellation-aware flows.
-4. Validate with tests, analyzers, and profiling.
+| File                                          | Load when                                                                                           |
+| --------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/operational-baseline.md`          | You need current async, logging, testing, and deployment guardrails for C#/.NET services.           |
+| `references/async-await-patterns.md`          | You need async/await patterns, ValueTask usage, cancellation design, or threadpool management.      |
+| `references/modern-csharp-features.md`        | You need patterns for records, pattern matching, primary constructors, or collection expressions.   |
+| `references/dependency-injection-patterns.md` | You need DI lifetime management, keyed services, option patterns, or service resolution strategies. |
+| `references/testing-and-analyzers.md`         | You need testing patterns, analyzer configuration, BenchmarkDotNet setup, or CI validation.         |
 
-## Baseline standards
+## Scripts
 
-- Use nullable reference types and treat warnings as actionable.
-- Use `async`/`await` with `CancellationToken` in public async APIs.
-- Keep exception handling consistent and observable.
-- Use dependency injection with explicit lifetimes.
-- Keep API contracts versioned and backward-compatible.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Avoid
+## Examples
 
-- Sync-over-async (`.Result`, `.Wait()`) in request paths.
-- Fat controllers with business logic and persistence mixed.
-- Global static mutable state in multi-request services.
+- "Refactor this controller to use async/await with CancellationToken propagation and proper DI lifetime management."
+- "Enable nullable reference types in this project and fix all the null-safety warnings with appropriate patterns."
+- "Design the error handling middleware for this ASP.NET API using IExceptionHandler and Result<T> patterns."
 ````

package/workflows/powers/csharp-pro/SKILL.md

@@ -1,40 +1,65 @@
 ---
 name: "csharp-pro"
-description: "Use for modern C# backend/application engineering with C# 14 and .NET 10-era production practices."
+description: "Use for modern C# backend/application engineering with C# 15 and .NET 11-era production practices."
 license: MIT
 metadata:
-  version: "1.0.0"
-  domain: "language"
-  role: "specialist"
-  stack: "csharp"
-  baseline: "C# 14 / .NET 10"
+  author: cubis-foundry
+  version: "1.0"
+compatibility: Claude Code, Codex, GitHub Copilot
 ---
 
 # C# Pro
 
-## When to use
+## Purpose
+
+Expert-level guidance for modern C# backend and application engineering. Covers async/await patterns with cancellation, nullable reference types, records, dependency injection lifetimes, and production diagnostics using current .NET practices.
+
+## When to Use
 
 - Building APIs, workers, and services in .NET.
 - Refactoring legacy C# into modern, testable architecture.
 - Improving async correctness and operational resilience.
 
-## Core workflow
+## Instructions
+
+1. **Confirm target framework and language version** — establish .NET version (.NET 11 LTS, etc.) and C# language version constraints before choosing features.
+
+2. **Define clean contracts with modern types** — use `record` for immutable DTOs and value objects. Use `record struct` for small value types to avoid heap allocation. Use primary constructors (C# 12+) for concise DI. Prefer `sealed` on classes not designed for inheritance. Use pattern matching (`is`, `switch` expressions) instead of type-checking cascades.
+
+3. **Enable nullable reference types project-wide** — set `<Nullable>enable</Nullable>` and treat warnings as errors. Use null-forgiving (`!`) only at boundaries with external proof (deserialization, DI resolution). Use `required` modifier on properties that must be set at construction. Use `[NotNullWhen]` and `[MaybeNullWhen]` on bool-returning try-pattern methods.
+
+4. **Implement async-first I/O with CancellationToken propagation** — every public async method takes `CancellationToken` as its last parameter. Use `ConfigureAwait(false)` in library code. Use `ValueTask<T>` when the common path completes synchronously. Use `await using` for `IAsyncDisposable` resources. Do not use `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()` in request paths because it causes threadpool starvation and deadlocks.
+
+5. **Wire dependency injection with explicit lifetimes** — `Transient` for stateless, `Scoped` for per-request, `Singleton` for shared. Do not inject `Scoped` services into `Singleton` because it causes captive dependency and stale data. Use `IOptions<T>` / `IOptionsSnapshot<T>` / `IOptionsMonitor<T>` for configuration with proper reload semantics. Use `IServiceScopeFactory` when a Singleton needs to create scoped work.
+
+6. **Handle errors consistently at boundaries** — use `IExceptionHandler` (ASP.NET 8+) or middleware for error-to-response mapping. Throw domain exceptions for business rule violations; use `Result<T>` patterns for expected failures. Use `ActivitySource` and `Activity` for distributed tracing. Log exceptions at the boundary, not at every catch. Do not catch `Exception` in deep code without rethrowing because it swallows unexpected errors.
+
+7. **Observe and diagnose** — use structured logging (Serilog, Microsoft.Extensions.Logging) with request/job correlation IDs. Use `dotnet-counters`, `dotnet-trace`, and `dotnet-dump` for runtime diagnostics. Do not expose stack traces in production.
+
+8. **Optimize with measurement** — use `dotnet-trace` or BenchmarkDotNet to identify allocation hotspots before changing data structures. Use `Span<T>`, `ReadOnlySpan<T>`, and `Memory<T>` for zero-copy slicing in hot paths. Use `ArrayPool<T>.Shared` over repeated allocations. Use `FrozenDictionary` / `FrozenSet` (.NET 8+) for read-heavy lookup tables.
+
+9. **Validate with tests and analyzers** — use Roslyn analyzers and `dotnet test`. Bound retries and timeouts explicitly for network and queue work. Do not build fat controllers with mixed business logic and persistence because it resists testing. Do not use `string` concatenation in loops because `StringBuilder` or interpolated string handlers are more efficient. Do not ignore `CancellationToken` in long-running operations because it makes services unresponsive to shutdown. Do not use global static mutable state in multi-request services because it creates race conditions — use DI with proper lifetimes.
+
+## Output Format
+
+Produces C# code using records, nullable reference types, async/await with cancellation, and explicit DI lifetimes. Includes structured error handling and pattern matching where applicable.
+
+## References
 
-1. Confirm target framework/runtime constraints.
-2. Define clean contracts (DTOs, domain, persistence boundaries).
-3. Implement async-first I/O and cancellation-aware flows.
-4. Validate with tests, analyzers, and profiling.
+| File                                          | Load when                                                                                           |
+| --------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `references/operational-baseline.md`          | You need current async, logging, testing, and deployment guardrails for C#/.NET services.           |
+| `references/async-await-patterns.md`          | You need async/await patterns, ValueTask usage, cancellation design, or threadpool management.      |
+| `references/modern-csharp-features.md`        | You need patterns for records, pattern matching, primary constructors, or collection expressions.   |
+| `references/dependency-injection-patterns.md` | You need DI lifetime management, keyed services, option patterns, or service resolution strategies. |
+| `references/testing-and-analyzers.md`         | You need testing patterns, analyzer configuration, BenchmarkDotNet setup, or CI validation.         |
 
-## Baseline standards
+## Scripts
 
-- Use nullable reference types and treat warnings as actionable.
-- Use `async`/`await` with `CancellationToken` in public async APIs.
-- Keep exception handling consistent and observable.
-- Use dependency injection with explicit lifetimes.
-- Keep API contracts versioned and backward-compatible.
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
 
-## Avoid
+## Examples
 
-- Sync-over-async (`.Result`, `.Wait()`) in request paths.
-- Fat controllers with business logic and persistence mixed.
-- Global static mutable state in multi-request services.
+- "Refactor this controller to use async/await with CancellationToken propagation and proper DI lifetime management."
+- "Enable nullable reference types in this project and fix all the null-safety warnings with appropriate patterns."
+- "Design the error handling middleware for this ASP.NET API using IExceptionHandler and Result<T> patterns."

package/workflows/powers/dart-pro/POWER.md

@@ -0,0 +1,68 @@
+````markdown
+---
+inclusion: manual
+name: "dart-pro"
+description: "Use for modern Dart engineering across Flutter, server, and CLI code with Dart 3.11-era language features, package hygiene, isolates, and testing discipline."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Dart Pro
+
+## Purpose
+
+Expert-level guidance for modern Dart development across Flutter app logic, server applications, and CLI tooling. Covers null safety, sealed classes with pattern matching, async and isolate patterns, package hygiene, and testing discipline using current Dart language features.
+
+## When to Use
+
+- Designing Dart libraries, Flutter app logic, or Dart CLI tooling.
+- Refactoring null-safety, sealed classes, records, or pattern matching.
+- Improving package structure, async correctness, and testability.
+
+## Instructions
+
+1. **Confirm runtime context** — identify whether the code targets Flutter UI, server, or CLI. This determines available APIs, isolate patterns, and testing approaches.
+
+2. **Keep null safety and type intent explicit** — prefer non-nullable types by default. Use `?` only when null is a valid domain value. Use `late` only when initialization is guaranteed before access. Target sound null safety with no `// ignore: null_check` suppressions without justification. Do not use `!` (null assertion) in production code without a preceding null check because it crashes at runtime.
+
+3. **Use sealed models, records, and pattern matching** — use sealed classes for closed type hierarchies with exhaustive `switch` that catches missing cases at compile time. Use records `(int, String)` for lightweight grouped returns. Use `switch` expressions with pattern matching for state machines. Prefer destructuring in `if-case` and `switch` over manual `is` checks and casts.
+
+4. **Design async flows with proper lifecycle** — use `async`/`await` for I/O-bound work. Keep `Future` chains flat. Use `Stream` for event-driven data with `StreamController.broadcast()` only when multiple listeners are needed. Cancel subscriptions and close controllers in `dispose()` to prevent memory leaks. Do not block the main isolate with synchronous I/O or heavy computation because it freezes the UI.
+
+5. **Offload compute to isolates when needed** — use `Isolate.run()` or `compute()` in Flutter for CPU-heavy work. Keep the main isolate responsive for UI and event handling.
+
+6. **Maintain package hygiene** — keep `pubspec.yaml` dependencies minimal. Use `dart pub outdated` to identify stale dependencies. Export only the public API from `lib/src/` via a barrel file. Pin SDK constraint to the minimum required version. Keep `pubspec.lock` in version control for applications (not for libraries). Do not import implementation files from `lib/src/` directly in other packages because it breaks encapsulation.
+
+7. **Run analysis before committing** — run `dart analyze` with zero warnings. Treat analyzer warnings as defects. Use `dart format` for consistent style. Do not override formatter rules per-file. Do not ignore analyzer warnings with `// ignore:` comments without a justification comment because it hides real defects.
+
+8. **Test business logic independently** — use `package:test` for unit tests, `package:mocktail` or `package:mockito` for mocking. Test logic in plain Dart classes independent of Flutter widgets. Run tests with `--coverage` and review uncovered branches. Do not mix business logic into widget `build()` methods because it prevents isolated testing.
+
+9. **Do not use `dynamic` as a type** because it disables all static checking — use `Object` or generics instead.
+
+## Output Format
+
+Produces Dart code with sound null safety, sealed class hierarchies, pattern matching, and clean async patterns. Includes barrel exports and analyzer-clean output with proper package structure.
+
+## References
+
+| File                                           | Load when                                                                                                           |
+| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `references/null-safety-and-async-patterns.md` | Null safety migration, sealed class patterns, async/isolate architecture, or stream lifecycle management is needed. |
+| `references/sealed-records-patterns.md`        | You need sealed class hierarchies, records, destructuring, or exhaustive switch patterns for state modeling.        |
+| `references/isolate-and-concurrency.md`        | You need isolate architecture, compute offload, port communication, or Flutter isolate integration patterns.        |
+| `references/package-structure-and-linting.md`  | You need pub workspace layout, barrel exports, analysis_options rules, or dependency audit workflow.                |
+| `references/testing-and-mocking.md`            | You need test patterns with mockito/mocktail, widget testing, golden tests, or coverage-driven CI.                  |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Refactor this state management code to use sealed classes with exhaustive pattern matching instead of enum flags."
+- "Design the isolate architecture for this image processing pipeline in a Flutter app."
+- "Set up the package structure for this shared Dart library with proper barrel exports and analysis_options."
+````

package/workflows/powers/dart-pro/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: "dart-pro"
+description: "Use for modern Dart engineering across Flutter, server, and CLI code with Dart 3.11-era language features, package hygiene, isolates, and testing discipline."
+license: MIT
+metadata:
+  author: cubis-foundry
+  version: "2.0"
+compatibility: Claude Code, Codex, GitHub Copilot
+---
+
+# Dart Pro
+
+## Purpose
+
+Expert-level guidance for modern Dart development across Flutter app logic, server applications, and CLI tooling. Covers null safety, sealed classes with pattern matching, async and isolate patterns, package hygiene, and testing discipline using current Dart language features.
+
+## When to Use
+
+- Designing Dart libraries, Flutter app logic, or Dart CLI tooling.
+- Refactoring null-safety, sealed classes, records, or pattern matching.
+- Improving package structure, async correctness, and testability.
+
+## Instructions
+
+1. **Confirm runtime context** — identify whether the code targets Flutter UI, server, or CLI. This determines available APIs, isolate patterns, and testing approaches.
+
+2. **Keep null safety and type intent explicit** — prefer non-nullable types by default. Use `?` only when null is a valid domain value. Use `late` only when initialization is guaranteed before access. Target sound null safety with no `// ignore: null_check` suppressions without justification. Do not use `!` (null assertion) in production code without a preceding null check because it crashes at runtime.
+
+3. **Use sealed models, records, and pattern matching** — use sealed classes for closed type hierarchies with exhaustive `switch` that catches missing cases at compile time. Use records `(int, String)` for lightweight grouped returns. Use `switch` expressions with pattern matching for state machines. Prefer destructuring in `if-case` and `switch` over manual `is` checks and casts.
+
+4. **Design async flows with proper lifecycle** — use `async`/`await` for I/O-bound work. Keep `Future` chains flat. Use `Stream` for event-driven data with `StreamController.broadcast()` only when multiple listeners are needed. Cancel subscriptions and close controllers in `dispose()` to prevent memory leaks. Do not block the main isolate with synchronous I/O or heavy computation because it freezes the UI.
+
+5. **Offload compute to isolates when needed** — use `Isolate.run()` or `compute()` in Flutter for CPU-heavy work. Keep the main isolate responsive for UI and event handling.
+
+6. **Maintain package hygiene** — keep `pubspec.yaml` dependencies minimal. Use `dart pub outdated` to identify stale dependencies. Export only the public API from `lib/src/` via a barrel file. Pin SDK constraint to the minimum required version. Keep `pubspec.lock` in version control for applications (not for libraries). Do not import implementation files from `lib/src/` directly in other packages because it breaks encapsulation.
+
+7. **Run analysis before committing** — run `dart analyze` with zero warnings. Treat analyzer warnings as defects. Use `dart format` for consistent style. Do not override formatter rules per-file. Do not ignore analyzer warnings with `// ignore:` comments without a justification comment because it hides real defects.
+
+8. **Test business logic independently** — use `package:test` for unit tests, `package:mocktail` or `package:mockito` for mocking. Test logic in plain Dart classes independent of Flutter widgets. Run tests with `--coverage` and review uncovered branches. Do not mix business logic into widget `build()` methods because it prevents isolated testing.
+
+9. **Do not use `dynamic` as a type** because it disables all static checking — use `Object` or generics instead.
+
+## Output Format
+
+Produces Dart code with sound null safety, sealed class hierarchies, pattern matching, and clean async patterns. Includes barrel exports and analyzer-clean output with proper package structure.
+
+## References
+
+| File                                           | Load when                                                                                                           |
+| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `references/null-safety-and-async-patterns.md` | Null safety migration, sealed class patterns, async/isolate architecture, or stream lifecycle management is needed. |
+| `references/sealed-records-patterns.md`        | You need sealed class hierarchies, records, destructuring, or exhaustive switch patterns for state modeling.        |
+| `references/isolate-and-concurrency.md`        | You need isolate architecture, compute offload, port communication, or Flutter isolate integration patterns.        |
+| `references/package-structure-and-linting.md`  | You need pub workspace layout, barrel exports, analysis_options rules, or dependency audit workflow.                |
+| `references/testing-and-mocking.md`            | You need test patterns with mockito/mocktail, widget testing, golden tests, or coverage-driven CI.                  |
+
+## Scripts
+
+No helper scripts are required for this skill right now. Keep execution in `SKILL.md` and `references/` unless repeated automation becomes necessary.
+
+## Examples
+
+- "Refactor this state management code to use sealed classes with exhaustive pattern matching instead of enum flags."
+- "Design the isolate architecture for this image processing pipeline in a Flutter app."
+- "Set up the package structure for this shared Dart library with proper barrel exports and analysis_options."