# Selective Build Test

> Use this skill whenever preparing local or CI execution to build and test only the impacted components identified by change impact analysis, while preserving quality gates and correctness.

- Skill: `mcj-coder/selective-build-test` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mcj-coder/selective-build-test`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mcj-coder/selective-build-test/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mcj-coder (https://skillmd.com/u/mcj-coder)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/mcj-coder/selective-build-test

---


# Selective Build & Test Planning

## Intent

Plan and execute only the necessary builds and tests for impacted components,
based on an explicit impact assessment, while maintaining full quality and
correctness standards. This includes using monorepo-aware tooling to ensure
only affected code is re-verified, keeping feedback loops fast.

---

## When to Use

- Before local build/test runs in a monorepo.
- When configuring or reviewing CI behaviour for incremental execution.
- When optimising feedback loops without weakening standards.
- **Always** in multi-component projects to avoid redundant work.

---

## Precondition Failure Signal

- Full repo builds/tests run for small changes.
- Monorepo tooling (e.g., Nx, Turborepo) is present but not used or configured incorrectly.
- Incremental runs miss required tests for impacted components.
- Developers bypass checks because “it takes too long.”
- CI outputs cannot explain why a component did/did not run.

---

## Postcondition Success Signal

- Build/test matrix includes all and only impacted components.
- Tooling correctly identifies "affected" projects based on git graph.
- Required transitive tests are included where dependencies demand it.
- Quality gates remain unchanged; only the scope is reduced.
- Execution is reproducible and reviewable from the same inputs.

---

## Process

1. **Source Review**: Inspect the impact set produced by `incremental-change-impact` and determine the appropriate testing tier (UnitTest, SystemTest, ComponentE2E, E2E, ArchitectureTest) based on the current execution stage (Dev, Pre-commit, Pre-push, CI/CD).
2. **Discovery & Implementation**:
    - Identify the correct monorepo tool (e.g., Nx, Turborepo) for the project stack.
    - Configure the tool (e.g., `nx affected`, `turbo run --filter=[head]`) to only target the identified components and tiers.
3. **Verification**: Execute the build/test and verify that only the intended components and tiers were processed and that they passed.
4. **Documentation**: Document the selective execution plan, including which tiers were run and why.
5. **Review**: Platform/DevOps Engineer and Tech Lead review the selective execution results for correctness, coverage, and alignment with the test execution matrix.

---

## Example Test / Validation

- Change a single component and verify only that component’s build/tests run
- Introduce a dependency change and verify dependent components are included
- Confirm quality gates are identical to full runs for impacted components

---

## Common Red Flags / Guardrail Violations

- Skipping pre-commit hooks or checks “to save time”
- Reducing scope by suppressing tests rather than proving non-impact
- Disabling warnings-as-errors or lint rules to speed up builds
- Incremental logic that is not reproducible or explainable

---

## Recommended Review Personas

- **Platform/DevOps Engineer** – validates correctness of incremental execution
- **Tech Lead** – validates standards are not weakened and scope is justified
- **Domain Expert** – validates dependency assumptions

---

## Skill Priority

P3 – Delivery & Flow  
(Must never override P0–P2 constraints.)

---

## Conflict Resolution Rules

- Must consume the output of incremental-change-impact
- Cannot weaken quality gates; only reduces scope
- If uncertainty exists, broaden scope rather than suppress checks (with justification)

---

## Conceptual Dependencies

- incremental-change-impact
- quality-gate-enforcement

---

## Classification

Operational

---

## Notes

Optimise feedback loops, not standards. Faster is acceptable only when correct. Refer to the repository's "Test Execution Matrix" for stage-specific tier requirements.