From Green Build to Safe Operation

For addyosmani/agent-skills, verification does not end when a change passes review or a build turns green. This chapter follows the same evidence discipline into CI, performance measurement, telemetry, staged exposure, and rollback. The reader’s practical task is to decide which signal answers which operational question, then use limited rollout and reversible controls to learn from real behavior without treating deployment success as proof that users are safe.

A local build runs under controlled conditions. Production adds different data, traffic, network paths, browser behavior, dependency states, and failure timing. The repository’s later lifecycle skills respond by separating deployment from exposure and by making operation observable. They do not remove uncertainty. They make it possible to see, bound, and respond to it.

Shift left reduces cost, but it does not eliminate runtime evidence

The CI/CD workflow moves inexpensive, repeatable checks toward the beginning of the pipeline. Lint, type checking, unit tests, build, integration checks, optional end-to-end tests, security audit, and bundle-size checks can run on pull requests and changes to the main branch. The principle is not that every check belongs in the first second. It is that a problem should be caught at the earliest stage capable of detecting it.

A lint failure can be corrected before it reaches a reviewer. A type failure can be localized before a deployment. A unit test can expose a behavior regression before integration work proceeds. A build can reveal that separate modules do not compose. Security or bundle checks may be slower, but they still provide a repeatable gate before release. The ordering is a cost model: early failures are generally cheaper to interpret and repair than failures discovered after exposure to users.

Shift left has a boundary. Static checks and tests cannot observe everything that happens in a browser, under real latency, with production data, or when several services fail at once. They may also encode the wrong expectation. A green pipeline proves that the checks passed under their conditions; it does not prove that the conditions match the user’s experience.

That is why the repository connects CI to preview deployments, runtime checks, monitoring, and staged rollout. A preview can expose a visual, network, or integration problem that a source-level check cannot see. A staging smoke test can reveal an environment or migration issue. A post-deploy health check can show that the service is reachable, but the application still needs user-facing signals to establish whether the change is behaving acceptably.

The pipeline is therefore an early filter, not the final witness. Its value comes from reducing the uncertainty that later stages need to handle, not from pretending that later stages are unnecessary.

Performance work begins with a baseline

Performance optimization in the repository follows a four-part logic: measure, identify the actual bottleneck, fix it, and measure again under comparable conditions. The baseline prevents a common error in agent-assisted work: selecting a familiar optimization before establishing that the suspected problem exists.

A slow first page load, a sluggish interaction, and a slow backend query have different evidence needs.