vouchington-tooling 0.1.9 → 0.3.0

package/skills/postgres-partitioning-uuid-v7/references/partition-lifecycle.md

@@ -0,0 +1,14 @@
+# Partition lifecycle
+
+UUIDv7 ordering supports range bounds and index-friendly time windows. Generate bounds from time
+instead of extracting timestamps in predicates; use a generated timestamp only when application
+semantics require one. Partition on the range key that queries and retention actually constrain.
+
+Create future ranges before writes need them and maintain a default partition only with an explicit
+attachment plan. Before attaching a populated range, prove the default partition excludes that range
+or move conflicting rows; otherwise attachment can scan and lock the default partition.
+
+Every primary or unique constraint on a partitioned table must include its partition key. Verify
+pruning with predicates on that key, including joins whose other side needs an equivalent range
+condition. UUIDv7 values are time ordered, not a promise that independently generated identifiers
+have a strict ordering relationship.

package/skills/storybook-authoring/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: storybook-authoring
+description: Add maintainable Storybook stories and browser-mode component coverage.
+---
+
+# Storybook authoring
+
+Create stories that show meaningful supported states with realistic args and fixtures. Keep story
+data local and deterministic, expose important visual or interaction variants, and add browser-mode
+coverage where it catches behavior unavailable to unit tests. Do not use stories as a substitute for
+end-to-end setup or production data handling.
+
+Consumer wrappers own Storybook configuration, exclusions, visual baselines, and commands.
+
+Read [component coverage](references/component-coverage.md) for direct stories and browser isolation.

package/skills/storybook-authoring/references/component-coverage.md

@@ -0,0 +1,9 @@
+# Component coverage
+
+Keep a direct story for each supported reusable component state. When a component needs server-only
+modules, request context, or browser-hostile imports, isolate the presentational surface or alias the
+boundary to a deterministic fixture. Test interactive story behavior in browser mode when it owns
+the component contract.
+
+Allow story discovery to follow the consumer's module graph and glob configuration. Do not hand
+maintain duplicate registration lists or make module-top-level browser assumptions.

package/skills/swift-test-authoring/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: swift-test-authoring
+description: Add Swift and SwiftUI tests with deterministic state, networking, and view inspection.
+---
+
+# Swift test authoring
+
+Test public behavior with deterministic inputs and injected dependencies. For SwiftUI, inspect or
+interact through the project's supported test approach; for networking, use a protocol-level test
+double and keep request/response synchronization explicit. Avoid sleeps and global state, and keep
+fixtures small enough to make failures readable.
+
+Consumer wrappers own test targets, coverage thresholds, view-inspection libraries, and fixture APIs.
+
+Read [network test doubles](references/network-test-doubles.md) for cancellation and shared-state safety.

package/skills/swift-test-authoring/references/network-test-doubles.md

@@ -0,0 +1,9 @@
+# Network test doubles
+
+Delayed URLProtocol callbacks must honor `stopLoading()`: guard delivery with synchronized stopped
+state so cancellation cannot call a released client. Keep shared response and captured-request state
+private behind one synchronization boundary, reset related fields atomically, and expose coherent
+snapshots for assertions.
+
+Avoid sleeping to coordinate tests. Inject scheduling or await explicit completion so networking,
+view state, and cancellation remain deterministic under parallel execution.

package/skills/test-authoring/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: test-authoring
+description: Write focused, maintainable tests and test fixtures for application or library behavior.
+---
+
+# Test authoring
+
+Use the repository's test conventions and runner skill. Test observable behavior, boundary failures,
+and regressions rather than implementation details. Build fixtures through public constructors or
+documented helpers; keep data minimal, explicit, and representative. Add a focused failing test
+before a behavior change when practical, then run the narrowest relevant test and required checks.
+
+Do not invent project test commands, coverage targets, mock libraries, or integration environments.
+A consumer wrapper owns those choices.
+
+Read [core practice](references/core-practice.md) for the shared boundary, completion, and evidence
+rules before choosing a runner-specific approach.

package/skills/test-authoring/references/core-practice.md

@@ -0,0 +1,10 @@
+# Core test practice
+
+Choose the lowest realistic boundary that can observe the contract. Mock external systems and
+uncontrolled infrastructure; exercise internal module composition where practical. Test behavior,
+failure paths, authorization, and security-relevant validation rather than private calls.
+
+Start with a failing test when the behavior is testable. Finish only when the production path, its
+public contract, documentation, and generated artifacts move together. Do not leave placeholders or
+test-only production branches. For every acceptance criterion, retain evidence from a focused test,
+review, or explicitly justified manual check.

package/skills/vitest-test-authoring/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: vitest-test-authoring
+description: Apply Vitest-specific patterns when adding or changing Vitest tests, mocks, or fixtures.
+---
+
+# Vitest test authoring
+
+Apply [test-authoring](../test-authoring/SKILL.md) first. Keep tests isolated with Vitest lifecycle
+hooks, restore spies and globals after each test, and prefer deterministic async assertions over
+timing waits. Mock external boundaries rather than modules under test, and use typed factories when
+the project supplies them. Run the selected file or project before broader validation.
+
+Consumer wrappers own project selection, mock boundaries, fixture names, and coverage policy.
+
+Read [mock boundaries](references/mock-boundaries.md) when adding module mocks or changing exports.

package/skills/vitest-test-authoring/references/mock-boundaries.md

@@ -0,0 +1,9 @@
+# Mock boundaries
+
+Mock providers, transports, clocks, and environment boundaries rather than application modules.
+When a module mock is necessary, preserve its runtime export shape, type the factory against the
+real module, and spread actual exports unless omission is intentional. Update static factories when
+the mocked module gains an export.
+
+Prefer spies or dependency injection for a narrow seam. Restore mocks, environment, and globals
+after each test so a test cannot alter another test's module graph or process state.