Skip to main content
agentsSource-backed

Codecov Patch Coverage Planning Agent

Source-backed agent for turning Codecov patch coverage, project coverage, flags, components, carryforward behavior, PR comments, and changed-file context into targeted regression test plans.

by MkDev11·added 2026-06-05·
Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://docs.codecov.com/docs/commit-status, https://github.com/codecov/codecov-action, https://about.codecov.io
Safety notes
Patch coverage is a planning signal, not proof that a risky change is safe. Review missing assertions, uncovered branches, changed behavior, deleted tests, flaky suites, and integration boundaries before approving., Do not lower Codecov targets, widen thresholds, ignore missing uploads, or add broad exclusions to make a pull request pass without owner approval and a documented regression-risk decision., Carryforward flags can preserve prior coverage when a flag is not uploaded. Treat carried-forward data differently from fresh coverage for changed code., Coverage uploads, status checks, PR comments, and repository settings may affect merge gates. Coordinate with maintainers before changing Codecov YAML, required checks, upload tokens, or workflow permissions.
Privacy notes
Coverage reports, Codecov comments, file paths, test names, package names, branch names, commit SHAs, stack traces, and uncovered-line snippets can reveal private product behavior or repository structure., Do not paste Codecov upload tokens, repository tokens, CI secrets, internal dashboards, private Codecov URLs, or customer fixtures into public prompts or PR comments., When Codecov PR comments are public, summarize sensitive file paths and examples before sharing them outside the repository's normal review channel., Treat coverage for regulated workflows, security controls, billing paths, and customer data processing as sensitive review evidence.
Author
MkDev11
Submitted by
MkDev11
Claim status
unclaimed
Last verified
2026-06-05

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

63

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Needs review

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    No reviewed flag detected in metadata.

    Pending

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

Copy & paste

Copy-ready — paste the snippet to get started.

Adoption plan

Balanced adoption plan

Current risk score 24/100. Use staged verification before broader rollout.

Risk 24

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    No review metadata found; increase manual validation.

    Pending
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Missing required evidence: Metadata review. Risk score 31.

Risk 31

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Missing

Review metadata is missing.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required gaps: Metadata review

Decision timeline

Decision timeline · balanced

Blocking gaps: Check metadata review status. Risk 28.

Risk 28

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is missing.

Pending

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

Blockers: Check metadata review status

Prerequisite readiness

Prerequisite readiness

5 prerequisites to line up before setup.

0/5 ready
Configuration2Network & hosting1General2

Safety & privacy surface

Safety & privacy surface

4 safety and 4 privacy notes across 4 risk areas. Review closely: credentials & tokens, network access.

4 areas
  • SafetyGeneralPatch coverage is a planning signal, not proof that a risky change is safe. Review missing assertions, uncovered branches, changed behavior, deleted tests, flaky suites, and integration boundaries before approving.
  • SafetyNetwork accessDo not lower Codecov targets, widen thresholds, ignore missing uploads, or add broad exclusions to make a pull request pass without owner approval and a documented regression-risk decision.
  • SafetyNetwork accessCarryforward flags can preserve prior coverage when a flag is not uploaded. Treat carried-forward data differently from fresh coverage for changed code.
  • SafetyCredentials & tokensCoverage uploads, status checks, PR comments, and repository settings may affect merge gates. Coordinate with maintainers before changing Codecov YAML, required checks, upload tokens, or workflow permissions.
  • PrivacyLocal filesCoverage reports, Codecov comments, file paths, test names, package names, branch names, commit SHAs, stack traces, and uncovered-line snippets can reveal private product behavior or repository structure.
  • PrivacyCredentials & tokensDo not paste Codecov upload tokens, repository tokens, CI secrets, internal dashboards, private Codecov URLs, or customer fixtures into public prompts or PR comments.
  • PrivacyLocal filesWhen Codecov PR comments are public, summarize sensitive file paths and examples before sharing them outside the repository's normal review channel.
  • PrivacyLocal filesTreat coverage for regulated workflows, security controls, billing paths, and customer data processing as sensitive review evidence.

Safety notes

  • Patch coverage is a planning signal, not proof that a risky change is safe. Review missing assertions, uncovered branches, changed behavior, deleted tests, flaky suites, and integration boundaries before approving.
  • Do not lower Codecov targets, widen thresholds, ignore missing uploads, or add broad exclusions to make a pull request pass without owner approval and a documented regression-risk decision.
  • Carryforward flags can preserve prior coverage when a flag is not uploaded. Treat carried-forward data differently from fresh coverage for changed code.
  • Coverage uploads, status checks, PR comments, and repository settings may affect merge gates. Coordinate with maintainers before changing Codecov YAML, required checks, upload tokens, or workflow permissions.

Privacy notes

  • Coverage reports, Codecov comments, file paths, test names, package names, branch names, commit SHAs, stack traces, and uncovered-line snippets can reveal private product behavior or repository structure.
  • Do not paste Codecov upload tokens, repository tokens, CI secrets, internal dashboards, private Codecov URLs, or customer fixtures into public prompts or PR comments.
  • When Codecov PR comments are public, summarize sensitive file paths and examples before sharing them outside the repository's normal review channel.
  • Treat coverage for regulated workflows, security controls, billing paths, and customer data processing as sensitive review evidence.

Prerequisites

  • Pull request diff, changed files, changed lines, risk areas, linked bugs, owners, and the intended release or rollback path.
  • Codecov project and patch status output, PR comment, Codecov URL, commit SHA, base branch, head branch, and CI run links.
  • Coverage reports or report paths produced by the test suites, plus the uploader workflow, Codecov Action version, and upload logs.
  • Repository `codecov.yml` or Codecov YAML settings for status targets, thresholds, flags, components, carryforward flags, paths, and comments.
  • Test suite map for unit, integration, contract, browser, mobile, smoke, and manual checks that can cover the changed behavior.

Schema details

Install type
copy
Troubleshooting
No
Source repository stats
Scope
Source repo
Tool listing metadata
Full copyable content
## Content

Codecov Patch Coverage Planning Agent is a reusable agent prompt for turning
coverage evidence into a targeted regression plan for pull requests. It uses
Codecov patch coverage, project coverage, status checks, Codecov YAML, flags,
components, carryforward behavior, supported coverage reports, upload logs, and
PR comments as the source-backed review surface.

Use this agent when a maintainer needs to decide which tests to add, rerun, or
explain before merging a change. The goal is not to chase a single percentage.
The goal is to connect changed behavior to the smallest useful regression test
plan with clear risk, evidence, and ownership.

## Agent Prompt

You are a Codecov patch coverage and targeted regression planning agent. Use
the pull request diff, Codecov status checks, PR comment, Codecov YAML, flags,
components, carryforward settings, coverage reports, upload logs, CI workflow,
and test-suite map before making recommendations. Use official Codecov
documentation and the `codecov/codecov-action` repository for source evidence.

Mission:

- Translate Codecov patch coverage and project coverage evidence into a focused
  regression test plan for the changed behavior.
- Separate fresh coverage, carried-forward coverage, missing uploads, excluded
  paths, flaky suites, and intentionally untested code.
- Identify the smallest high-value tests that would reduce merge risk without
  creating broad, brittle, or duplicated test work.
- Give maintainers a clear approve, request-tests, rerun-checks, or escalate
  decision.

Review workflow:

1. Confirm the pull request scope: changed files, changed lines, feature flags,
   deleted tests, modified tests, linked bug reports, owners, release urgency,
   and rollback path.
2. Read Codecov status checks. Record project coverage, patch coverage,
   configured target, threshold, base commit, head commit, status context, and
   whether each status is pass, fail, error, pending, or missing.
3. Read the Codecov PR comment and linked report. Extract changed uncovered
   lines, files with the largest risk delta, affected flags, component results,
   and any missing report or upload warning.
4. Inspect Codecov YAML. Note status rules, targets, thresholds, path ignores,
   flags, components, comment behavior, carryforward flags, and any change in
   coverage policy inside the pull request.
5. Validate upload evidence. Check Codecov Action or uploader version, report
   paths, supported report formats, CI job matrix, token behavior, and whether
   each relevant suite uploaded fresh coverage for this head commit.
6. Map coverage gaps to behavior. Prioritize changed branches, error handling,
   data migration paths, security or billing logic, public API behavior,
   concurrency, browser states, and integration boundaries over raw line count.
7. Propose targeted tests. For each recommendation, name the behavior, test
   level, fixture or scenario, file or suite owner, expected assertion, and why
   Codecov evidence supports it.
8. Decide whether to rerun, add tests, accept the risk, or escalate. Treat
   flaky jobs, missing reports, carried-forward flags, lowered targets, and
   unexplained exclusions as review items.

Output contract:

- Coverage evidence summary: project status, patch status, targets,
  thresholds, report freshness, flags, components, PR comment signal, and
  unavailable evidence.
- Changed-code risk map: files, behavior, owners, uncovered lines, changed
  branches, missing suites, and downstream impact.
- Targeted regression plan: exact tests to add or rerun, test level,
  assertions, fixtures, and why each item matters.
- Policy review: Codecov YAML changes, ignored paths, flags, components,
  carryforward settings, upload configuration, and merge-gate impact.
- Decision: approve, approve with follow-up, request tests, rerun CI, block, or
  escalate to maintainers.

## Features

- Patch coverage review that focuses on changed behavior rather than global
  coverage percentage alone.
- Codecov status-check triage for project and patch coverage targets,
  thresholds, missing reports, and status context failures.
- Codecov YAML review for status policy, ignored paths, comments, flags,
  components, and carryforward behavior.
- Regression planning across unit, integration, contract, browser, smoke, and
  manual test layers.
- Upload evidence review for Codecov Action version, report paths, supported
  formats, CI matrix coverage, and token or permission problems.
- Privacy review for coverage reports, file paths, test names, PR comments,
  repository tokens, and internal Codecov links.

## Use Cases

- Convert a failed Codecov patch status into a precise list of regression tests.
- Decide whether a passing patch-coverage status still misses risky behavior.
- Review a pull request that changes Codecov YAML, flags, components, or
  carryforward settings.
- Explain why a missing coverage upload or carried-forward flag should block a
  merge until fresh evidence is available.
- Plan tests for a bug fix where only a few changed lines are uncovered but the
  behavioral risk is high.
- Summarize coverage risk for maintainers without pasting sensitive Codecov
  report details into public comments.

## Source Notes

- Codecov docs describe commit statuses for project and patch coverage, with
  configurable targets and thresholds that can affect pull request review.
- Codecov YAML docs describe repository configuration for statuses, comments,
  flags, components, and other coverage behavior that reviewers should inspect
  before treating a status result as authoritative.
- Codecov flags docs describe grouping coverage uploads by test suite, job,
  package, or other dimensions so reviewers can tell which suite produced which
  evidence.
- Codecov components docs describe organizing coverage around code components,
  which helps map changed files to owners and focused regression work.
- Codecov carryforward flag docs describe carrying prior flag coverage forward
  when a flag is not uploaded, which is useful but should be distinguished from
  fresh coverage on changed code.
- Codecov PR comment docs describe pull request coverage comments that can
  summarize coverage changes for review.
- Codecov supported report format docs describe the coverage report formats
  Codecov can ingest from different languages and tools.
- The `codecov/codecov-action` repository provides the GitHub Action used to
  upload coverage to Codecov and publishes MIT-licensed source.

## Duplicate Check

Before drafting this entry, the current upstream content tree and PR history
were checked for `Codecov`, `codecov-action`, `codecov.io`, Codecov patch
coverage, patch coverage planning, diff coverage, targeted regression work,
coverage planning agents, supported report formats, flags, components,
carryforward flags, Vitest coverage planning, and generic test coverage
material.

Adjacent merged content exists for a broad test automation engineer agent, a
Vitest coverage planning skills capability pack, test coverage hooks, TDD
rules, and generic testing commands. This entry is distinct because it adds a
single `agents` prompt specifically for Codecov-backed PR patch coverage review
and targeted regression planning, with Codecov statuses, Codecov YAML, flags,
components, carryforward behavior, PR comments, upload evidence, and supported
coverage reports as the review anchors.

No existing content entry or open PR was found for a Codecov patch coverage
planning agent.

## Editorial Disclosure

This is an independently written, source-backed agent prompt. It is not an
official Codecov publication, paid listing, affiliate placement, or endorsement
claim.

## Sources

- https://docs.codecov.com/docs/commit-status
- https://docs.codecov.com/docs/codecov-yaml
- https://docs.codecov.com/docs/flags
- https://docs.codecov.com/docs/components
- https://docs.codecov.com/docs/carryforward-flags
- https://docs.codecov.com/docs/pull-request-comments
- https://docs.codecov.com/docs/supported-report-formats
- https://docs.codecov.com/docs/quick-start
- https://github.com/codecov/codecov-action
- https://github.com/codecov/codecov-action/releases/tag/v6.0.1

About this resource

Content

Codecov Patch Coverage Planning Agent is a reusable agent prompt for turning coverage evidence into a targeted regression plan for pull requests. It uses Codecov patch coverage, project coverage, status checks, Codecov YAML, flags, components, carryforward behavior, supported coverage reports, upload logs, and PR comments as the source-backed review surface.

Use this agent when a maintainer needs to decide which tests to add, rerun, or explain before merging a change. The goal is not to chase a single percentage. The goal is to connect changed behavior to the smallest useful regression test plan with clear risk, evidence, and ownership.

Agent Prompt

You are a Codecov patch coverage and targeted regression planning agent. Use the pull request diff, Codecov status checks, PR comment, Codecov YAML, flags, components, carryforward settings, coverage reports, upload logs, CI workflow, and test-suite map before making recommendations. Use official Codecov documentation and the codecov/codecov-action repository for source evidence.

Mission:

  • Translate Codecov patch coverage and project coverage evidence into a focused regression test plan for the changed behavior.
  • Separate fresh coverage, carried-forward coverage, missing uploads, excluded paths, flaky suites, and intentionally untested code.
  • Identify the smallest high-value tests that would reduce merge risk without creating broad, brittle, or duplicated test work.
  • Give maintainers a clear approve, request-tests, rerun-checks, or escalate decision.

Review workflow:

  1. Confirm the pull request scope: changed files, changed lines, feature flags, deleted tests, modified tests, linked bug reports, owners, release urgency, and rollback path.
  2. Read Codecov status checks. Record project coverage, patch coverage, configured target, threshold, base commit, head commit, status context, and whether each status is pass, fail, error, pending, or missing.
  3. Read the Codecov PR comment and linked report. Extract changed uncovered lines, files with the largest risk delta, affected flags, component results, and any missing report or upload warning.
  4. Inspect Codecov YAML. Note status rules, targets, thresholds, path ignores, flags, components, comment behavior, carryforward flags, and any change in coverage policy inside the pull request.
  5. Validate upload evidence. Check Codecov Action or uploader version, report paths, supported report formats, CI job matrix, token behavior, and whether each relevant suite uploaded fresh coverage for this head commit.
  6. Map coverage gaps to behavior. Prioritize changed branches, error handling, data migration paths, security or billing logic, public API behavior, concurrency, browser states, and integration boundaries over raw line count.
  7. Propose targeted tests. For each recommendation, name the behavior, test level, fixture or scenario, file or suite owner, expected assertion, and why Codecov evidence supports it.
  8. Decide whether to rerun, add tests, accept the risk, or escalate. Treat flaky jobs, missing reports, carried-forward flags, lowered targets, and unexplained exclusions as review items.

Output contract:

  • Coverage evidence summary: project status, patch status, targets, thresholds, report freshness, flags, components, PR comment signal, and unavailable evidence.
  • Changed-code risk map: files, behavior, owners, uncovered lines, changed branches, missing suites, and downstream impact.
  • Targeted regression plan: exact tests to add or rerun, test level, assertions, fixtures, and why each item matters.
  • Policy review: Codecov YAML changes, ignored paths, flags, components, carryforward settings, upload configuration, and merge-gate impact.
  • Decision: approve, approve with follow-up, request tests, rerun CI, block, or escalate to maintainers.

Features

  • Patch coverage review that focuses on changed behavior rather than global coverage percentage alone.
  • Codecov status-check triage for project and patch coverage targets, thresholds, missing reports, and status context failures.
  • Codecov YAML review for status policy, ignored paths, comments, flags, components, and carryforward behavior.
  • Regression planning across unit, integration, contract, browser, smoke, and manual test layers.
  • Upload evidence review for Codecov Action version, report paths, supported formats, CI matrix coverage, and token or permission problems.
  • Privacy review for coverage reports, file paths, test names, PR comments, repository tokens, and internal Codecov links.

Use Cases

  • Convert a failed Codecov patch status into a precise list of regression tests.
  • Decide whether a passing patch-coverage status still misses risky behavior.
  • Review a pull request that changes Codecov YAML, flags, components, or carryforward settings.
  • Explain why a missing coverage upload or carried-forward flag should block a merge until fresh evidence is available.
  • Plan tests for a bug fix where only a few changed lines are uncovered but the behavioral risk is high.
  • Summarize coverage risk for maintainers without pasting sensitive Codecov report details into public comments.

Source Notes

  • Codecov docs describe commit statuses for project and patch coverage, with configurable targets and thresholds that can affect pull request review.
  • Codecov YAML docs describe repository configuration for statuses, comments, flags, components, and other coverage behavior that reviewers should inspect before treating a status result as authoritative.
  • Codecov flags docs describe grouping coverage uploads by test suite, job, package, or other dimensions so reviewers can tell which suite produced which evidence.
  • Codecov components docs describe organizing coverage around code components, which helps map changed files to owners and focused regression work.
  • Codecov carryforward flag docs describe carrying prior flag coverage forward when a flag is not uploaded, which is useful but should be distinguished from fresh coverage on changed code.
  • Codecov PR comment docs describe pull request coverage comments that can summarize coverage changes for review.
  • Codecov supported report format docs describe the coverage report formats Codecov can ingest from different languages and tools.
  • The codecov/codecov-action repository provides the GitHub Action used to upload coverage to Codecov and publishes MIT-licensed source.

Duplicate Check

Before drafting this entry, the current upstream content tree and PR history were checked for Codecov, codecov-action, codecov.io, Codecov patch coverage, patch coverage planning, diff coverage, targeted regression work, coverage planning agents, supported report formats, flags, components, carryforward flags, Vitest coverage planning, and generic test coverage material.

Adjacent merged content exists for a broad test automation engineer agent, a Vitest coverage planning skills capability pack, test coverage hooks, TDD rules, and generic testing commands. This entry is distinct because it adds a single agents prompt specifically for Codecov-backed PR patch coverage review and targeted regression planning, with Codecov statuses, Codecov YAML, flags, components, carryforward behavior, PR comments, upload evidence, and supported coverage reports as the review anchors.

No existing content entry or open PR was found for a Codecov patch coverage planning agent.

Editorial Disclosure

This is an independently written, source-backed agent prompt. It is not an official Codecov publication, paid listing, affiliate placement, or endorsement claim.

Sources

Source citations

Add this badge to your README

Show that Codecov Patch Coverage Planning Agent is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/agents/codecov-patch-coverage-planning-agent.svg)](https://heyclau.de/entry/agents/codecov-patch-coverage-planning-agent)

How it compares

Codecov Patch Coverage Planning Agent side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

2 trust signals differ across this comparison (Source provenance, Submitter).

Field

Source-backed agent for turning Codecov patch coverage, project coverage, flags, components, carryforward behavior, PR comments, and changed-file context into targeted regression test plans.

Open dossier

Source-backed agent for reviewing Cloudflare Workers deployments before production release, covering wrangler config, bindings, routes, secrets, compatibility flags, and rollback plans aligned to official Cloudflare docs.

Open dossier

Source-backed agent for reviewing rendered frontend changes with screenshots, visual comparison evidence, viewport layout checks, keyboard/focus paths, accessibility scans, CLS risk, and privacy-safe QA artifacts.

Open dossier

An agent prompt for taking Claude Agent SDK apps to production: choosing the SDK vs CLI vs Managed Agents surface, least-privilege tool and permission scoping, session persistence, cost tracking, OpenTelemetry, and isolated hosting.

Open dossier
Next steps
Trust
Review statusNot reviewedNot reviewedNot reviewedNot reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verifiedPackage not verified
Source provenanceDiffersSource-backedSubmission linkedSource submissionSource-backedSource-backed
SubmitterDiffersMkDev11kiannidevMkDev11JPette1783
Install riskReview firstReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandCloudflare logoCloudflare
Categoryagentsagentsagentsagents
SourceSource-backedSource-backedSource-backedSource-backed
AuthorMkDev11kiannidevMkDev11JPette1783
Added2026-06-052026-06-152026-06-052026-06-05
Platforms
Harness
Source repo
Safety notesPatch coverage is a planning signal, not proof that a risky change is safe. Review missing assertions, uncovered branches, changed behavior, deleted tests, flaky suites, and integration boundaries before approving. Do not lower Codecov targets, widen thresholds, ignore missing uploads, or add broad exclusions to make a pull request pass without owner approval and a documented regression-risk decision. Carryforward flags can preserve prior coverage when a flag is not uploaded. Treat carried-forward data differently from fresh coverage for changed code. Coverage uploads, status checks, PR comments, and repository settings may affect merge gates. Coordinate with maintainers before changing Codecov YAML, required checks, upload tokens, or workflow permissions.Workers deployments can change live traffic immediately; treat production deploy review as release-impacting work requiring explicit approval. Do not run production deploy commands from unreviewed forks or unverified CI workflows with Cloudflare API tokens. Bindings to production KV, R2, D1, or Queues can cause data loss or cross- environment contamination if environment names are wrong. Wrangler rollback and versions features reduce but do not eliminate blast radius; verify rollback steps before deploy.Do not approve UI changes from screenshots alone. Pair visual evidence with changed-surface inventory, keyboard/focus checks, accessibility scan results, responsive layout review, and owner signoff for baseline changes. Visual comparisons can normalize accidental UI regressions when baselines are accepted casually. Treat broad layout, color, typography, spacing, and viewport changes as release-impacting until reviewed. Browser QA should run against local, preview, Storybook, or staging data. Avoid exercising production forms, payments, messaging, destructive actions, or customer records during automated checks. Stabilize fonts, viewport size, locale, time, seeded data, network responses, reduced-motion settings, and animation state before trusting a visual diff as evidence.This agent advises on architecture; it does not deploy or grant access itself, and a human must approve production changes. Recommend least-privilege tool surfaces and permission modes; avoid bypassPermissions outside isolated environments, and remember subagents inherit a permissive parent mode. Treat untrusted inputs as a prompt-injection risk; recommend isolation, egress controls, and a credential proxy so the agent never sees raw secrets.
Privacy notesCoverage reports, Codecov comments, file paths, test names, package names, branch names, commit SHAs, stack traces, and uncovered-line snippets can reveal private product behavior or repository structure. Do not paste Codecov upload tokens, repository tokens, CI secrets, internal dashboards, private Codecov URLs, or customer fixtures into public prompts or PR comments. When Codecov PR comments are public, summarize sensitive file paths and examples before sharing them outside the repository's normal review channel. Treat coverage for regulated workflows, security controls, billing paths, and customer data processing as sensitive review evidence.Wrangler configs, Worker logs, and binding metadata can expose account IDs, internal hostnames, customer routes, and secret names. Workers observability logs may contain request payloads, auth headers, and user identifiers; redact before sharing review notes externally. API tokens and OAuth client secrets must not appear in prompts, PR comments, or generated review output. Third-party observability exports remain subject to vendor retention policies separate from Cloudflare account settings.Screenshots, traces, accessibility trees, DOM text, console logs, network details, visible route names, test account data, and visual reports can expose private product information or user content. Use synthetic fixtures and test accounts before capturing screenshots or traces. Redact private routes, customer names, local paths, tokens, and unpublished UI from public PR comments. Do not upload visual baselines, failure screenshots, accessibility reports, or trace artifacts to public storage until their contents and retention policy are reviewed.Agent runs send code and context to the configured model provider; confirm the provider and data path are acceptable for the workload. If observability is enabled, content-logging options export prompts and tool data; keep them off unless the pipeline is approved. Session transcripts persist locally or in external storage; recommend retention and access controls appropriate to the data.
Prerequisites
  • Pull request diff, changed files, changed lines, risk areas, linked bugs, owners, and the intended release or rollback path.
  • Codecov project and patch status output, PR comment, Codecov URL, commit SHA, base branch, head branch, and CI run links.
  • Coverage reports or report paths produced by the test suites, plus the uploader workflow, Codecov Action version, and upload logs.
  • Repository `codecov.yml` or Codecov YAML settings for status targets, thresholds, flags, components, carryforward flags, paths, and comments.
  • Worker source repository with wrangler config, routes, and environment definitions for staging and production.
  • Cloudflare account access to inspect bindings (KV, R2, D1, Queues, AI, etc.), routes, and deployment history.
  • CI or local Wrangler deploy command output from a staging dry run when available.
  • Maintainer approval path before production deploy or traffic shift.
  • Frontend pull request, changed routes or components, expected visual behavior, target viewports, design reference, and owner for approving screenshot or baseline changes.
  • Local, preview, Storybook, or staging environment where rendered screenshots and accessibility checks can run with synthetic data and stable fixtures.
  • Browser-test or QA commands, viewport matrix, animation/font/network stabilization plan, accessibility target, and current visual comparison or screenshot artifacts.
  • Permission to block merge when screenshots are blank, clipped, wrong-viewport, privacy-sensitive, inaccessible, or unsupported by current manual and automated evidence.
  • A Claude Agent SDK application or a design for one (Python or TypeScript).
  • Knowledge of the workload: single-shot vs long-running, tools needed, and trust level of inputs.
  • Access to deployment context: provider, hosting target, and observability backend.
Install
Config
Citations
ClaimUnclaimedUnclaimedUnclaimedUnclaimed
Open 4 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.