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:
| 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.
1---2name: code-review3description: Use when reviewing Basic Machines code for house style, architecture risk, pre-merge hardening, or whether a change fits basic-memory/basic-memory-cloud conventions.4license: MIT5---6
7# Basic Machines Review
8
9Use this skill for repo-local review passes where ordinary code review needs Basic Machines
10house style and architecture judgment. Report findings only; do not edit code unless the user
11asks you to fix specific findings.
12
13## Scope
14
15Review the current diff or named files against:
16
17- The repo's `AGENTS.md` / `CLAUDE.md`
18- `docs/ENGINEERING_STYLE.md`
19- The touched code paths and tests
20
21Apply only the guidance for the active repo. In `basic-memory`, prioritize local-first
22file/database/MCP boundaries. In `basic-memory-cloud`, prioritize tenant/workspace isolation,
23cloud worker behavior, and web-v2 state/runtime boundaries.
24
25## Review Rubric
26
27Report only concrete, falsifiable risks:
28
29- **Cognitive load:** Is the change harder to understand than the problem requires?
30- **Change propagation:** Will one product change force edits across unrelated layers?
31- **Knowledge duplication:** Is the same rule encoded in multiple places that can drift?
32- **Accidental complexity:** Did the change add abstractions, fallbacks, or state without need?
33- **Dependency direction:** Are API/MCP/CLI, services, repositories, and UI stores respecting
34 their intended boundaries?
35- **Domain model distortion:** Do names and types still match the product concept, or did a
36 transport/storage detail leak into the domain?
37- **Test oracle quality:** Would the tests fail for the bug or regression the change claims to
38 protect against?
39
40## House Rules To Check Explicitly
41
42- No speculative `getattr(obj, "attr", default)` for unknown model shapes.
43- No broad exception swallowing, warning-only failure paths, or hidden fallback behavior.
44- No casts or `Any` that hide an unclear type relationship.
45- Dataclasses for internal value/result objects; Pydantic at validation/serialization
46 boundaries.
47- Narrow `Protocol`s when only a capability is needed.
48- Explicit async/resource ownership, cancellation, and cleanup.
49- Meaningful regression tests or verification for risky changes.
50- Comments explain why, not what.
51
52## Reporting Format
53
54Lead with findings ordered by severity. Each finding should include:
55
56| Severity | Use for |
57| -------- | ------- |
58| `high` | A likely correctness, security, data-loss, or tenant/workspace isolation failure |
59| `medium` | A concrete maintainability or boundary risk that can cause future defects |
60| `low` | A minor consistency issue, ambiguous guidance, or review-only cleanup |
61
62```text
63severity | file:line | risk category | claim
64Why: concrete behavior or code path that proves the risk.
65Fix: smallest practical change, or "none obvious" if the risk needs product input.
66```
67
68If there are no findings, say so and note any verification gaps that remain.
basicmachines-co