/code-standards
Code quality standards and style guide for reviewing pull requests
$ npx -y skills add mastra-ai/mastra --skill code-standards --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/code-standards
Context preview
The summary Claude sees to decide when to auto-load this skill.
Code quality standards and style guide for reviewing pull requests
SKILL.md
code-standards.SKILL.mdname: code-standards
description: Code quality standards and style guide for reviewing pull requests
version: 1.0.0
metadata:
tags:
- code-review
- quality
- styleCode Standards Review
When reviewing code, follow this structured process:
Step 1: Critical Issues
Check for issues that MUST be fixed before merging:
- Logic bugs and incorrect behavior
- Missing error handling for failure cases
- Race conditions or concurrency issues
- Unhandled edge cases (null, undefined, empty arrays, boundary values)
- Breaking API changes without migration path
Step 2: Code Quality
Evaluate overall code quality:
- Functions should do one thing and be reasonably sized (< 50 lines preferred)
- Avoid code duplication — look for repeated patterns that should be abstracted
- Use descriptive, meaningful names for variables, functions, and types
- Prefer explicit types over `any` in TypeScript
- Ensure proper use of async/await (no floating promises, proper error propagation)
Step 3: Style Guide Conformance
Check against the style guide in `references/style-guide.md`:
- Naming conventions
- Code organization and import ordering
- Comment quality (explain "why", not "what")
Step 4: Linting Flags
Flag these patterns:
- `var` usage (should be `const` or `let`)
- Leftover `console.log` or `debugger` statements
- Commented-out code blocks
- Magic numbers without named constants
- `TODO` or `FIXME` comments without issue references
Output Format
Structure your feedback as:
1. **Summary**: 1-2 sentence overview of the changes and overall quality 2. **Critical Issues**: Must-fix problems with file path and line numbers 3. **Suggestions**: Improvements that would make the code better 4. **Positive Notes**: Good patterns and decisions worth acknowledging
Read more
name: code-standards
description: Code quality standards and style guide for reviewing pull requests
version: 1.0.0
metadata:
tags:
- code-review
- quality
- styleCode Standards Review
When reviewing code, follow this structured process:
Step 1: Critical Issues
Check for issues that MUST be fixed before merging:
- Logic bugs and incorrect behavior
- Missing error handling for failure cases
- Race conditions or concurrency issues
- Unhandled edge cases (null, undefined, empty arrays, boundary values)
- Breaking API changes without migration path
Step 2: Code Quality
Evaluate overall code quality:
- Functions should do one thing and be reasonably sized (< 50 lines preferred)
- Avoid code duplication — look for repeated patterns that should be abstracted
- Use descriptive, meaningful names for variables, functions, and types
- Prefer explicit types over `any` in TypeScript
- Ensure proper use of async/await (no floating promises, proper error propagation)
Step 3: Style Guide Conformance
Check against the style guide in `references/style-guide.md`:
- Naming conventions
- Code organization and import ordering
- Comment quality (explain "why", not "what")
Step 4: Linting Flags
Flag these patterns:
- `var` usage (should be `const` or `let`)
- Leftover `console.log` or `debugger` statements
- Commented-out code blocks
- Magic numbers without named constants
- `TODO` or `FIXME` comments without issue references
Output Format
Structure your feedback as:
1. **Summary**: 1-2 sentence overview of the changes and overall quality 2. **Critical Issues**: Must-fix problems with file path and line numbers 3. **Suggestions**: Improvements that would make the code better 4. **Positive Notes**: Good patterns and decisions worth acknowledging
Mastra is a framework for building AI-powered applications and agents with a modern TypeScript stack. It includes everything you need to go from early prototypes to production-ready applications.
Repo: mastra-ai/mastra
Other skills on mastra.
- /builder-smoke-test
Smoke test the Agent Builder feature branch end-to-end against a hermetic project scaffolded by the skill (linked to the current worktree). Covers workspace reconciliation, stored agents/skills CRUD, ownership, visibility, stars, registry/library Copy flow, picker allowlists,
Open skill - /debugging-difficult-bugs
Use early when debugging a medium or hard bug, especially when tests alone may not reveal the real runtime failure. Trigger this before extended TDD iteration when a bug involves runtime state, ordering, persistence, streaming, concurrency, UI/manual reproduction, external
Open skill - /docs-audit
Interactive documentation quality review for Mastra docs. Use when auditing, reviewing, or critiquing Mastra documentation; checking docs against source code; validating code examples, API accuracy, or property completeness; checking whether docs follow the styleguide and
Open skill - /e2e-tests-studio
REQUIRED when modifying any file in packages/playground-ui or packages/playground. Triggers on: React component creation/modification/refactoring, UI changes, new playground features, bug fixes affecting studio UI. Generates Playwright E2E tests that validate PRODUCT BEHAVIOR,
Open skill - /mastra-docs
Documentation guidelines for Mastra. This skill should be used when writing or editing documentation for Mastra. Triggers on tasks involving documentation creation or updates.
Open skill - /mastra-frontend
How to build Mastra frontend interfaces with the @mastra/playground-ui design system. This skill should be used when creating or modifying any application UI — pages, components, styling, or tokens — in this repo or in an external consumer of the design system. The docs site has
Open skill

