diff --git a/.changeset/tdd-seam-tradeoffs.md b/.changeset/tdd-seam-tradeoffs.md
new file mode 100644
index 0000000..5c9f66c
--- /dev/null
+++ b/.changeset/tdd-seam-tradeoffs.md
@@ -0,0 +1,5 @@
+---
+"mattpocock-skills": patch
+---
+
+`tdd` now gives each proposed seam a one-line note on what it catches and what it misses, so choosing between seams is no longer a guess (#607).
diff --git a/skills/engineering/tdd/SKILL.md b/skills/engineering/tdd/SKILL.md
index 250871c..01eadaa 100644
--- a/skills/engineering/tdd/SKILL.md
+++ b/skills/engineering/tdd/SKILL.md
@@ -21,7 +21,7 @@ A **seam** is the public boundary you test at: the interface where you observe b
 
 **Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
 
-Ask: "What's the public interface, and which seams should we test?"
+Ask: "What's the public interface, and which seams should we test?" Give each proposed seam a one-line note on what it catches and what it misses.
 
 When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), call the Skill tool with "codebase-design" for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.