diff --git a/triage/skills/analyze.md b/triage/skills/analyze.md
index 4c87aca..bb7ea1d 100644
--- a/triage/skills/analyze.md
+++ b/triage/skills/analyze.md
@@ -194,8 +194,12 @@ Set `duplicateOf` to **null** and `duplicateConfidence` to **null** when there i
 
 ### Step 6: Detect Possible Regressions (Using `resolved.json`)
 
+A regression signals that functionality was broken, fixed, and is now broken again. The value of regression detection is the **insight** it provides: it tells the team that a previous fix did not hold, points to the area that keeps breaking, and highlights a pattern of instability worth investigating.
+
 Populate `regressionOf` from the schema above. Compare each unresolved issue’s **error signature** and **symptoms** to **recently resolved** bugs in `resolved.json` (same project, from `/scan`).
 
+**Chronological constraint:** the resolved bug's **resolution date** must be before the open bug's **creation date**. If the fix landed after the new bug was filed, it cannot be a regression.
+
 When a resolved issue likely fixed the **same area** and the open bug reads like a **reappearance** (same stack line, same API error, same workflow break), set `regressionOf` on the open issue:
 
 ```json
@@ -203,14 +207,14 @@ When a resolved issue likely fixed the **same area** and the open bug reads like
   "key": "EDM-900",
   "summary": "Fixed null dereference in checkout totals",
   "resolved": "2026-02-01T10:00:00.000+0000",
-  "reason": "Same NPE in OrderTotals.java as EDM-900; reopened after release 3.2"
+  "reason": "Same NPE in OrderTotals.java as EDM-900; fix in 3.1 did not hold — reappeared in 3.2, likely incomplete root cause"
 }
 ```
 
 - `key` — resolved issue key (required)
 - `summary` — short summary of the resolved bug (required)
 - `resolved` — resolution date ISO string if known, else null
-- `reason` — one sentence tying this open bug to that fix (required)
+- `reason` — one sentence: what broke again and why the previous fix may not have held (required)
 
 Set `regressionOf` to **null** when no plausible resolved match exists. This feeds the report **Regression** column and **Possible Regressions** section.
 
diff --git a/triage/skills/assess.md b/triage/skills/assess.md
index 5352e52..7b65d0b 100644
--- a/triage/skills/assess.md
+++ b/triage/skills/assess.md
@@ -22,6 +22,8 @@ You perform **full triage on one bug** — the same analytical dimensions as bul
 - **Staleness / activity** — created/updated dates; whether CLOSE-style staleness applies (vague + inactive), without needing other issues for comparison
 - **Duplicates** — multi-angle `jira_search` + **duplicateConfidence** (0–100) for candidates; if mode A, exclude self-key when comparing
 - **Regression hint** — search resolved bugs (e.g. last 90 days) for same signature/symptoms; describe possible **regressionOf**-style relationship in prose (no `resolved.json` required if you query Jira)
+  - A regression signals functionality that was broken, fixed, and is now broken again — focus on the insight: what area keeps failing and whether the prior fix was incomplete or reintroduced
+  - **Chronological constraint:** the resolved bug's *resolution date* must be before the open bug's *creation date* — if the fix landed after the new bug was filed, it cannot be a regression
 - **ESCALATE / WONT_FIX** — when the text clearly warrants it (cross-team, security, out of scope)
 
 **Skip only what inherently needs multiple open bugs:**