Monorepo Build Tooling Selection Matrix
Evaluate monorepo task runners and distributed build systems against developer productivity metrics.
Use this template when selecting or migrating monorepo orchestration tools across multi-language engineering organizations. It produces a clear feature-and-performance matrix to accelerate consensus among technical leads.
Role: Staff Developer Productivity Engineer specializing in distributed build architecture and CI/CD optimization.
Context
- Repository scale and volume: {{codebase_footprint}}
- Primary language ecosystems: {{core_tech_stack}}
- Existing pipeline bottlenecks: {{build_pain_points}}
- Candidate build orchestrators: {{candidate_tools}}
- Cloud CI infrastructure budget: {{cloud_ci_budget}}
- Target engineering team size: {{developer_seat_count}}
Task
Construct a comprehensive build system comparison matrix evaluating {{candidate_tools}} to resolve {{build_pain_points}} across {{core_tech_stack}} while maintaining efficiency for {{developer_seat_count}} engineers.
Method
- Analyze {{codebase_footprint}} to derive required task graph capabilities (e.g., remote caching, incremental builds, package scoping).
- Define critical evaluation axes: language interoperability with {{core_tech_stack}}, local developer experience, CI execution speed, maintenance overhead, and license cost.
- Evaluate how effectively each option in {{candidate_tools}} mitigates {{build_pain_points}}.
- Assess remote cache infrastructure requirements against {{cloud_ci_budget}}.
- Populate a scoring matrix comparing performance, integration complexity, and operational overhead.
- Detail migration friction and learning curve for {{developer_seat_count}} contributors.
- Provide a definitive tool recommendation with a phased adoption outline.
Constraints
- MUST deliver comparison data in a Markdown matrix format with explicit scoring criteria.
- MUST NOT recommend solutions that do not natively support all languages in {{core_tech_stack}}.
- Financial projections MUST stay strictly within {{cloud_ci_budget}}.
- Maintain an objective, vendor-agnostic tone focusing on deterministic build execution.
Output format
- Core Assessment Matrix (Markdown table with columns: Capability/Dimension, Weight, Candidate Ratings [Poor/Adequate/Strong], Justification Summary)
- Cost & Infrastructure Impact Table (Comparison of storage, compute overhead, and vendor fees)
- Final Recommendation & Migration Strategy (Numbered 4-step rollout plan)
Self-review
- Are all bottlenecks mentioned in {{build_pain_points}} directly targeted in the matrix?
- Is the scoring tailored specifically to {{codebase_footprint}} rather than generic benchmarks?
- Does the recommended tool fit within {{cloud_ci_budget}}?
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.