Code review as a repeatable workflow
The review system checks changes for security, performance, correctness, maintainability, missing tests, and regression risk before work is treated as ready.
AI review tooling
Engineering Review Plugin
A reusable review system for AI-assisted engineering work. The plugin and related review habits turn code review, testing strategy, deployment checks, architecture review, and documentation review into repeatable workflows.
What It Does
The plugin makes review repeatable.
The page explains the AI-review tooling behind the builds: not a product for sale, but part of the way the work gets made credible.
Testing strategy as product thinking
The test lens asks what needs to be proven: business-critical paths, error handling, edge cases, security boundaries, and data integrity.
Deploy checklists as controls
The deploy lens turns release work into a checklist: CI, review, migration readiness, preview verification, rollback triggers, and production smoke checks.
Workflow
The review workflow turns AI output into inspected work.
A generated answer is the start of the process. The review system asks what could break, what was missed, and what needs to be proven before the result matters.
1
A change is made with AI assistance
Claude or Codex may help draft code, docs, or implementation steps. That is the construction surface, not the final control.
2
The relevant review lens is selected
Code review, testing strategy, deployment checklist, architecture review, debugging, documentation, or tech-debt review is used depending on what changed.
3
The review asks concrete questions
What can break? What is untested? Is authorization safe? Are claims supported? Does the architecture match the problem? What should a future reviewer be able to inspect?
4
Findings become fixes or explicit limits
The output is not just a list of concerns. It becomes code fixes, stronger tests, clearer docs, accepted limitations, or a decision to hold the change.
5
The final artifact keeps the trail
Commits, PR descriptions, build checks, docs, and production verification make the review visible after the chat is gone.
Controls
The control is a named review habit, not a vibe check.
A portfolio reader should see that the same review habits keep showing up: run the gates, inspect the diff, review the risk, document the limit, and verify the result.
Review discipline becomes tooling
The useful move is turning repeated review habits into reusable skills and checklists. The control does not depend on remembering the same prompt every time.
The reviewer looks for failure modes
Security gaps, race conditions, missing edge cases, N+1 queries, stale docs, unsafe deploys, and unsupported claims are treated as review targets.
Local to preview to production
The review system supports the same promotion pattern across the site work: verify locally, deploy to preview, then promote to production and verify the public page.
Technology
The stack tells the product story.
These pages are not replacing the private repositories. They summarize what a reviewer would see there: the architecture choices, evidence surfaces, tests, and boundaries behind the build.
Plugin skills
- Code review for security, performance, correctness, and maintainability
- Testing strategy for unit, integration, end-to-end, accessibility, and edge coverage
- Deploy checklist for pre-deploy, deploy, post-deploy, and rollback criteria
- Architecture, debugging, documentation, incident-response, standup, and tech-debt skills
Review surfaces
- Claude Code and Claude CLI for repo work
- Codex / ChatGPT as independent review surfaces
- GitHub PRs as the visible review trail
- Local browser, preview, and production checks
Deterministic gates
- Lint, format, typecheck, tests, and production builds
- Browser checks where the interface matters
- Branch protection and CI
- Explicit production verification after merge
Why this matters
- AI can accelerate building, but acceleration increases the need for review
- Reusable review lenses make the process consistent
- Portfolio-grade work needs evidence, not just a working screen
- Review artifacts show how the work improves over time
Repository Signals
What the repository contains.
For now, the repositories stay private while the public site explains the work. These notes summarize the files, routes, docs, checks, and review artifacts without exposing private configuration, credentials, or organization-specific data.
The engineering plugin is important because it turns review discipline into a reusable operating surface: code review, testing, deploy checks, architecture, debugging, documentation, and technical-debt review.
The public point is not that a plugin exists. The point is that AI-assisted work is being checked through named review lenses instead of accepted because it looks polished.
The same pattern shows up across the site: local checks, preview deploys, PRs, production verification, and explicit discussion of what is still bounded or private.
This is part of the broader AI-apprenticeship story: learning to build faster while also learning how to make the work inspectable.