MADE Support Bundle

Reporting at
Near-Zero Effort

Support, status, and stories from the session itself

The MADE Support Bundle

The report you need is already in your session

Your team's support needs, daily status, and wins are created inside the Amplifier sessions people are already running. They just leak out before anyone sees them — the value exists in the work; the problem is capture.

So what actually ships to close that gap?

Proof — it's real and shipped

One include block unifies three capture paths across 7 recipes

The bundle's bundle.md wires together support requests, team status tracking, and story submissions — the whole thing runs on 7 recipes.

Real and shipped. So why is capture still needed?

3
capture capabilities in one bundle: support, status, stories
7
recipes powering the bundle
The problem

Today the value leaks out of the session

Three failure modes are exactly what the bundle exists to fix — each pillar answers one of them.

Start with the first leak: support requests.

Requests get lost in chat
A real support need is described mid-session and never filed anywhere.
Status is a manual ceremony
Updating what you did is a tedious, separate chore.
Wins go unshared
A finished result never becomes something the team can see.
Pillar 1 — support requests

Say "I need help with…" and the issue files itself

The trigger phrase launches a 7-step workflow that analyzes the session, confirms with you, dedupes, and files a GitHub issue to microsoft-amplifier/amplifier-support.

Capture, not typing. Next: status that writes itself.

1
Check GitHub access
2
Extract the issue from the session
3
Confirm with you
4
Find duplicates, then file & return the URL
Pillar 2 — team status

An opt-in hook makes status write itself

The hook fires on three triggers and appends a progress bullet only when the session's own LLM confirms real work — reading, browsing, and brief chat are excluded. It's off by default and pushes to a shared team-status.md.

Automatic and gated. Last pillar: ship the win.

10
turns between checks (TURN_THRESHOLD)
3
triggers: 10 turns, git operations, session end
300s
default throttle between pushed updates
Off
by default — needs enabled:true + an include path
Pillar 3 — story submissions

Say "amplifier story" and the win ships as a PR

The session becomes an HTML deck, then submit-story-pr.yaml clones the stories repo, creates a story/ branch, commits into staging/, and opens a PR to ramparte/amplifier-stories.

Three capture paths, one session. Here's what that adds up to.

1
Session becomes an HTML deck
2
Clone the stories repo, create a story/ branch
3
Commit into the staging folder
4
Open a PR to ramparte/amplifier-stories
The payoff

The session becomes the single source of truth

Because the report already lives in the work, support, status, and stories all flow from the session itself: file an issue by describing it, status writes itself, and a win ships as a PR — all without leaving the work.

File an issue by describing it Status writes itself A win ships as a PR
The takeaway

Capture at the source

When reporting rides on the work instead of sitting beside it, it actually happens. Put the capture where the value is created — and near-zero-effort reporting stops being a goal and starts being the default.

Sources

Research Methodology

Repo: microsoft-amplifier/amplifier-bundle-made-support — analyzed against main (60 commits, ends 2026-02-06).

Feature status: LIVE (team-status hook is LIVE but OFF by default / opt-in).

Research performed — every claim re-derived from:

Gaps: Real-world usage counts (issues filed, stories shipped, status pushes) are not verifiable from this checkout — amplifier-support is private and no metrics were queried. Local HEAD branch has a corrupt git object, so analysis used the valid main ref.

Primary contributors: Salil Das (sadlilas) — 58 commits, primary author of all 3 pillars and PRs #3/#4/#5; Samuel Lee — 2 commits.

More Amplifier Stories