adding seam review skill

docs/reference/review-checklist.md

@@ -46,6 +46,31 @@ Use this checklist when reviewing a design produced by a human or an LLM.
 - Can service and adapter internals be trusted mostly through seam tests and type constraints rather than line-by-line domain review?
 - Do service implementations avoid accumulating hidden business logic?
 
+## General bounded-seam review questions
+
+- What caller intent does this seam grant?
+- What invariant becomes true after crossing it?
+- What tainted input becomes trusted here?
+- What can still fail, and how is failure represented?
+- What decisions are pure policy versus orchestration versus I/O?
+- What internal details are leaking through the public API?
+- If this seam were renamed by user goal instead of implementation shape, what would it be called?
+
+## Applying the questions by seam type
+
+### Workflow seams
+
+- Given command X, under what rules does this workflow emit event Y or failure Z?
+- Is the workflow mostly assembling decisions and capabilities, or is it hiding business rules inside orchestration?
+- Does the workflow expose the business outcome more clearly than the implementation steps?
+
+### Policy seams
+
+- What exact business or security decision is being made?
+- What inputs are sufficient for that decision?
+- Are the reasons for approval or rejection explicit enough to review?
+- Is the policy pure and deterministic?
+
 ## Security review readiness
 
 - Are trust boundaries visible enough for a reviewer to identify where untrusted data enters?