- Home
- Skills
- Open Circle
- Valibot
- Repo Source Code Review
repo-source-code-review_skill
- TypeScript
8.4k
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill open-circle/valibot --skill repo-source-code-review- SKILL.md5.5 KB
Overview
This skill reviews pull requests and source code changes under /library/src/. It focuses on code quality, TypeScript type safety, documentation, and test coverage to prevent regressions before merging. The checks are tailored to the library's modular, type-safe patterns and naming conventions.
How this skill works
The skill inspects modified files, verifies patterns against the project's conventions, and flags deviations such as missing purity annotations, wrong import extensions, incomplete JSDoc, or absent type tests. It validates generic constraints, return types, and presence of .test.ts and .test-d.ts files, and reports actionable items for the author to fix.
When to use it
- Reviewing PRs that modify anything in /library/src/
- Validating new APIs or refactors for pattern consistency
- Ensuring type inference and generic constraints are correct
- Checking documentation completeness for exported functions
- Confirming runtime and type test coverage exists before merging
Best practices
- Read the PR description and identify affected APIs before deep inspection
- Ensure exported factory functions have // @__NO_SIDE_EFFECTS__ when pure
- Use interface for object shapes and type for unions/aliases consistently
- Always include explicit return types on exported functions and constrain generics with extends
- Add both runtime (.test.ts) and type (.test-d.ts) tests for new APIs
- Use .ts extension on all local imports and follow established naming patterns (e.g., StringSchema, minLength)
Example use cases
- A PR introducing a new schema factory: verify purity annotation, JSDoc, return type, and both test files are present
- A refactor that changes internal types: ensure generic inference still holds and type tests pass
- A bug fix that alters parse logic: check runtime tests include edge cases and error messages
- A contribution adding helper actions: confirm naming ends in Action, JSDoc first line follows action pattern, and imports use .ts
FAQ
A pure factory creates schema/action objects without mutating globals, performing I/O, or causing side effects. It must be annotated with // @__NO_SIDE_EFFECTS__ before the export.
When is a .test-d.ts required?
Every new or changed public API that affects typing must have a .test-d.ts file covering inference scenarios and expected compile-time behavior using expectTypeOf.