non-technical-reporting-summarylisted

# Non-Technical Reporting Summary Produce a concise summary of the current branch or PR suitable for engineering managers and senior leadership. The audience is non-technical — they care about *what changed and why it matters*, not how it was implemented. ## Gathering Context 1. Run `git branch --show-current` to identify the branch. 2. Run `gh pr view --json title,body,url` to get the PR description and link. 3. Run `git merge-base HEAD main` then `git log --oneline <base>..HEAD` and `git diff --stat <base>..HEAD` to understand the scope of changes. 4. Read the changed files only if the PR description and diff stat are not enough to understand intent. ## Output Format Produce exactly this structure, wrapped in a fenced code block so the user can copy it verbatim for import into a notebook. Use a four-backtick fence (since the content itself contains triple-backtick-free markdown headings, a four-backtick outer fence keeps it copyable as one unit): ````markdown # <PR title> - <PR URL> ## What we did <1-3 sentences. Plain language. Describe the change in terms of what it does for the team, the product, or the process — not how it works internally. No file names, no tool names, no technical jargon unless the audience would know the term.> ## Expected outcome <1-3 sentences. What improves, what risk is reduced, what becomes possible next. Concrete when possible (e.g. "cutting CI time by ~X%") but honest when speculative (e.g. "once validated, will allow us to...").> `