Code Review
- 106 installs
- 3.6k repo stars
- Updated August 5, 2026
- basicmachines-co/basic-memory
code-review is a Claude skill that runs a repo-local pre-merge review pass for Basic Machines code, reporting architecture and boundary risks by severity.
About
This skill runs a code-review pass on a diff or named files for the Basic Machines repos (basic-memory, basic-memory-cloud). It applies the repo's house-style and architecture rules, then reports only concrete, falsifiable risks ordered by severity. A developer uses it before merging a change to check boundary direction, accidental complexity, and test quality.
- Repo-local pre-merge review pass tuned to Basic Machines house style and architecture rules
- Reports findings by severity (high/medium/low) with why + smallest fix; never edits code unless asked
- Checks boundary, complexity, and test-oracle risks against AGENTS.md/CLAUDE.md and ENGINEERING_STYLE.md
Code Review by the numbers
- 106 all-time installs (skills.sh)
- Ranked #440 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
code-review capabilities & compatibility
- Capabilities
- code review · architecture review · pre merge check
- Use cases
- code review · refactoring
What code-review says it does
Report findings only; do not edit code unless the user asks you to fix specific findings.
Report only concrete, falsifiable risks:
npx skills add https://github.com/basicmachines-co/basic-memory --skill code-reviewAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 106 |
|---|---|
| repo stars | ★ 3.6k |
| Last updated | August 5, 2026 |
| Repository | basicmachines-co/basic-memory ↗ |
What it does
Review a Basic Machines diff for house-style and architecture risk before merging.
Who is it for?
Pre-merge review of a change in basic-memory or basic-memory-cloud against house style and architecture boundaries.
Skip if: General code review outside the Basic Machines repos, or auto-fixing findings.
When should I use this skill?
Reviewing a Basic Machines diff for architecture risk or pre-merge hardening.
What you get
A severity-ordered list of concrete, falsifiable risks with why and the smallest fix.
By the numbers
- 7-point review rubric
- 3 severity levels (high/medium/low)
Files
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
Anythat 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:
| Severity | Use for |
|---|---|
high | A likely correctness, security, data-loss, or tenant/workspace isolation failure |
medium | A concrete maintainability or boundary risk that can cause future defects |
low | A 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.
Related skills
Improve Codebase ArchitectureSafely deepen clusters of shallow modules into cohesive, testable units while respecting their external dependencies.566k196k
Caveman ReviewGet ultra-compressed, one-line code review comments that cut noise while keeping every actionable fix.270k94.7kCodebase DesignShared vocabulary for designing deep modules: improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable.266k196kCavecrewDelegate coding tasks to specialized subagents that return compressed output, keeping the main context window usable for much longer sessions.220k94.7kCode ReviewReviews a branch or PR diff on two axes at once: conformance to coding standards plus a code-smell baseline, and whether it actually implements the original spec.201k196k
Requesting Code ReviewDispatch a consistent, high-signal code reviewer subagent that catches plan deviations and quality issues before merging or continuing development.183k264kFAQ
Does this skill edit my code?
No. It reports findings only and does not edit code unless the user asks to fix specific findings.
What does it review against?
The repo's AGENTS.md/CLAUDE.md, docs/ENGINEERING_STYLE.md, and the touched code paths and tests.