General engineering
AuraScore 83/100

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.

Template

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

  1. Analyze {{codebase_footprint}} to derive required task graph capabilities (e.g., remote caching, incremental builds, package scoping).
  2. Define critical evaluation axes: language interoperability with {{core_tech_stack}}, local developer experience, CI execution speed, maintenance overhead, and license cost.
  3. Evaluate how effectively each option in {{candidate_tools}} mitigates {{build_pain_points}}.
  4. Assess remote cache infrastructure requirements against {{cloud_ci_budget}}.
  5. Populate a scoring matrix comparing performance, integration complexity, and operational overhead.
  6. Detail migration friction and learning curve for {{developer_seat_count}} contributors.
  7. 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}}?
AuraScore breakdown
83/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency7/10 · Adequate

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-general
research-productivity-operations
developer-experience
build-systems
monorepo