---
name: code-review-and-quality
description: "Seven-axis code review with staff engineer standard, including entropy reduction and runtime robustness. Invoke before merging changes, when user says /review, or when reviewing code quality. | 七轴代码审查（含熵减合规性和运行时健壮性），对标高级工程师标准。合并变更前、用户说 /review 或审查代码质量时触发。"
metadata:
  {
    "builtin_skill_version": "1.0",
    "xingzierai":
      {
        "emoji": "🔍",
        "requires": {}
      }
  }
---
# Code Review and Quality

Seven-axis review. Would a staff engineer approve this?

## Overview

Code review is not rubber-stamping—it's the last line of defense before code reaches production. Every review should answer: "Would I approve this if I were the author and the reviewer were a skeptical staff engineer?"

The seven axes of code review:
1. **Correctness** — Does it do what it claims?
2. **Security** — Can it be exploited?
3. **Performance** — Will it scale?
4. **Maintainability** — Can others understand and modify it?
5. **Test Coverage** — Are the right things tested?
6. **Entropy Reduction** — Does this change reduce or increase system entropy?
7. **Runtime Robustness** — Does it degrade gracefully when services are unavailable?

## When to Use

**Activate this skill when:**
- User says `/review` or asks to "review code"
- Before merging any change
- After implementation is complete
- When asked "is this ready to ship?"

**Do not activate for:**
- Draft/unfinished work (say "not ready for review")
- Already reviewed code (unless re-review requested)

## Process

### Step 1: Understand the Context

1. Read the `SPEC.md` and `PLAN.md`
2. Understand what the change is supposed to do
3. Identify the files that changed

### Step 2: Review Each Axis

For each changed file, evaluate:

**Axis 1: Correctness**
- Does the code do what the spec requires?
- Are edge cases handled?
- Are error cases handled properly?

**Axis 2: Security**
- Is user input validated?
- Are secrets handled properly?
- Could this be exploited?

**Axis 3: Performance**
- Are there obvious N+1 queries?
- Are large data structures handled efficiently?
- Are caches used where appropriate?

**Axis 4: Maintainability**
- Is the code clear and readable?
- Are functions small and single-purpose?
- Is there appropriate documentation?

**Axis 5: Test Coverage**
- Are happy paths tested?
- Are failure cases tested?
- Do tests actually verify behavior?

**Axis 6: Entropy Reduction Compliance**

Based on the Entropy Reduction Architecture (docs/ENTROPY_REDUCTION_ARCHITECTURE.html):

| Check | Iron Law | Blocking? |
|-------|----------|-----------|
| File exceeds 400 lines? | 2. Compartmentalization | Yes |
| New `any` types introduced? | 3. Negative Entropy Flow | No (Nit) |
| Silent catch blocks? | 5. Information Conservation | Yes |
| Inline `isDark` ternary styles? | 1. Openness First | No (Nit) |
| Global variables introduced? | 2. Compartmentalization | Yes |
| `!important` used? | 7. Delta First | No (Nit) |
| Irreversible operations? | 4. Reversibility | No (Nit) |
| No tests for logic changes? | 3. Negative Entropy Flow | No (Nit) |

**Axis 7: Runtime Robustness**

Code must degrade gracefully when runtime environment is non-ideal (services unavailable, network errors, config missing, dependency failures).

| Check | Blocking? |
|-------|-----------|
| Backend unavailable: does frontend show "Service unavailable" instead of misleading error? | Yes |
| Error messages point to the actual root cause, not an unrelated config? | Yes |
| API response type mismatch (backend returns Object, frontend expects Array) is caught? | Yes |
| Environment variable missing: is there a reasonable default? | No (FYI) |
| Service startup dependency is detectable by frontend? | No (Nit) |
| Network transient failure: is there automatic retry? | No (Nit) |
| Error messages include status code + response preview for debugging? | No (Nit) |

### Step 3: Severity Labels

Label each finding:

| Severity | Meaning | Action |
|----------|---------|--------|
| **Blocking** | Must fix before merge | Request changes |
| **Nit/Optional** | Minor, doesn't block | Comment, author decides |
| **FYI** | Informational | Just informing |

### Step 4: Provide Feedback

Review format:

```markdown
## Review: [Feature Name]

### Summary
Brief summary of the change.

### Files Changed
- `file1.py`
- `file2.py`

### Findings

#### [Blocking] Issue description
Explanation of why it's blocking.

#### [Nit] Minor issue
Explanation, optional to fix.

### Entropy Assessment
- Entropy Impact: RED (increasing) / YELLOW (neutral) / GREEN (reducing)
- Violated Iron Laws: [list numbers]
- Entropy Index Change:
  - Structural: 8.5 -> 8.6 UP (new oversized file)
  - Information: 7.8 -> 7.7 DOWN (eliminated 3 any)
  - Thermodynamic: 7.5 -> 7.5 (no change)
  - Cognitive: 9.0 -> 9.0 (no change)
  - Style: 8.2 -> 8.2 (no change)
- Reduction Suggestions: [specific suggestions]

### Runtime Robustness Assessment
- Backend Unavailable: ✅ Graceful / 🔴 Misleading Error
- Error Messages: ✅ Accurate / ⚠️ Could Mislead
- API Type Safety: ✅ Type Guards / 🔴 Unsafe Cast
- Network Resilience: ✅ Retry Logic / ⚠️ No Retry

### Approval
- [ ] Approved
- [ ] Request Changes

### Notes
Any additional context.
```

### Step 5: Change Sizing

If a diff is too large, request splitting:

- **Ideal**: ~100 lines diff
- **Acceptable**: ~200 lines diff
- **Too large**: >500 lines -> request split

## The Entropy Reduction Iron Law for Reviews

**Every code change must have net entropy change <= 0 (at minimum, do not increase entropy)**

This is derived from: `dS_system = dS_internal + dS_exchange`
- `dS_internal >= 0` (natural code decay, unavoidable)
- `dS_exchange` can be negative (negative entropy flow: types, tests, tokens)
- Entropy reduction requires: `dS_exchange < -dS_internal`

## Rationalizations

| Excuse | Rebuttal |
|--------|----------|
| "It's just a small change" | Small changes break production too. Review all of them. |
| "Tests pass, so it's fine" | Tests can only verify what they're written for. |
| "The author knows better" | Reviewers share responsibility for shipped code. |
| "I don't have time to review thoroughly" | Take time or request someone else. |

## Red Flags

- No tests with new code
- Blocking issues not addressed in next review
- Diff over 500 lines
- Security issues in authentication/authorization
- Performance issues in hot paths
- Magic numbers without constants
- Net entropy increase without justification

## Verification

**Evidence that code review is working:**

- [ ] Review requested before merge
- [ ] All blocking issues addressed
- [ ] Tests added for new functionality
- [ ] No obvious security vulnerabilities
- [ ] Code is clear and maintainable
- [ ] Diff size is reasonable (<200 lines)
- [ ] Net entropy change <= 0
