Engineer Self-Reviews From GitHub and Jira, Without AI Slop

The self-review that starts from "write a performance review for a senior engineer" comes back fluent, kind, and useless. Your manager has read that paragraph. It was about someone else.

A useful draft has a narrower job. It finds the work, holds it up against anchors you agreed in advance, and stops before it awards the point.

Anchors beat adjectives

"Strong engineer" is not a review. A behavioral anchor is a sentence a teammate could disagree with by pointing at a change.

The built-in Engineering 360 form, under Performance → Forms → New form, uses a 4-point scale labelled Below, Partly meets, Meets, and Exceeds. On code quality the four meanings are:

Changes often need significant rework.

Solid with guidance in review.

Clear, tested and easy to change.

Sets the standard the team follows.

Technical design, delivery and reliability, code review, and knowledge sharing use the same shape. Self, peer, and manager answer most of them. Delivery is asked of the person and their manager, not of peers, because a peer did not own the on-call week. The written close is one question: one thing to focus on next quarter. Upward questions, for people who manage, stay anonymous and are a different instrument.

Pick the anchor the evidence supports, not the one that sounds like a promotion case. "Clear, tested and easy to change" is Meets. It is a good quarter. Exceeds is "sets the standard the team follows," which means other people's reviews got shorter because of how you worked, not because you closed a lot of tickets.

Not sure is a real answer, and it never counts as a rating. Use it when you cannot name the event. A guessed Meets is worse than a blank.

Pull requests are a map, not a mark

Forty merged pull requests can be a quarter of rework, which is the bottom anchor, or a quarter of small, reviewed, boring changes, which is often the job. Four pull requests can be the design the rest of the platform copied. The count tells you where to look. It does not tell you which sentence is true.

Treat a Jira ticket the same way. "Done" is a status someone clicked. The review sentence is what changed for a user, a caller, or the person who gets paged. If you cannot say that in two sentences, you do not have a rating yet. You have a search result.

Two filters before anything goes in the draft. Leave, health, family, and "they were around a lot" stay out. Availability is not performance, and it is a terrible proxy for it. And do not compare people. "Better than the other senior on the team" is a calibration argument wearing a self-review.

Freeze the goals before the quarter ends

The other way a Q4 review goes soft is goalpost drift. In October the goal was "move 20 services." In January, after the review opens, someone edits it to "move the important services" and the quarter looks tidy.

When a round opens, the review copies up to five goals that belonged to the period: not dropped, and open or closed on or after the period started. You and your manager rate each one Missed, Partly met, Met, or Exceeded against the progress recorded at opening. A later update does not change the copy. Close the goal as Done a week after opening and the review still shows the number it opened with. The argument happens against a snapshot, not against the story you prefer once you know how it ends.

People with no goals in the period skip the section. Goals are optional. A team that does not set them should not invent five on the Sunday before the review.

What the assistant is for

Used as a search tool, an assistant earns its place. Used as the author, it writes the paragraph your manager has already learned to skip. The split is mechanical.

1. Open the self-review from Performance → To do and choose the Agent tab.
2. Copy request and send it to Claude, or whichever assistant you connected.
3. Name the accounts, repositories, or projects it may search. It should search the review period. GitHub's date filter includes both ends and uses UTC, so say the dates out loud rather than "this quarter."
4. It reads the questions with get_review_context, then saves wording and links with save_review_draft. It can suggest a point. It cannot set one, and it cannot submit, share, or finish the review.
5. Use this wording copies a suggestion into your answer. Ratings are not copied. You pick every point, confirm the assessment is yours, and submit. Submitting deletes the draft.

The recipe it is given says counts of pull requests, tickets, or hours help it find work, and it must not rate on them. That recipe is an instruction. The control is smaller and harder: there is no tool that writes the rating or presses submit. A save can still warn you when a suggested point has no evidence. Read the warning.

Then apply the one-minute test. For every sentence, can you name the change, the incident, or the review comment behind it? If yes, the assistant saved you the scavenger hunt. If no, delete the sentence. A link you did not open is not evidence.

Help me draft my Q4 2026 self review in SquadBear. Find it with get_my_work, call get_review_context, follow its recipe, and save with save_review_draft. Search only the API repository I name. I pick every rating and submit it myself.

The longer argument for keeping pay, feedback, and the written record in different meetings is performance reviews without the theater. What an assistant is allowed to operate, outside reviews, is running HR through your own assistant.

Start free for up to 5 people, or open the demo and read a self-review before you ask anything to draft one.