Add third-party assumptions section to spec templates

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: ofriw

website/prompts/specifications/spec-template.md

@@ -20,8 +20,8 @@ For **extracting** specs from an existing codebase automatically, use the
 
 ### How to Use
 
-1. Copy the sections relevant to your system's complexity
-   (see [Matching Depth to Complexity](/docs/practical-techniques/lesson-13-systems-thinking-specs#matching-depth-to-complexity))
+1. Start with Architecture + Interfaces + State, then add sections as the code pulls them
+   (see [Converge, Don't Count Passes](/docs/practical-techniques/lesson-13-systems-thinking-specs#converge-dont-count-passes))
 2. Fill in with your domain specifics — skip sections that don't apply
 3. Use as context for agent implementation or as a design document for team review
 4. Delete after implementation — code is the source of truth

website/shared-prompts/_generate-spec.mdx

@@ -57,6 +57,14 @@ You are a senior systems architect writing a system oriented specification.
 |-------|------|-------|-----------|
 | [endpoint/event/service] | HTTP / async / in-process | [module] | [who calls it] |
 
+### Third-Party Assumptions
+
+> Behavioral guarantees your design depends on. When an assumption changes, its "Drives" column shows which spec elements to revisit.
+
+| Assumption | Source | Drives |
+|------------|--------|--------|
+| [behavioral guarantee or limitation] | [documentation URL or reference] | C-[id], I-[id], [state model], [security decision] |
+
 ### Extension Points
 
 > Only committed business needs. If the variation is not funded/scheduled, omit — YAGNI applies.
@@ -374,6 +382,7 @@ You are a senior systems architect writing a system oriented specification.
     - Include only what's relevant to fully describing `$ARGUMENTS` in its system context.
     - Include diagrams where relevant.
     - Use repeat `code_research` calls to learn the different sub systems and internals of `$ARGUMENTS`.
+    - For each integration point, identify what behavioral guarantees the external service provides (delivery semantics, signing, SLAs) and trace which design decisions depend on them.
     - Write the resulting spec to a markdown file under `specs/` with an appropriate name.
 3. Spawn a general-purpose agent to:
     - Read the resulting spec file

website/shared-prompts/_spec-template.mdx

@@ -45,6 +45,14 @@
 |-------|------|-------|-----------|
 | [endpoint/event/service] | HTTP / async / in-process | [module] | [who calls it] |
 
+### Third-Party Assumptions
+
+> Behavioral guarantees your design depends on. When an assumption changes, its "Drives" column shows which spec elements to revisit.
+
+| Assumption | Source | Drives |
+|------------|--------|--------|
+| [behavioral guarantee or limitation] | [documentation URL or reference] | C-[id], I-[id], [state model], [security decision] |
+
 ### Extension Points
 
 > Only committed business needs. If the variation is not funded/scheduled, omit — YAGNI applies.