break-point-probe

All text output follows unified language preference.

Purpose

Unit tests prove a function is correct in isolation. They do not prove the function is on the runtime path of the bug. Approving a bugfix PR based on unit tests alone is review theater when:

• The fix lives deep in a transform pipeline that has upstream normalization
• The frontend might preprocess the input before it ever reaches the backend
• There are multiple code paths that generate the same artifact, and the fix only touches one
• The bug's observable symptom depends on an external system (dbt, Stripe, Snowflake, etc.)

This skill produces auditable evidence of what was actually verified, in which runtime steps, at which precision level. The output contract makes it impossible for the agent to silently under-verify — every unverified step must be declared.

When to invoke

Invoke when ANY of these hold:

• PR body contains an unchecked "manual verification" / "QA" / "UAT" checkbox
• PR archetype is bugfix AND the diff spans ≥ 2 layers (UI ↔ backend, backend ↔ external system, domain ↔ storage)
• PR archetype is cross-stack
• User asks "is this fix actually wired?" / "verify the break-point" / "pressure-test this fix"
• A previous review claimed APPROVE based only on unit tests and the fix touches a transform or wiring path

Skip when:

• Docs-only PR
• Refactor PR (behavioral equivalence is the review focus, there's no "break-point")
• Style / lint / formatting PR
• PR is purely internal utility with no upstream/downstream callers in production path

Input

Accept any of:

• PR context: pr_number, owner_repo, diff, pr_body, linked_issue_body
• Free-form bug description: symptom + suspected fix location

Process

Step 1 — Build the failure chain

Read diff + PR description + linked issue. Trace the bug's full path from user action to observable symptom. Write it as an ordered list.

Example (, PR #X):

1. User types "xxx.snowflakecomputing.com" in Snowflake Account field       [layer: ui]
2. Frontend POST to /warehouse-connections with config dict                  [layer: api]
3. Backend encrypts + stores config in DB                                    [layer: storage]
4. Later, <workflow> session launch fetches config via get_warehouse_connection   [layer: domain]
5. warehouse_config_to_profile_yml() generates profiles.yml                  [layer: domain]  ← FIX HERE
6. <workflow> instance container reads profiles.yml                               [layer: infra]
7. dbt-snowflake appends ".snowflakecomputing.com" to account field          [layer: external]
8. Connects to "xxx.snowflakecomputing.com.snowflakecomputing.com" → fails   [layer: external]  ← SYMPTOM