team-assembly

Selects the minimum reviewer team for a change based on touched paths and risk.

4.4k|154|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/fallow-rs/fallow --skill team-assembly
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: team-assembly
Source: https://github.com/fallow-rs/fallow/tree/main/.agents/skills/team-assembly
Command: npx skills add https://github.com/fallow-rs/fallow --skill team-assembly

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Choosing the right reviewers for a code change is often guesswork: too few reviewers miss contract or integration risks, while too many slow down the review cycle. This Skill maps a diff to the reviewer domains it actually touches so every change gets complete, non-redundant coverage.

Core Features & Use Cases

  • Path-to-reviewer mapping: Reads the current diff together with the review-routing documentation to match touched files and behavioral effects to reviewer domains.
  • Cross-cutting detection: Includes additional reviewers when contracts change or multiple consumers are affected, even if filenames alone would not suggest it.
  • Parallel review coordination: Runs independent reviews in parallel where reviewer files do not overlap, then synthesizes verdicts without replacing blocking concerns with majority votes.
  • Use Case: A pull request modifies a shared API contract and two consumer packages. The Skill identifies contract, integration, and consumer-domain reviewers, briefs each with the diff and controlling plan, and merges their verdicts into one review outcome.

Quick Start

Assemble the reviewer team for the current diff using the review-routing documentation and brief each reviewer on their domain.

Frequently Asked Questions about team-assembly

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose reviewers for a pull request?

Map the diff's touched paths and behavioral effects to reviewer domains defined in your review-routing documentation. Include cross-cutting reviewers when contracts or multiple consumers change, rather than selecting reviewers from filenames alone.

How to assign reviewers based on changed files?

Read the current diff and a routing document that links paths to reviewer domains, then match each touched file to its domain. Behavior affecting additional consumers should expand the team beyond what filenames suggest.

Can code reviews run in parallel across multiple reviewers?

Yes, independent reviews can run in parallel when the reviewers' files do not overlap. Each reviewer is briefed with the diff, the controlling plan, and the primary source files for their domain.

When should a change get extra reviewers beyond the file owners?

Add cross-cutting reviewers when the change modifies shared contracts or affects multiple consumers. Filename-based selection alone misses behavioral impact on downstream code.

How are conflicting reviewer verdicts resolved?

Verdicts are synthesized into a single outcome without replacing blocking concerns with majority votes. A blocking review stands even if other reviewers approve.