style-checker

name	style-checker
description	Enforces this monorepo's coding style rules by inspecting git diffs, reading .agents/skills/style-checker/references/style_guidance.md, fixing style violations, and reporting the result. Use when the user asks to check style, review codebase style, clean up a diff, verify coding conventions, or before completing any coding task in this repository.
compatibility	Designed for coding agents working inside a git monorepo with shell access, file read access, and file editing tools.
allowed-tools	Bash(git:*) Bash(cargo:*) Bash(npm:*) Bash(pnpm:*) Bash(yarn:*) Read Edit MultiEdit

Style Checker

You are an expert code reviewer enforcing this monorepo's local style rules.

Run this skill when asked to check style, review coding conventions, clean up a diff, or before finishing any coding task in this repository.

Core Rule

Always review the changed code against the repository's canonical style guide:

.agents/skills/style-checker/references/style_guidance.md

That file is the source of truth. If these instructions conflict with .agents/skills/style-checker/references/style_guidance.md, follow .agents/skills/style-checker/references/style_guidance.md.

Workflow

1. Inspect the current changes

Determine what changed before reviewing style.

Run the narrowest useful git commands, typically:

git status --short
git diff
git diff --cached

Review only changed files and changed lines unless the style guide requires broader context.

Do not perform unrelated cleanup.

2. Read the style guide

Read:

.agents/skills/style-checker/references/style_guidance.md

Use it to evaluate the diff. Do not rely only on general language or framework conventions.

3. Analyze the diff

Compare the changed code against .agents/skills/style-checker/references/style_guidance.md.

Pay special attention to these monorepo expectations.

Rust

Check changed Rust code for:

• Custom library error types, preferably using thiserror, where typed errors are appropriate.
• No naked unwrap() or expect() in production paths.
• Intentional error handling or propagation for fallible operations.
• Appropriate //! or /// documentation for public modules, public types, and important public functions.
• Consistency with nearby crate conventions for errors, logging, async behavior, and public APIs.

TypeScript

Check changed TypeScript code for:

• NodeNext-compatible relative imports with explicit .js extensions where required.
• readonly arrays, tuples, and object shapes where immutability is intended or required by project convention.
• No newly introduced implicit any.
• Explicit types at module boundaries and public APIs.
• No weakening of strictness, type safety, or existing lint expectations.

4. Fix violations directly

If you find a style violation, edit the affected file immediately.

Use the smallest safe fix. Prefer targeted edits over broad rewrites.

Good fixes include:

• Replacing unwrap() with proper error propagation.
• Adding or refining a typed error enum.
• Adding missing .js extensions to TypeScript relative imports.
• Adding readonly where required.
• Adding public documentation required by the style guide.
• Tightening an implicit or overly broad type.

Avoid:

• Reformatting unrelated code.
• Renaming symbols for preference only.
• Refactoring outside the changed area.
• Applying generic best practices that are not supported by the repo guidance.

5. Re-check the diff

After editing, inspect the diff again.

Confirm that:

• The style issue is fixed.
• The edit is minimal.
• No unrelated changes were introduced.
• The code still follows nearby patterns.

6. Run relevant validation

When practical, run the narrowest relevant validation command for the changed files.

Prefer project-specific commands from package scripts, justfiles, makefiles, cargo configs, or repo documentation.

Possible commands include:

cargo fmt
cargo clippy
cargo test
npm run typecheck
npm run lint
npm test
pnpm typecheck
pnpm lint
pnpm test
yarn typecheck
yarn lint
yarn test

Do not run expensive full-repo checks when a narrower check is available.

If validation cannot be run, explain why.

Reporting

At the end, report clearly and briefly.

Include:

• Whether the style check passed.
• What style issues were found.
• What files were changed.
• What validation commands were run.
• Any validation that could not be run.

If no issues were found, say exactly:

Style check passed; no changes were needed.

If fixes were made, summarize them in plain language.

Example:

Style check completed. I fixed two TypeScript style issues in lib/web/src/client.ts: added NodeNext .js import extensions and made the exported config map readonly. I ran pnpm typecheck and it passed.

Constraints

• Always read .agents/skills/style-checker/references/style_guidance.md before enforcing style.
• Review the diff, not the whole repository.
• Fix style violations directly when safe.
• Keep changes minimal and local to the relevant diff.
• Do not invent new conventions.
• Do not ignore the style check before completing coding work.
• If .agents/skills/style-checker/references/style_guidance.md is missing, report that the canonical style guide could not be found and apply only conservative checks based on nearby code.