loom-code-review-and-quality
Code review is an audit-oriented playbook for changed source and records.
It reviews intent, tests, implementation, risk, and evidence, then routes durable
findings into loom-audit or the consuming ticket.
Core Dependency
Use loom-core first. This playbook composes loom-audit, loom-evidence,
loom-tickets, loom-specs, loom-ralph, and loom-retrospective.
Use This Playbook When
Use this playbook when:
- reviewing a diff, branch, pull request, or worker output
- a ticket appears implementation-complete
- another agent produced code that needs independent review
- refactor, bug fix, package, security, or performance work needs a quality gate
- closure depends on code and evidence telling the same story
Route
Use this route:
intent -> tests -> implementation -> risks -> evidence -> findings -> disposition
Intent
Start from the target record:
- ticket scope and
ACC-*
- spec
REQ-* and SCN-*
- plan execution unit
- packet mission and output
- linked evidence and audit records
Name what the change claims to accomplish before reading for style.
Tests And Evidence
Review tests and evidence before implementation when possible.
Check:
- red/green story when behavior changed
- tests match behavior rather than implementation trivia
- important edge, error, empty, permission, compatibility, and migration states are
covered or explicitly out of scope
- manual, browser, or runtime observations support non-testable claims
- evidence limitations are visible
Create or request loom-evidence when the review needs durable support.
Implementation Axes
Review across:
- correctness: matches spec, acceptance, tests, and source reality
- readability: names, control flow, comments, and local clarity
- architecture: boundaries, dependencies, conventions, and abstraction level
- security: untrusted input, auth, secrets, data exposure, injection, and external
data
- performance: unnecessary work, N+1 patterns, unbounded fetches, hot paths,
browser rendering, and bundle impact
- scope: unrelated cleanup, hidden behavior changes, generated churn, and follow-up
work mixed into the change
Use specialized playbooks for deeper passes: security, performance, browser, API,
or simplification.
Findings
Use loom-audit when findings or verdict should survive.
Material findings should name:
- observed issue
- file/line, record ID, evidence ID, or diff ref
- claim or boundary challenged
- risk or impact
- required follow-up
Low-severity local comments can remain in the review output when no durable record
needs them.
Disposition
The consuming surface owns disposition.
Common routes:
- fixed in current ticket
- accepted residual risk in ticket with authority
- follow-up ticket
- spec update for behavior gap
- evidence update for proof gap
- research for source uncertainty
- constitution for durable policy or precedent
- knowledge promotion after retrospective
Done Means
The review pass is done when:
- intent and evidence were checked before verdict
- material issues have actionable findings or explicit absence
- review scope and uninspected areas are visible
- ticket or audit records carry durable findings when needed
- consuming records decide disposition rather than the review silently closing work
1---2name: loom-code-review-and-quality3description: Use when a code diff, branch, PR, worker output, or implementation-complete ticket needs a code-focused quality review across correctness, tests, architecture, security, performance, scope, and evidence before audit or closure.4---5
6# loom-code-review-and-quality
7
8Code review is an audit-oriented playbook for changed source and records.
9
10It reviews intent, tests, implementation, risk, and evidence, then routes durable
11findings into `loom-audit` or the consuming ticket.
12
13## Core Dependency
14
15Use `loom-core` first. This playbook composes `loom-audit`, `loom-evidence`,
16`loom-tickets`, `loom-specs`, `loom-ralph`, and `loom-retrospective`.
17
18## Use This Playbook When
19
20Use this playbook when:
21
22- reviewing a diff, branch, pull request, or worker output
23- a ticket appears implementation-complete
24- another agent produced code that needs independent review
25- refactor, bug fix, package, security, or performance work needs a quality gate
26- closure depends on code and evidence telling the same story
27
28## Route
29
30Use this route:
31
32```text
33intent -> tests -> implementation -> risks -> evidence -> findings -> disposition
34```
35
36## Intent
37
38Start from the target record:
39
40- ticket scope and `ACC-*`
41- spec `REQ-*` and `SCN-*`
42- plan execution unit
43- packet mission and output
44- linked evidence and audit records
45
46Name what the change claims to accomplish before reading for style.
47
48## Tests And Evidence
49
50Review tests and evidence before implementation when possible.
51
52Check:
53
54- red/green story when behavior changed
55- tests match behavior rather than implementation trivia
56- important edge, error, empty, permission, compatibility, and migration states are
57 covered or explicitly out of scope
58- manual, browser, or runtime observations support non-testable claims
59- evidence limitations are visible
60
61Create or request `loom-evidence` when the review needs durable support.
62
63## Implementation Axes
64
65Review across:
66
67- correctness: matches spec, acceptance, tests, and source reality
68- readability: names, control flow, comments, and local clarity
69- architecture: boundaries, dependencies, conventions, and abstraction level
70- security: untrusted input, auth, secrets, data exposure, injection, and external
71 data
72- performance: unnecessary work, N+1 patterns, unbounded fetches, hot paths,
73 browser rendering, and bundle impact
74- scope: unrelated cleanup, hidden behavior changes, generated churn, and follow-up
75 work mixed into the change
76
77Use specialized playbooks for deeper passes: security, performance, browser, API,
78or simplification.
79
80## Findings
81
82Use `loom-audit` when findings or verdict should survive.
83
84Material findings should name:
85
86- observed issue
87- file/line, record ID, evidence ID, or diff ref
88- claim or boundary challenged
89- risk or impact
90- required follow-up
91
92Low-severity local comments can remain in the review output when no durable record
93needs them.
94
95## Disposition
96
97The consuming surface owns disposition.
98
99Common routes:
100
101- fixed in current ticket
102- accepted residual risk in ticket with authority
103- follow-up ticket
104- spec update for behavior gap
105- evidence update for proof gap
106- research for source uncertainty
107- constitution for durable policy or precedent
108- knowledge promotion after retrospective
109
110## Done Means
111
112The review pass is done when:
113
114- intent and evidence were checked before verdict
115- material issues have actionable findings or explicit absence
116- review scope and uninspected areas are visible
117- ticket or audit records carry durable findings when needed
118- consuming records decide disposition rather than the review silently closing work
aibot88