Performance reviews with evidence: Git and Jira data for better 1:1s

Performance reviews are one of the hardest parts of being a Team Lead. I struggle with two things: assessing each team member fairly, and remembering what they achieved, fought with and contributed over a whole quarter. Memory is selective. Last week beats last March. Visible work beats quiet work. And a strong personal impression starts to feel like an objective fact the longer you carry it around.

So before my last round of 1:1s I gave Claude Code read-only access to our GitLab and Jira and asked it to collect evidence. This post is the long version of a short LinkedIn post: the prompts I used, the metrics that came out of it, and the skill I turned it into so a colleague could run the same thing for their team. One rule up front, for this post and for the process: no names, no real numbers. Everything below describes the method, not the people.

The setup

The important decision was not technical. I did not ask for a ranking. I asked for material for a conversation, and I wrote down first what kind of conversation I wanted. This was the very first prompt of the session, with the aliases and goal screenshots removed:

I want to do 1:1 meetings with discussion on goals. I have those with the users <a>, <b> and <c>.
Can you use my gitlab PAT and my JIRA token to check what they worked on

<a> goals: [Image #1]  […]

so what I need are 3 files under <my notes folder> with the 3-8 concrete questions I should ask.
A nice overview of the goals. placeholders to take notes in ".md"

Please take into account that

1. I like to have a leisure conversation to get to know more about the personal career situation of my employees
2. I really want to know how they like our working style, their projects
3. I want to know where they want to develop themselves in the next half year
4. I want to clearly communicate the goals we set
5. I want honest feedback on my working style and how we can improve that to make their lives better

My overall leadership strategy is servant leadership, meaning I try to remove barriers and hope trust
in people makes them productive. I need some numbers of my employees in case it comes to comparison, raises.

So good numbers are
1) How many issues they contributed to - story points
2) How many different topics did they work on
3) How much interaction were they showing with other co-workers (I can come up with an own scale)
4) ... Please make proposals to my list such that I can take this

These numbers I want to clearly report to them

Questions? Proposals?

Two things made this prompt work. The five conversation goals ended up, almost one to one, as the five sections of every 1:1 file. And „Questions? Proposals?“ at the end turned Claude from an executor into a sparring partner: it came back with additional signals before it wrote a single line of code. „These numbers I want to clearly report to them“ set the tone for everything after it. If you would be embarrassed to show a metric to the person it describes, it should not be in there.

Steering the metrics

The first pass only looked at the obvious repositories, so I widened it („we also need backend and <product> and devops repos. but simply check user git activity“). Then came the prompt where my own knowledge of the team mattered more than the data:

yes, I need a raise sheet. I need some soft factors I can evaluate them on, such as I asked you for proposals.
[…]
yes, please pull epic and issue titles to check there is no duplicated dummy stuff and some just get
higher rates because they rename epics more often. Time tracking I can just discuss in one other question

So Claude came up with some nice hard metrics, that I reviewed and improved.

nice. collaboration score needs also "MRs reviewed". "Comments in MRs", any other proposal on code? Line lifetime maybe

Reviews and MR comments went in hard facts. Line lifetime did not: it needs blame data across every repository over time, it is slow, and like code churn it says more about the kind of code someone touches than about its quality. I dropped it and do not miss it.

The metric definitions

This is what the gather script actually computes per person for the review window (calendar year to date by default). All of it comes from the Jira search API and the GitLab user events API:

DELIVERY (Jira, issues assigned and updated in the window)
  issues worked          all assigned issues touched in the window
  issues done            status category = done
  story points (done)    "Story Points" field, looked up by name, summed over done issues
  bugs                   issues of type Bug
  wins                   top 5 epics by story points, with 3 example issue titles each

DELIVERY (GitLab events)
  MRs opened / merged    "opened" / "accepted" events on merge requests
  commits                commit_count of push events            -> context only, never ranked

BREADTH
  epics, Jira projects   distinct epics and projects of the assigned issues
  repos, namespaces      distinct GitLab projects with any event, grouped by top-level group

COLLABORATION
  MRs reviewed for others  MRs the person approved or commented on, whose author is someone else
  comments in MRs          comment events on merge requests
  approvals                "approved" events
  teammates helped         distinct authors of those MRs
  issues for others        issues the person created that someone else is assigned to
  review depth             MR comments / MRs reviewed for others  -> style signal, not quality

  collaboration score = MRs reviewed for others + MR comments + approvals + issues for others

SOFT FACTORS (manager input, 1 = concern … 5 = role model)
  Ownership & follow-through, Autonomy / low-maintenance, Reliability / predictability,
  Communication & transparency, Attitude & resilience

Every chart in the dashboard carries its own warning where one is due. Commits: „NOT comparable, work-style artifact“.


Story points: „uncalibrated team estimate, trend not truth“. Issues raised for others: „managers and leads inflate this via delegation, not peer review“.

What the data did to my assumptions

It challenged several of them. The person I thought of as the super-helper really did help a lot of others, and the data made it easier to say that their own delivery needed more focus.


The cross-team contributor looked less active inside our team, because much of their impact happened in other teams‘ repositories; the breadth metrics showed that, the team-only view hid it.


And the one I privately called the code machine was in fact delivering at the level I had perceived.


The team was super happy to see their hard-metrics shipped to them. Because in your day to day life, you sometimes forget how much great stuff you produce. Seeing you did 100 MR reviews for 5 different teams, gives you back confidence, that you are needed here.


Sometimes your gut is right, and it is still nice to check.

What went wrong, or could have

• The first pass missed whole groups of repositories until I told it to include the backend and devops repositories. The GitLab events API also only shows what your token can see. Check the namespaces list per person before you trust any total.
• Story points are only comparable inside one team with one estimation habit. Across teams they are noise.
• The composite collaboration score is a sum of four counts. It is useful for spotting a pattern and useless as a grade. I kept it because it started good conversations, not because it measures anything precisely.
• Goals are not in Jira. The 1:1 file has a placeholder and the skill reminds you to paste them in.

If you want to try it

• Write down the conversation you want before you ask for numbers. The numbers then fit the conversation, not the other way round.
• Use read-only tokens and keep everything local. A comparison dashboard of real people does not belong in a shared drive, a chat or a cloud artifact.
• Put the caveat next to the metric, in the chart, where you cannot skip it.
• Let the model propose, but give the judgment calls (soft factors, what counts as gaming) back to yourself explicitly.
• Share each person’s own data with them and nobody else’s. That was the best part: we discussed what the numbers reflected, what they missed, and whether my reading matched their experience.

AI did not make a single performance decision here. It gave me structured evidence instead of a fuzzy memory, showed me contribution patterns I had not seen, and made me ask better questions. Not replacing judgment, but giving it something solid to stand on.

Related Posts

Tutorial: An app in R shiny visualizing biopsy data — in a pharmaceutical company

3D GPS data animation – virtually climb the Alps