Team process
What the git history says about how the team works
Git history records more than code. It records how long changes wait for review, how large they are, how often they are reverted, who can unblock whom, and which parts of the system only one person understands. This package reads those signals across six categories and reports them as properties of the process — never as a score for a person.
It is also explicit about what git cannot tell you. A Data Integrity category checks for identity fragmentation, the effects of squash and rebase, signs of gaming, and the work that never touches the repository, so the other five categories are read with their limits known.
Team Review
Free
Team and up · included with your license
Engineering leads and agencies who want to know where the process is slow or fragile before a retrospective turns into opinions — and who need the analysis to be defensibly about the team, not about anyone on it.
What runs
The workflows inside
Team Check Assessment
Six category workflows run as child instances — Volume Signals, Flow and Cycle-Time Signals, Quality and Durability Signals, Collaboration Signals, Ownership and Risk Signals, and Data Integrity — each checking every item in its own step with cited commands and figures, then a compile step that dedupes and ranks the findings into process-level recommendations.
How a run goes
Step by step, in the order the engine enforces
- 1
Choose the repository and the window
The assessment runs over a time window you set, against the git history and forge data where it is available.
- 2
Six categories, each item a step
Volume, flow, quality, collaboration, ownership and data integrity. For each item the agent gathers evidence with the command it ran and the figure it got, decides violated, passed or not assessable, and records it.
- 3
Reviewed at team level
Findings loop through review until they pass. Signals are aggregated as team and process properties; the workflow is built so that individual performance scores cannot fall out of it.
- 4
A process report, not a scoreboard
The compile step dedupes across categories and writes recommendations about the process — review latency, change size, bus factor — with the data-integrity caveats alongside.
What you get
At the end of a run
- ✓A team-process report across six categories, each item with its evidence and verdict
- ✓Process-level recommendations with severity and effort
- ✓A data-integrity section stating what the history can and cannot support
Read next
Related packages
- Code as Crime Scene →
The forensic investigation from Your Code as a Crime Scene — hotspots, complexity trends, temporal coupling, knowledge maps, churn — run by your coding agent.