# Bep Engineering Review

> Review a concrete software change for outcome correctness, engineering risk, and contract impact. Not an automatic implementation pass.

- Skill: `saltbo/bep-engineering-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add saltbo/bep-engineering-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/saltbo/bep-engineering-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: saltbo (https://skillmd.com/u/saltbo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/saltbo/bep-engineering-review

---


# Engineering Review

Remain read-only for a review-only request. If the user also asks to resolve
findings, that authorization includes in-scope fixes and local acceptance.
Apply BEP preferences directly to new projects. For existing projects, evaluate
against their established conventions and support promises; distinguish a
preference difference from a correctness, security, or compatibility defect.

Review on two independent axes:

1. **Outcome:** compare observable behavior with the request, authorized scope,
   supported contracts, and migration expectations.
2. **Engineering:** compare the implementation with repository conventions and
   only the narrow engineering skills relevant to the changed boundaries.

Classify each non-mechanical change before choosing review depth:

- **High risk:** public or cross-service contracts; authentication,
  authorization, security, or privacy; money, billing, credit, or quota;
  persisted data or migration; concurrency, transactions, distributed work;
  production delivery or another hard-to-reverse decision.
- **Low risk:** localized, reversible, internal, and none of the high-risk
  conditions.
- **Medium risk:** every other non-mechanical change.

Verify every finding against the artifact. Classify severity independently from
scope: `blocking` means the requested outcome is wrong or incomplete, a
supported contract breaks, security or data integrity is at risk, or an
applicable configured gate fails; otherwise it is `non-blocking`. A finding is
`in-scope` only when the current request authorizes its resolution.

Lead with findings ordered by severity and include precise file and line
locations. Then state assumptions, unanswered questions, verification evidence,
and a concise change summary. If there are no findings, say so and identify any
remaining test or review limitation.