Change Code in a Large Multi-Language Repo with Only the Needed Builds and Tests

## Research and Plan, Then Make and Test the Smallest Change Use a repeatable sequence for every change: 1. Research the request, relevant code, dependency interfaces, existing tests, and known failure modes. 2. Form a high-level implementation plan and challenge its assumptions, edge cases, and operational risks. 3. Inspect similar code to learn the repository’s organization, naming, error handling, and testing patterns. 4. Present the plan only when the user asks for it; otherwise continue with the implementation. 5. Implement the smallest coherent change that satisfies the request. 6. Review the result for API correctness, clarity, performance, readability, and unintended scope. 7. Run formatting, targeted builds, and relevant tests, then iterate on failures. Do not treat drafting as completion. A change is ready only after the implementation and its directly affected behavior have been reviewed and validated. ## Follow the Closest Similar Code Before Editing Read the repository-level contribution guidance and any path-specific instructions that govern the files being changed. Find the nearest working analogue, such as a sibling class, adjacent package, similar test, or related workflow, and follow its established structure unless the task requires a deliberate deviation. Verify dependency APIs and edge cases from authoritative interfaces or existing usage. Locate current tests before creating new ones, and integrate new coverage with the repository’s existing frameworks instead of inventing a parallel harness. Keep the investigation focused on the requested behavior. Do not combine the change with unrelated renaming, directory movement, formatting churn, or architectural cleanup. ## Check Which Tools and Hardware Are Available Before Testing Before choosing commands, determine which compilers, runtimes, build tools, containers, accelerators, and credentials are actually available. Distinguish an unavailable capability from a product failure: a missing device, unsupported container runtime, or absent toolchain does not prove the code is defective. Use the repository’s standard container or development environment when it is supported and needed for reproducibility. Otherwise, run every meaningful check available in the current environment and identify the smallest remaining command that requires another machine or user action. Never claim that an unavailable test passed. Report the exact limitation, the validation completed without it, and the residual risk. ## Build and Test Only the Parts the Change Affects Prefer repository-provided presets and helper scripts over hand-built command sequences. Discover the supported presets, select the one matching the changed component and language level, and target only the relevant build targets, unit tests, integration tests, or compiler checks. Use dependency information to include downstream components affected by a shared or high-dependency change. For a local change, avoid rebuilding unrelated packages. Reserve full builds and full test suites for cross-cutting changes, release gates, or repository policy that explicitly requires them. Record why the selected scope is sufficient. A narrow check is valuable only when its relationship to the change is clear. ## Test Each Language and Hardware Architecture in Its Own Way Treat each language or package layer according to its own interface. Native libraries may require compiler, language-standard, and architecture settings, while scripting-language packages may require runtime versions, dependency extras, and package-specific test entry points. Do not pass one ecosystem’s parameters into another. For architecture-sensitive code, distinguish host-only checks, compile-only checks, simulator or virtual targets, and tests that require physical hardware. Select representative architectures based on the changed behavior and supported compatibility range rather than compiling every variant by default. When a shared component changes, inspect the dependency graph and validate the consumers most likely to expose compatibility regressions. ## Run Cheap Checks First and Don't Stop Slow Builds Too Early Assume that large builds, generated test matrices, and hardware-backed suites can take substantial time. Set realistic timeouts, use supported caches, limit architectures and targets during iteration, and expand coverage only when the risk or release stage justifies the cost. Long duration alone is not evidence of a hang. Do not cancel a running build or test merely because it is slow; stop it only when there is concrete failure evidence, an explicit operational limit, or a user instruction. Stage validation so cheap feedback arrives first: formatting and static checks, targeted compilation, host-capable tests, then specialized or hardware-dependent suites. Preserve the final required coverage even when early iterations use a smaller subset. ## Trim CI While Iterating, but Run Full CI Before Merge Use change detection and job matrices to run the jobs relevant to affected components. Temporary override matrices or skip controls may reduce cost during early iteration, especially for infrastructure changes or high-dependency areas, but they must remain visible and auditable. Treat reduced CI coverage as a merge blocker. Before merge, restore the repository’s required full configuration and obtain a successful run without temporary overrides or skip controls. Do not remove another contributor’s override or change its scope without explicit direction. Keep override configuration structurally valid when the workflow expects an empty value rather than deletion. Confirm that result aggregation fails closed when required jobs fail or reduced coverage remains active. ## Run Formatters and Linters, and Report Checks That Did Not Run Run the repository’s formatter, linter, and pre-commit checks on the changed files before committing. Apply common style guidance first, then any language-, directory-, or test-specific rules selected by the affected paths. Review the final diff for accidental files, generated artifacts, inconsistent naming, stale comments, and missing tests. Re-run the focused validation after the final edit so reported evidence matches the delivered content. Report the exact checks performed, their outcomes, any checks not run, the reason they were unavailable, and the resulting residual risk. Never describe a change as fully validated when required hardware, tooling, permissions, or CI coverage was missing.