# Git What > Generate release notes, tester verification checklists, and commit summaries from git history. Use whenever the user asks for release notes, changelog, app store / play console notes, what's new notes, tester verification checklists, QA regression checklist, commit summaries, commit messages, or invokes any gw-* command (gw-changelog, gw-verify, gw-staged, gw-week, gw-fortnight, gw-month) inside a git repo. Also use when the user asks to summarize work done in the last week / fortnight / month, daily standup updates, sprint reports, work logs, or to review recent work on all branches. - Skill: `gam3rg33k/git-what` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add gam3rg33k/git-what` - Raw SKILL.md: https://api.skillmd.com/api/skills/gam3rg33k/git-what/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - License: MIT - Author: GAM3RG33K (https://skillmd.com/u/gam3rg33k) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/gam3rg33k/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 ``` If `COMMIT_ID` is missing, ask the developer for the starting commit before continuing. **Source data collection** 1. Run `git log ..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 ..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 ``` If `COMMIT_ID` is missing, ask the developer for the starting commit before continuing. **Source data collection** 1. Run `git log ..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 = 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="" --since=" days ago" --format="%h %s%n%b%n---"` and the same again with `--author=""`; 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.