mcpField
C
code-review

code-review

github.com/basicmachines-coTesting & quality4.4k120 installsUpdated 1d ago
Repository

About code-review

A repository-local code review skill for Basic Machines projects. It checks changes against repository guidance and architecture, reports concrete risks, and avoids editing code unless requested.

Key features

  1. 01Checks diffs or named files against repository guidance
  2. 02Applies repo-specific architecture priorities
  3. 03Reports falsifiable findings by severity
  4. 04Includes focused review rules and output format
  5. 05Avoids code edits unless requested

Use cases

  1. 01Reviewing a change in basic-memory
  2. 02Reviewing cloud isolation and worker changes
  3. 03Checking tests and architectural boundaries

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/basicmachines-co/basic-memory --skill code-review

After installing, type/code-reviewin Claude Code to confirm it loaded.

Details

From the project README

Basic Machines Review

Use this skill for repo-local review passes where ordinary code review needs Basic Machines house style and architecture judgment. Report findings only; do not edit code unless the user asks you to fix specific findings.

Scope

Review the current diff or named files against:

  • The repo's AGENTS.md / CLAUDE.md
  • docs/ENGINEERING_STYLE.md
  • The touched code paths and tests

Apply only the guidance for the active repo. In basic-memory, prioritize local-first file/database/MCP boundaries. In basic-memory-cloud, prioritize tenant/workspace isolation, cloud worker behavior, and web-v2 state/runtime boundaries.

Review Rubric

Report only concrete, falsifiable risks:

  • Cognitive load: Is the change harder to understand than the problem requires?
  • Change propagation: Will one product change force edits across unrelated layers?
  • Knowledge duplication: Is the same rule encoded in multiple places that can drift?
  • Accidental complexity: Did the change add abstractions, fallbacks, or state without need?
  • Dependency direction: Are API/MCP/CLI, services, repositories, and UI stores respecting their intended boundaries?
  • Domain model distortion: Do names and types still match the product concept, or did a transport/storage detail leak into the domain?
  • Test oracle quality: Would the tests fail for the bug or regression the change claims to protect against?

House Rules To Check Explicitly

  • No speculative getattr(obj, "attr", default) for unknown model shapes.
  • No broad exception swallowing, warning-only failure paths, or hidden fallback behavior.
  • No casts or Any that hide an unclear type relationship.
  • Dataclasses for internal value/result objects; Pydantic at validation/serialization boundaries.
  • Narrow Protocols when only a capability is needed.
  • Explicit async/resource ownership, cancellation, and cleanup.
  • Meaningful regression tests or verification for risky changes.
  • Comments explain why, not what.

Reporting Format

Lead with findings ordered by severity. Each finding should include:

SeverityUse for
highA likely correctness, security, data-loss, or tenant/workspace isolation failure
mediumA concrete maintainability or boundary risk that can cause future defects
lowA minor consistency issue, ambiguous guidance, or review-only cleanup
severity | file:line | risk category | claim
Why: concrete behavior or code path that proves the risk.
Fix: smallest practical change, or "none obvious" if the risk needs product input.

If there are no findings, say so and note any verification gaps that remain.

Comments

Markdown supported