For engineering leaders

The full instrument.

The Technical view is for people who will defend a number in a 1:1. Every score traces to stored evidence. We never rank on volume.

An AI reviewer that knows your systems. Reviews carry your business context, what this repo is, the ticket the change served, and the surrounding code — not just the diff.
Skill inventory and trajectory per person. Strengths, gaps, and whether someone is climbing — from merged work, never from commit counts.
Delivery alignment. Whether the change actually did what the ticket asked, linked automatically even when nobody tagged it.
Monthly architecture reviews. A whole-repo read: layering, debt hotspots, dependency rot, security architecture.
Training built from your team's own PRs, runnable in a sandboxed editor — so feedback ends in practice, not a document.

PR #482 — Migrate payment retries to outbox patternScored

alice@ · payments-core · merged 2h ago

Correctness

Error handling

Testing

Maintainability

Scope discipline

+ if err := tx.Commit(ctx); err != nil { + return fmt.Errorf("outbox enqueue: %w", err)

Why 61 on testing: the retry path has no test covering the double-delivery case introduced at line 141 — exercise generated in Training.

Lead the agent

Your team already directs AI. We teach them to do it well.

We do not detect who used a tool, and we do not rank people on "AI skill." Those numbers are guesses, and a guess your team can dispute is a number they will ignore. What we do instead: NRD Sight already knows what good looks like in this repo. We hand the developer the prompt that would have produced that — and the prompt that fixes what didn't.

Agent brief — standing instructions for this repo: purpose, conventions, business priorities, never-do list. Paste into Cursor, Claude, or Grok project rules.
Start this work — ticket to spec: problem, acceptance, files to read, tests to add, out of scope.
Fix this — a scoped prompt next to every review finding and security issue. Confirm it still exists. Stay in scope. Add the test. Explain the PR.
Practice this — write the spec you would hand an agent for your last weak PR. Get it graded. Copy the rewrite.

The professional bar is the same in every prompt: state the problem first, name the repo by URL, stay scoped, prefer existing helpers, add tests, invent nothing, put no secrets in the paste.

Copy prompt · review finding

I need you to address a code-review finding from a
principal-engineer pass on a merged pull request.

Rules:
- Stay scoped to this finding.
- Confirm the issue still exists.
- Add or update tests where it is behavioral.
- Open a PR that explains the fix in plain language.

**Issue:** Retry without idempotency key can double-capture
**Repository:** https://github.com/acme/payments
**Do this:** Reuse the request's idempotency key on every retry.

Why this prompt: stay scoped, confirm the issue still exists, add tests, and explain the change in the PR.

Will my engineers hate this?

The fastest way to make engineers hate measurement is to measure motion.

We deliberately never rank on volume. Engineers get the same evidence leaders see, their own private growth view, and training built from their own code. The rubric is fixed and visible: the same bar for everyone, with receipts. Praise is public; comparison is private.

Read the methodology →

Every pull request graded — then the prompt that would have scored higher.

The full instrument.

Your team already directs AI. We teach them to do it well.

The fastest way to make engineers hate measurement is to measure motion.

Paste a public pull request. No repo connection required.