Work Signal Sources
Connect GitLab so AI review drafts cite real shipped work. Fetch-on-demand, privacy-scoped, opt-in per draft, never a surveillance warehouse.
Why It Matters
Reviews written from memory systematically undercount quiet, consistent shippers and overcount whoever was visible in the last month. The fix is letting the AI drafter cite real work at draft time: the merge requests someone shipped and the reviews they gave others, as titles and links a human reviewer then weighs.
Kit fetches work signals on demand when the reviewer opts in for a draft. It does not maintain a separate raw activity database. It does retain a digest of used signals on the review, including titles, links, dates, repositories, and AI-related annotations. There is no productivity leaderboard or cross-employee activity comparison view.
Warning
Signals produce narrative evidence, never scores. No volume metrics or diff stats are collected, no cross-person comparison surface exists, and fetching is opt-in per draft. Discuss the sources with the reviewee. This feature is not a productivity leaderboard.
Connecting GitLab
GitLab is the v0 provider (one connection per account). Go to Performance > Work signals:
| Field | Value |
|---|---|
| GitLab URL |
https://gitlab.com, or your self-hosted instance’s URL; self-hosted is supported (HTTPS, publicly reachable host) |
| Group access token | A read_api Group Access Token with the Reporter role, or a service-account PAT on the Free tier |
Press Connect GitLab. The token is encrypted at rest and shown only masked afterwards. Kit uses read-only API access; it never writes to your GitLab. If the connection later errors (revoked token, unreachable host), the source trips to Error with the failure message shown; re-enter credentials to reconnect. If a fetch fails during drafting, the draft uses the remaining sources and notes the unavailable source. Later drafts skip a source in Error state until you reconnect it.
Confirming Identities
Signals are fetched per person, so each team member must be mapped to their GitLab username, and the mapping must be confirmed by an admin before it’s used. This is the fence against the obvious failure: a typo’d username must never pull a stranger’s activity into someone’s review. Unconfirmed mappings are refused at fetch time.
Under Identity mapping, add each member’s GitLab username (Kit prefills a suggestion by looking the person up by email on your GitLab where it can), then confirm it. Members without a confirmed mapping are silently skipped when drafting; nothing is fetched for them.
What Is Gathered
At draft time, with the per-draft opt-in ticked, Kit fetches for the review period (the cycle’s period, or the last 6 months if unset):
| Signal | Meaning |
|---|---|
| Merged merge requests | Work the person shipped |
| Review activity | MRs the person reviewed for others, glue work most tools ignore |
Each signal includes title, link, date, and repo, plus the activity kind and annotations described below. No diff sizes, no line counts, no commit frequencies. Two AI-era annotations are derived on the fly: AI authorship (commit trailers like Assisted-by:/Co-Authored-By: naming coding agents; the drafter credits direction and review rigor, never inflated volume) and AI-enablement work (changes to skills, agent configs, MCP tools, prompts; work the drafter is instructed to credit explicitly).
Opt-in, Disclosure, and Refusal
- Per-draft opt-in: signals are used only when the reviewer ticks “Include work signals from GitLab (opt-in for this draft).” Never by default, never covertly.
- Source disclosure: the reviewer sees retained titles, links, dates, and repositories beside the draft. The reviewee does not automatically have access to this panel in someone else’s review. Discuss the sources with them before finalization.
- Human gate downstream: a signal-informed draft still faces the edit-or-own submission gate; signals inform a human’s assessment, they never become one.
- Tool-invisible work has a channel: the self-review’s Your own notes field exists because mentoring, incidents, and unblocking others don’t show up in a code host.
Note
For German tenants: works-council co-determination (BetrVG §87(1) Nr. 6) covers systems capable of monitoring performance. Involve your works council before connecting a source.
Quick Checklist
- Create a read_api Group Access Token (Reporter) in GitLab
- Connect it in Performance > Work signals, gitlab.com or self-hosted
- Map and confirm each member’s GitLab username
- Tell the team signals exist and are opt-in per draft, with no covert use
- Remind reviewees to use Your own notes for work GitLab can’t see
Next Steps
- AI-Drafted Reviews: where signals surface
- Performance Reviews Overview: how the signal layer fits the whole module