marve10s Meeting Update
Use the user's current local timezone and treat 18:00 as the evening meeting boundary.
Time window
- Tuesday: include work completed after Thursday at 18:00 through the time of the Tuesday update.
- Thursday: include work completed after Tuesday at 18:00 through the time of the Thursday update.
- On another day, ask which meeting the update is for rather than guessing the window.
The opening boundary is exclusive. Do not repeat work completed earlier on the previous meeting day; the user already covered it in that evening's update.
Build the update
Use repository and GitHub history as the source of truth. Collect work by the user's GitHub account that reached a shared branch during the window:
- pull requests merged during the window;
- direct commits pushed during the window;
- app releases shipped during the window (TestFlight or Play builds, OTA updates);
- open PRs with live preview deployments, A/B tests, or experiments running — name each experiment and feature concretely, never as generic "docs work" or "misc fixes".
Do not count the same change twice when a PR and its merge or squash commit both appear. Exclude other authors' work. Exclude unmerged or unfinished work unless the user asks to include work in progress.
Combine related changes into one meaningful item. Describe the problem solved, user or business effect, and important context rather than filenames, implementation inventories, test commands, or commit mechanics.
Output
Write a short first-person update that the user can say naturally in a meeting. Lead with the most important outcome and keep the language understandable to a nontechnical manager. Do not add confidence scores, verification sections, commit hashes, or a long source list.
If the history is ambiguous or incomplete, state the uncertainty instead of inventing work. Include PR links or a compact evidence list only when the user asks for it.