Git What

git-what

git-what turns git history into plain, paste-ready summaries for App Store Connect, Play Console, Slack, or email. It provides several commands, all of which run inside a git repo.

Shared output rules

Every command shares the same final processing and output. Only source data collection differs from command to command. These rules apply to all commands:

• Use plain text, simple bullets (• or -), and basic separators (blank lines, ---) when helpful
• Do not use heavy markdown: no # headings, no **bold**, no backticks, no code blocks in the delivered output
• A short plain title line (e.g. What's new) is fine when it reads as summary text, not as markdown structure
• No commit hashes in the final output
• Do not invent changes. If a change is unclear, say so briefly or omit it
• Use plain language, no technical terms (no file names, APIs, stores, refactors, TTL, debounce, etc.) unless the command's output shape requires them
• Merge similar items into single bullets instead of one bullet per commit or file
• Past or present tense is fine; stay consistent within the list
• Do not include Co-Authored-By footers or any AI attribution

Each command below documents how it collects its source data and the output shape it follows on top of these shared rules.

gw-changelog

Generate short Play Store / App Store release notes from git history.

Usage

gw-changelog <commit_id>

If COMMIT_ID is missing, ask the developer for the starting commit before continuing.

Source data collection

1. Run git log <commit_id>..HEAD --no-merges --format="%h %s%n%b%n---" to collect commits from the given commit (exclusive) through HEAD.
2. Read commit subjects and bodies. Use git show or git diff <commit_id>..HEAD --stat only when a commit message is too vague to judge user impact.
3. Keep only changes that affect the end user. Drop build scripts, lint fixes, refactors, dependency bumps, CI, and internal tooling unless they clearly change app behavior.

Output shape

• Start with a short plain title line such as What's new (no extra intro paragraph unless asked)
• 4–8 bullets max when possible
• Each bullet = one user-visible theme (notifications, links, comments, login/guest behavior, bug fixes)

Example output shape

What's new

• Tapping notifications from your phone or the in-app list now opens the right article, comment, or badge
• Comment alerts scroll to the right place on the article
• Fixed duplicate alerts on Android and a freeze when opening articles from comment alerts
• Shared links open more reliably after sign-up and no longer misroute after log out

gw-verify

Generate a tester verification checklist for the same commit range as gw-changelog.

Usage

gw-verify <commit_id>

If COMMIT_ID is missing, ask the developer for the starting commit before continuing.

Source data collection

1. Run git log <commit_id>..HEAD --no-merges --format="%h %s%n%b%n---" to collect commits from the given commit (exclusive) through HEAD.
2. Read commit subjects and bodies to identify what changed and what user-facing behavior is affected.

Output shape

• Start with a short plain title line such as Verification checklist (no extra intro paragraph unless asked)
• 4–12 checks; one bullet per check
• Each check starts with an imperative verb (e.g. Verify, Check, Confirm, Test, Try)
• Group related checks under a short plain section label line (labels read as summary text, not markdown structure)
• Cover at least: the main flow of each change, the edge cases called out in commits, and the most likely regressions (neighboring flows touched by the same area)

Example output shape

Verification checklist

Notifications
- Verify tapping a notification on the phone opens the correct article
- Check the in-app notifications list opens the right comment or badge
- Confirm comment alerts scroll to the right place on the article

Login and sharing
- Test opening a shared link right after sign-up
- Confirm a shared link opened after logging out lands on the right article
- Verify no duplicate alerts appear on Android
- Check the app no longer freezes when opening articles from comment alerts

gw-staged

Generate a commit message covering only screens created/updated/removed and APIs integrated/updated. Merge common items into single bullets.

Usage

gw-staged

Operates on the current uncommitted working tree (staged + unstaged + untracked). No commit ID needed.

Source data collection

1. Run git status --porcelain and git diff --stat to enumerate changed and untracked files.
2. Read diffs for screen files and API/service files. The exact locations vary by repo. Common defaults to check first: screens under src/screens/** and src/navigation/**; API/service code under src/api/**, src/services/**, src/types/**. If the repo does not use these paths, discover the equivalents: look for where UI components and data/API code live (e.g. lib/, app/, features/, pages/, or a top-level api/ / services/ directory) and use those instead.
3. Drop non-screen, non-API changes (plans, docs, lint fixes, config, tests for non-API code) from the commit body. Do not mention them.
4. Do not invent changes. If a diff is unclear, inspect the file before deciding the bullet.

Output shape

• Subject line: feat/fix/chore(<scope>): <short summary of primary screen or API change>. Scope = affected tab/feature (e.g. profile, auth, chat). Derive the scope from the changed areas, not from a fixed list.
• Two sections only: Screens and APIs. Omit a section if empty
• 3–7 bullets per section max; merge common items
• Each bullet starts with a verb: Add, Update, Remove, Integrate, Wire
• For APIs: include HTTP method + path (e.g. Integrate GET /customer/me/call-history)
• For screens: state screen name + the user-visible change (new screen, new section, removed flow)

Example output shape

feat(profile): add bank accounts, call history, call detail screens

Screens
- Add BankAccounts screen with bank list, primary badge, add-account sheet
- Add CallHistory screen listing past/missed expert calls with advisor header
- Add CallDetail screen with summary, key points, action items, notes PDF download
- Update Profile screen to wire BankAccounts + CallHistory row routes
- Update NomineeDetails screen: add "Folios with nominee" section, drop percentage column
- Update MainTabBar: profile tab icon now reflects focused state

APIs
- Integrate GET /customer/me/call-history (list)
- Integrate GET /customer/me/call-history/{scheduleId} (detail)
- Integrate GET /customer/me/call-history/{scheduleId}/notes.pdf (binary download via new apiGetBinary helper)
- Update CustomerAccount + PatchCustomerAccountPayload types: add taxType, occupation, contactOwner, sourceOfFunds, politicallyExposed, placeOfBirth, countryCode fields; rename IncomeRange enum values to backend contract

gw-week / gw-fortnight / gw-month

Personal work summaries for the last 7 / 15 / 30 days. They share one implementation; the only difference is the time window.

Usage

gw-week
gw-fortnight
gw-month

No commit ID needed. The window counts back from today (7 / 15 / 30 days).

Source data collection

1. Resolve the current git user from the repo's own config: run git config user.name and git config user.email. Do not assume a username; use whatever the repo reports.
2. Build the author filter. Match commits by the git user's name OR email (a commit matches if the author name equals user.name or the author email equals user.email). Run one pass per identity because git's --author is a regex, not a plain name/email matcher.
3. If the repo was just cloned or has branches reachable only through a remote, run git fetch --all first so remote-tracking branches are current.
4. Collect commits across ALL active branches, not just the current one:
   • git log --all --no-merges --author="<name>" --since="<N> days ago" --format="%h %s%n%b%n---" and the same again with --author="<email>"; combine both result sets and drop duplicate hashes
   • Use --all to cover every local and remote-tracking branch in one pass.
   • Drop merge commits (--no-merges) to avoid duplicate summaries of the same work.
5. Read commit subjects and bodies. Use git show when a message is too vague to summarize.
6. Filter to the current git user's work only. Anything committed by other authors is excluded.

Output shape

• Start with a short plain title line reflecting the window, e.g. This week / Last fortnight / Last month
• 4–8 bullets max when possible; each bullet = one work theme
• Commits that exist only on branches other than the current one are expected to appear — that is the point of the --all scan
• If there are no commits in the window, say so plainly rather than inventing output

Example output shape

This week

• Finished the onboarding flow: sign-up, profile setup, and guest access all work end to end
• Reworked how shared links open so they land on the right article after sign-up or log out
• Fixed a freeze on Android when opening articles from comment alerts
• Tightened notification behavior — taps now open the correct article, comment, or badge

Version history

• v0.0.1: gw-changelog, gw-verify, gw-staged
• v0.0.2: adds gw-week, gw-fortnight, gw-month — personal work summaries for the last 7 / 15 / 30 days, filtered to the current git user, across all active branches. Adds skill metadata (keywords, tags) for discoverability.