@minko-ai/minko 0.1.0 → 0.1.1

package/assets/skills/code-review/reference/zig.md

@@ -0,0 +1,440 @@
+# Zig Code Review Guide
+
+> Code review guidelines for Zig focusing on explicit memory ownership, error unions, defer/errdefer cleanup, comptime usage, safety-checked operations, C interop, and tests.
+
+## Table of Contents
+
+- [Memory & Allocators](#memory--allocators)
+- [Errors & Cleanup](#errors--cleanup)
+- [Pointers, Slices & Optionals](#pointers-slices--optionals)
+- [Comptime & Generics](#comptime--generics)
+- [Safety, Undefined Behavior & Casts](#safety-undefined-behavior--casts)
+- [C Interop](#c-interop)
+- [Testing](#testing)
+- [Style & API Design](#style--api-design)
+- [Review Checklist](#review-checklist)
+- [References](#references)
+
+---
+
+## Memory & Allocators
+
+### Make Allocator Ownership Explicit
+
+Zig code should make allocation policy visible. Libraries should usually accept an `std.mem.Allocator` from the caller rather than creating a global allocator internally.
+
+```zig
+const std = @import("std");
+
+// ❌ Bad: hides allocation policy and lifetime from callers.
+fn readNamesBad() ![][]const u8 {
+    var gpa = std.heap.DebugAllocator(.{}){};
+    const allocator = gpa.allocator();
+    return try allocator.alloc([]const u8, 10);
+}
+
+// ✅ Good: caller chooses allocator and owns the returned memory.
+fn readNames(allocator: std.mem.Allocator) ![][]const u8 {
+    return try allocator.alloc([]const u8, 10);
+}
+```
+
+Review questions:
+- Does the caller know who owns allocated memory?
+- Does the API document whether returned slices must be freed?
+- Is the allocator parameter passed through instead of replaced by an internal global allocator?
+
+### Pair Allocations With Cleanup
+
+Every allocation path should have a visible cleanup path. Look for missing `defer`, missing `errdefer`, and containers that are initialized but never deinitialized.
+
+```zig
+const std = @import("std");
+
+fn collectBad(allocator: std.mem.Allocator) ![]u8 {
+    // ❌ Bad: returns a slice whose backing memory is freed as the function exits.
+    var bad_list: std.ArrayListUnmanaged(u8) = .empty;
+    defer bad_list.deinit(allocator);
+    try bad_list.append(allocator, 'a');
+    return bad_list.items;
+}
+
+fn collect(allocator: std.mem.Allocator) ![]u8 {
+    // ✅ Good: `errdefer` cleans up only on failure; success transfers ownership.
+    var list: std.ArrayListUnmanaged(u8) = .empty;
+    errdefer list.deinit(allocator);
+
+    try list.append(allocator, 'a');
+    try list.append(allocator, 'b');
+    return try list.toOwnedSlice(allocator);
+}
+```
+
+Review questions:
+- Is cleanup registered immediately after acquisition?
+- Is `errdefer` used when ownership transfers only on success?
+- Are `deinit` calls paired with all container initializations?
+
+### Choose Allocators Deliberately
+
+Allocator choice is part of the design. A review should flag broad use of a debug/general-purpose allocator where a fixed buffer, arena, page allocator, or caller-provided allocator better matches the lifetime.
+
+```zig
+// ❌ Bad: allocation lifetime is scattered across many individual frees.
+const user = try allocator.create(User);
+const events = try allocator.alloc(Event, event_count);
+
+// ✅ Good: request/frame-scoped allocations are freed together.
+var arena = std.heap.ArenaAllocator.init(parent_allocator);
+defer arena.deinit();
+const allocator = arena.allocator();
+```
+
+Review questions:
+- Are arena allocations freed at a clear lifetime boundary?
+- Is a test using `std.testing.allocator` to catch leaks?
+- Is a library avoiding policy decisions that belong to its caller?
+
+---
+
+## Errors & Cleanup
+
+### Keep Error Sets Useful
+
+Avoid flattening meaningful errors into `anyerror` unless the boundary genuinely needs it. Specific error sets improve API contracts and make callers handle expected failures.
+
+```zig
+// ❌ Bad: erases the expected parse failures behind `anyerror`.
+fn parseDigitAny(input: []const u8) anyerror!u8 {
+    if (input.len == 0) return error.EmptyInput;
+    if (input[0] < '0' or input[0] > '9') return error.InvalidDigit;
+    return input[0] - '0';
+}
+
+// ✅ Good: names the domain failures that callers should handle.
+const ParseError = error{
+    EmptyInput,
+    InvalidDigit,
+};
+
+fn parseDigit(input: []const u8) ParseError!u8 {
+    if (input.len == 0) return error.EmptyInput;
+    if (input[0] < '0' or input[0] > '9') return error.InvalidDigit;
+    return input[0] - '0';
+}
+```
+
+Review questions:
+- Are expected domain failures named explicitly?
+- Is `anyerror` only used at integration boundaries?
+- Does the caller preserve context when converting errors?
+
+### Use `try`, `catch`, and `errdefer` Intentionally
+
+Blind `catch unreachable` is a code smell unless the invariant is mechanically guaranteed. Prefer propagating errors with `try`, converting them at boundaries, or adding a comment for unreachable invariants.
+
+```zig
+// ❌ Bad: hides a real allocation failure.
+const buffer_bad = allocator.alloc(u8, size) catch unreachable;
+
+// ✅ Good: caller can handle OutOfMemory.
+const buffer = try allocator.alloc(u8, size);
+```
+
+Review questions:
+- Does `catch unreachable` mask I/O, allocation, parsing, or user-input errors?
+- Are errors converted close to a boundary where the abstraction changes?
+- Does `errdefer` undo partial state changes on failure?
+
+---
+
+## Pointers, Slices & Optionals
+
+### Prefer Slices Over Pointer Plus Length
+
+Slices carry pointer and length together, improving bounds checking and API clarity. Raw pointer plus length should be reserved for FFI or very low-level code.
+
+```zig
+// ❌ Bad: easy to mismatch pointer and length.
+fn checksumRaw(ptr: [*]const u8, len: usize) u32 {
+    var sum: u32 = 0;
+    for (ptr[0..len]) |byte| sum += byte;
+    return sum;
+}
+
+// ✅ Good: one value represents the buffer.
+fn checksum(bytes: []const u8) u32 {
+    var sum: u32 = 0;
+    for (bytes) |byte| sum += byte;
+    return sum;
+}
+```
+
+Review questions:
+- Can a raw pointer API become a slice API?
+- Is nullability modeled with `?T` instead of sentinel values?
+- Are pointer lifetimes clear after returning from a function?
+
+### Avoid Returning Pointers to Stack Data
+
+Review returned slices and pointers carefully. Zig makes many lifetime issues visible, but reviewers should still check that returned data outlives the function.
+
+```zig
+// ❌ Bad: returned slice points to stack memory.
+fn labelStack() []const u8 {
+    var buf: [16]u8 = undefined;
+    _ = &buf;
+    return buf[0..];
+}
+
+// ✅ Good: caller owns the allocated result and can free it.
+fn label(allocator: std.mem.Allocator) ![]u8 {
+    return try allocator.dupe(u8, "ready");
+}
+```
+
+Review questions:
+- Does returned memory come from the caller, allocator, static storage, or a stable owner?
+- Does a slice escape after its backing buffer is mutated or freed?
+- Is aliasing intentional and documented for mutable slices?
+
+---
+
+## Comptime & Generics
+
+### Keep Comptime Work Bounded and Readable
+
+`comptime` is powerful, but complex compile-time code can make error messages and build times worse. Prefer small generic helpers with clear type contracts.
+
+```zig
+fn RingBuffer(comptime T: type, comptime capacity: usize) type {
+    // ✅ Good: invalid generic parameters fail with an actionable message.
+    if (capacity == 0) @compileError("capacity must be greater than zero");
+
+    return struct {
+        items: [capacity]T = undefined,
+        len: usize = 0,
+    };
+}
+```
+
+Review questions:
+- Does `comptime` enforce a real invariant?
+- Are compile errors explicit and actionable?
+- Is reflection code isolated from ordinary runtime logic?
+
+### Avoid Overly Broad `anytype`
+
+`anytype` can make APIs flexible, but it can also hide required capabilities. Add comptime checks or prefer concrete interfaces when possible.
+
+```zig
+// ✅ Good: the required writer capability is obvious at the call site.
+fn writeAll(writer: anytype, bytes: []const u8) !void {
+    try writer.writeAll(bytes);
+}
+```
+
+Review questions:
+- Is the required shape of `anytype` clear from the function body or docs?
+- Would a concrete type or smaller helper be easier to review?
+- Are compile errors understandable when the wrong type is passed?
+
+---
+
+## Safety, Undefined Behavior & Casts
+
+### Treat `undefined`, `unreachable`, and Casts as Review Hotspots
+
+Zig exposes low-level control directly. Review every `undefined`, `unreachable`, `@ptrCast`, `@alignCast`, `@intCast`, and pointer/int conversion.
+
+```zig
+// ❌ Bad: assumes data layout, byte order, length, and alignment without proof.
+const header: *const Header = @ptrCast(@alignCast(bytes.ptr));
+
+// ✅ Good: parse fields explicitly and check length before reading.
+if (bytes.len < 4) return error.ShortInput;
+const magic = std.mem.readInt(u16, bytes[0..2], .little);
+const flags = std.mem.readInt(u16, bytes[2..4], .little);
+```
+
+Review questions:
+- Is `undefined` overwritten before being read?
+- Is `unreachable` only used for impossible states, with a nearby explanation when non-obvious?
+- Are casts preceded by checks for layout, range, alignment, size, byte order, and nullability?
+
+### Prefer Checked Arithmetic Unless Wrapping Is Intentional
+
+Wrapping operators such as `+%` and `-%` are useful, but they should communicate a deliberate modular arithmetic choice.
+
+```zig
+// ❌ Bad: wrapping silences overflow that should expose a logic bug.
+index = index +% 1;
+
+// ✅ Good: checked arithmetic traps on unexpected overflow.
+sum += byte;
+
+// ✅ Good: wrapping is intentional for modular hash behavior.
+hash = hash *% 16777619;
+hash = hash +% byte;
+```
+
+Review questions:
+- Is wrapping arithmetic required by an algorithm?
+- Would overflow indicate invalid input or a bug?
+- Are integer width changes explicit and tested around boundaries?
+
+---
+
+## C Interop
+
+### Contain C Boundaries
+
+Keep `@cImport`, C pointer handling, and ABI assumptions close to a wrapper layer. Convert C data into Zig types before it spreads through the codebase.
+
+```zig
+const std = @import("std");
+
+// ❌ Bad: uses C strlen when no external C boundary is needed.
+fn strlenC(input: [*:0]const u8) usize {
+    const c = @cImport({
+        @cInclude("string.h");
+    });
+
+    return c.strlen(input);
+}
+
+// ✅ Good: use Zig's sentinel-aware standard library helper.
+fn strlenZ(input: [*:0]const u8) usize {
+    return std.mem.len(input);
+}
+```
+
+Review questions:
+- Are C pointers represented with the correct Zig pointer type?
+- Are sentinel-terminated strings modeled as sentinel pointers or slices?
+- Are ownership and cleanup rules from the C library documented?
+- Are C error codes converted into Zig error unions near the boundary?
+
+---
+
+## Testing
+
+### Use `std.testing` Assertions and Leak Detection
+
+Tests that allocate should use `std.testing.allocator` where practical so leaks are reported by the test runner.
+
+```zig
+const std = @import("std");
+
+test "collect returns owned memory on success" {
+    const allocator = std.testing.allocator;
+    const names = try collect(allocator);
+    defer allocator.free(names);
+
+    try std.testing.expectEqual(@as(usize, 2), names.len);
+}
+
+test "collect handles allocation failures cleanly" {
+    var failing = std.testing.FailingAllocator.init(std.testing.allocator, .{
+        .fail_index = 0,
+    });
+    try std.testing.expectError(error.OutOfMemory, collect(failing.allocator()));
+}
+```
+
+Review questions:
+- Are allocation-heavy paths covered by tests?
+- Are error paths tested with `std.testing.expectError`?
+- Do tests cover boundary sizes such as empty input, one element, max capacity, and invalid encodings?
+
+### Test Build Modes and Targets When Relevant
+
+Behavior can differ across safety modes, targets, and ABIs. For low-level code, ask whether the PR was tested with the intended target and optimization mode.
+
+Review questions:
+- Does code rely on debug-only safety checks?
+- Does packed/aligned/extern layout code have target-aware tests?
+- Are endian, pointer-width, and ABI assumptions tested or documented?
+
+---
+
+## Style & API Design
+
+### Follow Zig Naming Conventions
+
+Use the official style guide as the baseline: `TitleCase` for types, `camelCase` for functions, and `snake_case` for variables. Avoid redundant words such as `Value`, `Data`, `Manager`, or `State` when the surrounding namespace already provides that meaning.
+
+```zig
+// ❌ Bad: redundant namespace and vague type name.
+pub const json_bad = struct {
+    pub const JsonValueManager = struct {};
+};
+
+// ✅ Good: name is meaningful in its fully-qualified namespace.
+pub const json = struct {
+    pub const Value = union(enum) {};
+};
+```
+
+Review questions:
+- Does the fully-qualified name read naturally?
+- Are file and directory names consistent with the style guide?
+- Are underscore-prefixed declarations avoided unless they come from an external convention?
+- Are public APIs documented with doc comments where helpful?
+
+### Keep Public APIs Small
+
+Zig modules often expose declarations directly from files and structs. Review public declarations for accidental exports.
+
+Review questions:
+- Should this declaration be `pub`?
+- Is the public API stable enough to expose?
+- Are implementation details hidden behind a smaller surface?
+
+---
+
+## Review Checklist
+
+### Memory & Lifetime
+- [ ] Allocator ownership is explicit.
+- [ ] Allocations have matching `free`, `deinit`, `defer`, or `errdefer`.
+- [ ] Returned slices and pointers outlive the function.
+- [ ] Arena or temporary allocations have a clear lifetime boundary.
+
+### Errors & Cleanup
+- [ ] Expected failures use specific error sets where practical.
+- [ ] `catch unreachable` does not hide real runtime failures.
+- [ ] Partial initialization is rolled back with `errdefer`.
+- [ ] Error conversions happen at abstraction boundaries.
+
+### Pointers & Safety
+- [ ] Raw pointers are justified; slices are used for ordinary buffers.
+- [ ] Casts check size, range, alignment, and nullability.
+- [ ] `undefined` is not read before initialization.
+- [ ] Wrapping arithmetic is intentional and tested.
+
+### Comptime & API Design
+- [ ] `comptime` logic enforces useful invariants.
+- [ ] `anytype` usage has clear expectations.
+- [ ] Public declarations are intentional.
+- [ ] Names follow Zig style conventions.
+
+### C Interop & Portability
+- [ ] C boundaries are isolated behind wrappers.
+- [ ] C ownership and cleanup rules are documented.
+- [ ] Target, endian, pointer-width, and ABI assumptions are tested or documented.
+
+### Tests
+- [ ] Tests use `std.testing.allocator` for allocation-heavy code.
+- [ ] Error paths use `std.testing.expectError`.
+- [ ] Boundary cases are covered.
+- [ ] Relevant build modes and targets are considered.
+
+---
+
+## References
+
+- [Zig 0.16.0 Language Reference](https://ziglang.org/documentation/0.16.0/)
+- [Zig 0.16.0 Standard Library documentation](https://ziglang.org/documentation/0.16.0/std/)
+- [Zig 0.16.0 Style Guide](https://ziglang.org/documentation/0.16.0/#Style-Guide)
+- [Choosing an Allocator](https://ziglang.org/documentation/0.16.0/#Choosing-an-Allocator)

package/assets/skills/cyclomatic-complexity/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.