القائمة
Review code changes for quality, design, and maintainability. Use when reviewing pull requests, code changes, or performing code reviews. Applies general engineering code review standards.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Generates commit messages following Conventional Commits 1.0.0 specification. Use when the user asks to commit changes, write commit messages, or when staging and committing code changes.
Initialize and configure multi-project memory bank structure. Use when the user asks to set up a memory bank, initialize project context, or create the .memory-bank directory.
Creates and reviews documentation embedded in source code including doc comments, API documentation, and inline documentation. Use when writing code documentation, reviewing doc quality, or adding examples to code.
Creates and manages project-level documentation including READMEs, tutorials, how-to guides, and architectural docs. Use when creating user-facing documentation, writing tutorials, or organizing project documentation following Diataxis framework.
Review Rust code changes for safety, idioms, and patterns. Use when reviewing Rust code, checking ownership and lifetimes, unsafe blocks, error handling, or Rust-specific patterns like builders and typestate.
Enforces Rust development policies including zero warnings, static dispatch preference, minimal Arc usage, and comprehensive testing requirements. Use when reviewing Rust code, writing new Rust code, or checking compliance with project policies.
| name | review-codes |
| description | Review code changes for quality, design, and maintainability. Use when reviewing pull requests, code changes, or performing code reviews. Applies general engineering code review standards. |
| license | MIT |
| compatibility | opencode |
| metadata | {"focus":"code-review","type":"generic"} |
Review code changes following the project's Code Review Process Guidelines.
Use this skill when:
Read the code review process guidelines:
.aiassisted/guidelines/engineering/code-review-process.mdFind the primary files with significant logical changes. Review these first to understand context.
Communicate major design issues immediately - don't wait until reviewing all files.
Check each area from the guidelines:
| Area | What to Check |
|---|---|
| Design | Do interactions make sense? Right place in codebase? |
| Functionality | Does it work as intended? Edge cases? Concurrency issues? |
| Complexity | Is it more complex than necessary? Over-engineered? |
| Testing | Appropriate tests? Will they catch regressions? |
| Naming | Descriptive? Follows conventions? |
| Comments | Explain "why" not "what"? Accurate? |
| Style | Follows style guide? Consistent? |
| Documentation | README/API docs updated if needed? |
Format your review using severity labels:
**Nit:** Consider renaming `x` to `userCount` for clarity.
**Optional:** This could use early return to reduce nesting.
**FYI:** The new `async/await` syntax simplifies this pattern.
This function has a potential null pointer issue on line 42.
**Blocking:** This introduces a SQL injection vulnerability.
| Label | Meaning |
|---|---|
| Nit: | Minor suggestion, optional |
| Optional: | Consider this, not required |
| FYI: | Educational, no action needed |
| (no label) | Should be addressed before approval |
| Blocking: | Must be fixed before merge |
Approve when:
Request Changes when:
Approve a change once it definitely improves the overall code health of the system, even if it is not perfect.
Balance developer velocity with code quality. Reviews should be collaborative, not adversarial.
The complete code review process is documented in:
.aiassisted/guidelines/engineering/code-review-process.md
Always load and follow the guidelines as the authoritative source.