agentleFS
fritzprixfritzprix/libr-agent/.agents/skills/libragent-quality/SKILL.md

libragent-quality

Skill11 starsChanged 20 days agoMITView on GitHub

Code quality validation for LibrAgent project. Use when performing code quality checks, refactoring validation, or ensuring code meets project standards for TypeScript/React frontend and Rust backend. Runs comprehensive validation including linting, formatting, type checking, build verification, and dead code detection.

  • Installs packages

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 9 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before every install, scripts/enforce-pnpm-version.cjs rejects other pnpm versions (for example pnpm 11 regenerating the lockfile without …

    line 26
  2. Distinctive:

    Vitest: - Test suite execution

    line 100
  3. Distinctive:

    Wait for all checks to pass.

    line 117
  4. Very specific:

    Never use any: - Use precise types, unknown with type guards, or generics

    line 145
  5. Distinctive:

    No inline import types: - Use proper import statements at top of file

    line 148
  6. Very specific:

    Use rustfmt: - Always format before committing

    line 152
  7. Very specific:

    Fix clippy warnings: - No warnings allowed (-D warnings in CI)

    line 153
  8. Very specific:

    Handle errors explicitly: - Use Result<T, E> types

    line 154
  9. Very specific:

    Document public APIs: - Use /// doc comments

    line 155
  10. Very specific:

    Compound components: - Use patterns like Chat.Header, Chat.Messages

    line 161
  11. Very specific:

    Check .eslintrc.js or eslint.config.js for rules.

    line 168
  12. Very specific:

    Run pnpm format to auto-fix formatting issues.

    line 172
  13. Distinctive:

    Read clippy suggestions carefully - they often indicate actual bugs or improvements.

    line 176
  14. Very specific:

    Check TypeScript errors: tsc --noEmit

    line 180
  15. Very specific:

    Check Rust errors: cd src-tauri && cargo check

    line 181
  16. Distinctive:

    All tests must pass

    line 196
  17. Distinctive:

    No dead code (with approved exceptions)

    line 197
  18. Distinctive:

    Run validation early and often: - Don't wait until PR time

    line 201
  19. Distinctive:

    Keep tests passing: - Don't commit broken tests

    line 204
  20. Distinctive:

    Document exceptions: - If you must disable a rule, explain why

    line 205

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

LibrAgent Code Quality Validation

This skill provides comprehensive code quality validation for the LibrAgent project, which uses a dual-stack architecture with React/TypeScript frontend and Rust/Tauri backend.

Quick Start

For complete validation before commits or PRs:

pnpm refactor:validate

This runs all checks in sequence and ensures code quality across the entire stack.

It also runs pnpm lockfile:check (pnpm install --frozen-lockfile) to match CI dependency installation.

Package Manager Pin

  • package.json declares "packageManager": "pnpm@9.15.9" and "engines.pnpm": "9.15.9".
  • Before every install, scripts/enforce-pnpm-version.cjs rejects other pnpm versions (for example pnpm 11 regenerating the lockfile without overrides).
  • Local setup:
corepack enable
corepack prepare pnpm@9.15.9 --activate
pnpm install --frozen-lockfile

Individual Validation Commands

Frontend (TypeScript/React)

# Linting - Check code style and potential errors
pnpm lint

# Format checking
pnpm format:check

# Lockfile / CI parity check
pnpm lockfile:check

# Auto-fix formatting issues
pnpm format

# Type checking and build
pnpm build

# Dead code detection
pnpm dead-code

# Run tests
pnpm test:run

Backend (Rust)

# Format checking
pnpm rust:fmt:check

# Auto-format Rust code
pnpm rust:fmt

# Lint with clippy
pnpm rust:clippy

# Type checking
pnpm rust:check

# Check with all features
pnpm rust:check:all

# Run tests — full suite is sequential (OOM-safe); prefer --test while iterating
pnpm rust:test
pnpm rust:test --test text_encoding_tests
# Modules under tests/integration/ live in the integration_tests binary:
pnpm rust:test --test integration_tests -- workspace_skill_access_regression_tests

# Run tests (edit-file-only build; anchor/editFile regression)
pnpm rust:test:edit-file

# Complete Rust validation
pnpm rust:validate

Complete Validation Pipeline

The refactor:validate command executes:

  1. ESLint - JavaScript/TypeScript code quality
  2. Prettier - Code formatting consistency
  3. Lockfile check - pnpm install --frozen-lockfile (CI parity)
  4. Vitest - Test suite execution
  5. Rust fmt - Rust code formatting
  6. Rust clippy - Rust linting
  7. Rust check - Rust compilation check with all features
  8. Rust test - Rust test suite (default workspace-str-replace build)
  9. Rust test (edit-file) - Rust test suite with --no-default-features --features workspace-edit-file
  10. Vite build - Production build verification
  11. Unimported - Unused code detection

Common Validation Scenarios

Before Committing

pnpm refactor:validate

Wait for all checks to pass. Fix any errors reported.

Quick Frontend Check

pnpm lint && pnpm format && pnpm build

Quick Backend Check

pnpm rust:validate

Fix Formatting Issues

# Fix frontend formatting
pnpm format

# Fix Rust formatting
pnpm rust:fmt

Critical Project Rules

TypeScript Rules

  1. Never use any - Use precise types, unknown with type guards, or generics
  2. No ESLint-disable comments - Fix the underlying issue instead
  3. Use centralized logger - getLogger('ComponentName') not console.*
  4. No inline import types - Use proper import statements at top of file

Rust Rules

  1. Use rustfmt - Always format before committing
  2. Fix clippy warnings - No warnings allowed (-D warnings in CI)
  3. Handle errors explicitly - Use Result<T, E> types
  4. Document public APIs - Use /// doc comments

Architecture Rules

  1. Feature-based organization - Components in src/features/
  2. Service layer pattern - Business logic in src/lib/
  3. Compound components - Use patterns like Chat.Header, Chat.Messages
  4. Type safety - Define interfaces in src/models/

Troubleshooting

ESLint Errors

Check .eslintrc.js or eslint.config.js for rules. Fix code to match standards.

Prettier Conflicts

Run pnpm format to auto-fix formatting issues.

Rust Clippy Warnings

Read clippy suggestions carefully - they often indicate actual bugs or improvements.

Build Failures

  1. Check TypeScript errors: tsc --noEmit
  2. Check Rust errors: cd src-tauri && cargo check
  3. Verify dependencies: pnpm install

Dead Code Detection

Review unimported output. Remove unused exports or add to ignore list if intentional.

Integration with CI/CD

The project uses GitHub Actions for CI. All validation commands must pass before merge:

  • ESLint must pass
  • Prettier formatting must be correct
  • TypeScript must compile without errors
  • Rust must compile without warnings
  • All tests must pass
  • No dead code (with approved exceptions)

Best Practices

  1. Run validation early and often - Don't wait until PR time
  2. Fix issues incrementally - Easier to debug when changes are small
  3. Read error messages carefully - They often contain the solution
  4. Keep tests passing - Don't commit broken tests
  5. Document exceptions - If you must disable a rule, explain why

Reference

For detailed project guidelines, see:

  • .github/copilot-instructions.md - Complete coding standards
  • agents.md - Agent-specific guidelines
  • docs/architecture/ - Architecture documentation
  • CONTRIBUTING.md - Contribution guidelines

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.