diff --git a/.github/workflows/breaking-change-checker.lock.yml b/.github/workflows/breaking-change-checker.lock.yml
index 8ac0c0e728..297b4d8bd2 100644
--- a/.github/workflows/breaking-change-checker.lock.yml
+++ b/.github/workflows/breaking-change-checker.lock.yml
@@ -21,7 +21,11 @@
 #
 # Daily analysis of recent commits and merged PRs for breaking CLI changes
 #
-# frontmatter-hash: 2336029da3e5ed8e6ebb9b83f249a4ba732f7eed260a2bcc46015efbe4453d1b
+# Resolved workflow manifest:
+#   Imports:
+#     - shared/reporting.md
+#
+# frontmatter-hash: d69d5c45e603c822b7a706a9b56adafa773ec5a95dd8ccaacc958dae408b099a
 
 name: "Breaking Change Checker"
 "on":
@@ -555,6 +559,79 @@ jobs:
           PROMPT_EOF
           cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT"
           </system>
+          PROMPT_EOF
+          cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT"
+          ## Report Structure Guidelines
+          
+          ### 1. Header Levels
+          **Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy.**
+          
+          When creating GitHub issues or discussions:
+          - Use `###` (h3) for main sections (e.g., "### Test Summary")
+          - Use `####` (h4) for subsections (e.g., "#### Device-Specific Results")
+          - Never use `##` (h2) or `#` (h1) in reports - these are reserved for titles
+          
+          ### 2. Progressive Disclosure
+          **Wrap detailed test results in `<details><summary><b>Section Name</b></summary>` tags to improve readability and reduce scrolling.**
+          
+          Use collapsible sections for:
+          - Verbose details (full test logs, raw data)
+          - Secondary information (minor warnings, extra context)
+          - Per-item breakdowns when there are many items
+          
+          Always keep critical information visible (summary, critical issues, key metrics).
+          
+          ### 3. Report Structure Pattern
+          
+          1. **Overview**: 1-2 paragraphs summarizing key findings
+          2. **Critical Information**: Show immediately (summary stats, critical issues)
+          3. **Details**: Use `<details><summary><b>Section Name</b></summary>` for expanded content
+          4. **Context**: Add helpful metadata (workflow run, date, trigger)
+          
+          ### Design Principles (Airbnb-Inspired)
+          
+          Reports should:
+          - **Build trust through clarity**: Most important info immediately visible
+          - **Exceed expectations**: Add helpful context like trends, comparisons
+          - **Create delight**: Use progressive disclosure to reduce overwhelm
+          - **Maintain consistency**: Follow patterns across all reports
+          
+          ### Example Report Structure
+          
+          ```markdown
+          ### Summary
+          - Key metric 1: value
+          - Key metric 2: value
+          - Status: ✅/⚠️/❌
+          
+          ### Critical Issues
+          [Always visible - these are important]
+          
+          <details>
+          <summary><b>View Detailed Results</b></summary>
+          
+          [Comprehensive details, logs, traces]
+          
+          </details>
+          
+          <details>
+          <summary><b>View All Warnings</b></summary>
+          
+          [Minor issues and potential problems]
+          
+          </details>
+          
+          ### Recommendations
+          [Actionable next steps - keep visible]
+          ```
+          
+          ## Workflow Run References
+          
+          - Format run IDs as links: `[§12345](https://github.com/owner/repo/actions/runs/12345)`
+          - Include up to 3 most relevant run URLs at end under `**References:**`
+          - Do NOT add footer attribution (system adds automatically)
+          
+          
           PROMPT_EOF
           cat << 'PROMPT_EOF' >> "$GH_AW_PROMPT"
           {{#runtime-import workflows/breaking-change-checker.md}}
diff --git a/.github/workflows/breaking-change-checker.md b/.github/workflows/breaking-change-checker.md
index d9e5e5754d..c3157ca20a 100644
--- a/.github/workflows/breaking-change-checker.md
+++ b/.github/workflows/breaking-change-checker.md
@@ -33,6 +33,8 @@ safe-outputs:
     run-success: "✅ Analysis complete! [{workflow_name}]({run_url}) has reviewed all changes. Compatibility verdict delivered! 📋"
     run-failure: "🔬 Analysis interrupted! [{workflow_name}]({run_url}) {status}. Compatibility status unknown..."
 timeout-minutes: 10
+imports:
+  - shared/reporting.md
 ---
 
 # Breaking Change Checker
@@ -128,6 +130,19 @@ Is it removing schema fields or making optional fields required?
 
 ## Step 5: Report Findings
 
+### Report Formatting Guidelines
+
+**CRITICAL**: Follow the formatting guidelines from `shared/reporting.md` to create well-structured, readable reports.
+
+**Key Requirements**:
+1. **Header Levels**: Use h3 (###) or lower for all headers in your issue report to maintain proper document hierarchy. The issue title serves as h1, so all content headers should start at h3.
+2. **Progressive Disclosure**: Wrap detailed analysis in `<details><summary><b>Section Name</b></summary>` tags to improve readability and reduce scrolling.
+3. **Report Structure**:
+   - **Summary** (always visible): Count of breaking changes, severity assessment
+   - **Critical Breaking Changes** (always visible): List of changes requiring immediate attention
+   - **Detailed Analysis** (in `<details>` tags): Full diff analysis, code examples
+   - **Recommendations** (always visible): Migration steps, version bump guidance
+
 ### If NO Breaking Changes Found
 
 **YOU MUST CALL** the `noop` tool to log completion:
@@ -153,19 +168,40 @@ Create an issue with the following structure:
 **Body**:
 
 ```markdown
-## ⚠️ Breaking Changes Detected
+### Summary
+
+- **Total Breaking Changes**: [NUMBER]
+- **Severity**: [CRITICAL/HIGH/MEDIUM]
+- **Commits Analyzed**: [NUMBER]
+- **Status**: ⚠️ Requires Immediate Review
 
-The following breaking changes were detected in commits from the last 24 hours.
+### Critical Breaking Changes
 
-### Breaking Changes Summary
+[List the most important breaking changes here - always visible]
 
 | Commit | File | Category | Change | Impact |
 |--------|------|----------|--------|--------|
 | [sha] | [file path] | [category] | [description] | [user impact] |
 
-### Commits Analyzed
+<details>
+<summary><b>Full Code Diff Analysis</b></summary>
+
+#### Detailed Commit Analysis
+
+[Detailed analysis of each commit with code diffs and context]
+
+#### Breaking Change Patterns Detected
 
-List the commits that were analyzed with their details.
+[Detailed breakdown of specific breaking patterns found in the code]
+
+</details>
+
+<details>
+<summary><b>All Commits Analyzed</b></summary>
+
+[Complete list of commits that were analyzed with their details]
+
+</details>
 
 ### Action Checklist
 
@@ -177,6 +213,10 @@ Complete the following items to address these breaking changes:
 - [ ] **Document breaking changes in CHANGELOG.md** - Add entries under "Breaking Changes" section with user-facing descriptions
 - [ ] **Verify backward compatibility was considered** - Confirm that alternatives to breaking were evaluated
 
+### Recommendations
+
+[Migration steps, version bump guidance, and action items - always visible]
+
 ### Reference
 
 See [scratchpad/breaking-cli-rules.md](scratchpad/breaking-cli-rules.md) for the complete breaking change policy.