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: basic-machines-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---67# Basic Machines Review89Use this skill for repo-local review passes where ordinary code review needs Basic Machines10house style and architecture judgment. Report findings only; do not edit code unless the user11asks you to fix specific findings.1213## Scope1415Review the current diff or named files against:1617- The repo's `AGENTS.md` / `CLAUDE.md`18- `docs/ENGINEERING_STYLE.md`19- The touched code paths and tests2021Apply only the guidance for the active repo. In `basic-memory`, prioritize local-first22file/database/MCP boundaries. In `basic-memory-cloud`, prioritize tenant/workspace isolation,23cloud worker behavior, and web-v2 state/runtime boundaries.2425## Review Rubric2627Report only concrete, falsifiable risks:2829- **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 respecting34 their intended boundaries?35- **Domain model distortion:** Do names and types still match the product concept, or did a36 transport/storage detail leak into the domain?37- **Test oracle quality:** Would the tests fail for the bug or regression the change claims to38 protect against?3940## House Rules To Check Explicitly4142- 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/serialization46 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.5152## Reporting Format5354Lead with findings ordered by severity. Each finding should include:5556| 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 |6162```text63severity | file:line | risk category | claim64Why: concrete behavior or code path that proves the risk.65Fix: smallest practical change, or "none obvious" if the risk needs product input.66```6768If there are no findings, say so and note any verification gaps that remain.
tuyv