Scrum Helper: a browser extension that writes your scrum report from Git activity

The report is the easy part

Scrum Helper is a Chrome extension that simplifies writing development reports by auto-filling content based on your Git activity. The workflow is deliberately short. You select your platform, enter your username, and provide authentication details when needed. You choose a date range and your preferences. The extension then fetches your commits, pull requests and issues through the selected platform's API, and for platforms that support review activity it includes code reviews in the generated report.

The output is editable. The usage section is explicit that you review and edit the generated report before using it in your preferred email or group platform, which is the right design for a tool that writes into a message other people read. Nothing is sent on your behalf; the extension fills a compose window.

The three supported platforms are GitHub, GitLab and Codeberg, and the point of supporting all three is that activity can be spread across them. A contractor working in GitLab, a maintainer on Codeberg and a company employee on GitHub can all produce a report from one tool.

There is a FOSSASIA landing page at fossasia.github.io/scrum_helper, the extension is published in the Chrome Web Store under the FOSSASIA name, and there is a standalone desktop application for Windows, macOS and Linux distributed through GitHub Releases. The licence is LGPL-2.1, and the project is a FOSSASIA one, which is the sort of provenance that matters for a tool that reads your private repository history.

Per-platform details that catch people out

The platform handling is not uniform, and the differences are the practical detail of using the extension.

Authentication is per platform, and it is optional. The documentation says to add authentication details when needed for private data or higher API limits, which is the honest framing, because the public API of a platform will give you your own public activity without a token, and a token is what grants access to private repositories and a higher rate limit.

GitLab has a Group filter. You can optionally provide one, and leaving it empty includes activity across all groups. That is a decision with a privacy dimension, since a report that spans every group you belong to is not the same as one scoped to your team, and the default of everything is the more revealing option.

Codeberg supports a custom API base URL, which matters because a hardcoded base URL would make the tool useless against a different instance.

Two of the newer features make the same point about credentials. Advanced Repository Filtering lets you select specific repositories to include in the report, with a searchable repository list in the popup, and the documentation states that it requires a GitHub personal access token of the classic type. The Include Commits on Existing PRs option, which includes recent commits made to pull requests opened before the selected date range so that long-running work is not lost, carries the same requirement.

That is a design choice worth noting. The features that need a token are the ones that read beyond your own default scope, and the documentation flags the requirement at the point where you would hit it rather than leaving you to guess.

It prefills the compose window

The integration that makes this more than a report generator is with the mail clients people actually use.

For Google Groups the flow is specific. You open Google Groups New Topic, start a New Conversation, refresh the page so the Scrum Helper settings are applied, and then use the pre-filled scrum and edit as needed. The refresh step is the kind of detail that only appears in documentation written by someone who did it, because without the refresh the extension has not injected itself into that particular page.

For Gmail, Yahoo and Outlook the flow is the compose window. You open it, make sure the Scrum Helper settings are applied following the same steps as before, and the extension prefills the scrum content for you to edit. The extension is listed as integrating directly with compose windows in Google Groups, Gmail, Yahoo Mail and Outlook.

The new Standalone Popup Interface changes the order of operations. You can generate reports directly from the extension popup, with a live preview of the report before sending, rich text formatting with clickable links, and a copy to clipboard action that keeps the formatting. So there are two routes to the same output: inject it into a compose window, or preview and copy it.

The Flexible Display Modes option lets you toggle the extension display between a traditional popup and an alternative mode, which is a small thing that matters when the extension is on your toolbar all day.

Manifest V3 forces a per-browser build

The development setup has one non-obvious wrinkle, and it comes from the browser extensions platform rather than from the project.

Because Chromium based browsers and Gecko based browsers handle Manifest V3 differently, the project uses a build step to generate engine-specific distributions. The build is a single command:

npm run build

The script is node build.js at the repository root, and the output lands in per-browser directories. The Chrome, Edge and Brave instructions are the standard developer mode flow: go to chrome://extensions, or edge://extensions or brave://extensions, enable Developer mode, click Load unpacked and select the dist/chrome folder. Opera works the same way with opera://extensions and the dist/opera folder.

Firefox is different because Gecko loads an add-on differently. You go to about:debugging, click This Firefox in the sidebar, click Load Temporary Add-on and select the manifest.json inside the dist/firefox folder. The documentation notes the consequence, that the extension remains active only for the current browser session, and suggests Firefox Developer Edition if you need persistence.

The dependency install is npm install, and the fork and clone step is the usual one:

git clone https://github.com/YOUR_USERNAME/scrum_helper.git
cd scrum_helper

So the extension you install from the Chrome Web Store is the same code as the one you load unpacked, just built for the engine you are running.

The Tauri desktop build and its prerequisites

The standalone application is a Tauri app, and the src-tauri/ directory at the repository root is the Rust side of it.

Tauri needs system libraries to build the webview and the Rust backend, and on Ubuntu or Debian that is a specific list:

sudo apt update
sudo apt install -y libwebkit2gtk-4.1-dev build-essential curl wget file libxdo-dev libssl-dev libayatana-appindicator3-dev librsvg2-dev

On Windows and macOS the documentation points at the official Tauri prerequisites guide for the C++ build tools and the platform specific WebKit SDKs.

Rust itself is installed with the standard toolchain installer:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

and the note about restarting your shell so that cargo is on your PATH is worth keeping, because a build that fails because cargo is missing produces a confusing error rather than an obvious one.

Development runs with npm run tauri dev, which gives a hot-reloading window, and production installers are built with npm run tauri build. The outputs are the standalone binaries, a.deb, an.AppImage, a.msi and a.dmg, and they are written to src-tauri/target/release/bundle/.

The two delivery shapes share the same report generation code, which is the point of maintaining both. The extension is for people who live in a browser and write their reports in a web mail client; the desktop app is for people who want the same output without the browser extension being present on every page they visit.

Tooling, tests and who maintains it

The JavaScript toolchain is small and modern. Biome handles everything, with the scripts for lint, format, check, fix and check:write all delegating to it, so there is no ESLint and Prettier pair to argue about. Tailwind 4 is there with the CLI package, PostCSS and autoprefixer. Tests run on Vitest with happy-dom as the DOM environment, and the configuration lives in vitest.config.js. The tests/ directory is at the repository root.

There are also a webstore/ directory, which holds the store listing assets, a deploy/ directory for the landing page, and an agents.md file, which is the instruction file for coding agents working on the repository. The other root files are CHANGELOG.md, CONTRIBUTING.md, the LICENSE file and a .github/ directory.

The package manifest states the name as scrum-helper, the author as FOSSASIA, the licence as LGPL-2.1 and the keywords as scrum, google groups and fossasia, and the bugs URL points at the issue tracker on GitHub.

The release history is worth reading for the shape of the project. Version 2.0.3 came in February 2026, 2.1.4 a few weeks later on 2026-02-28, and 2.1.5 on 2026-10-12, with the last push on 2026-10-15. The gap between 2.1.4 and 2.1.5 is seven months, which for a FOSSASIA community project is a healthy rhythm, and the newer features, the standalone popup, the repository filtering and the pull request commit option, are the visible result of that work.

Editorial conclusion

Adopt Scrum Helper if your team writes a daily report in a web mail client or a Google Groups thread and you would rather spend the time on the content than on the retrieval, especially if you work across more than one Git host. Do not adopt it if your work is not in Git activity, since the report is only as good as the commits and reviews the platforms expose. Before you start, decide whether you need a personal access token, because the advanced repository filtering and the include commits on existing pull requests options both require a GitHub classic token, and read the Google Groups steps, where the page has to be refreshed for the settings to apply.

Frequently asked questions

Official sources

1. fossasia/scrum_helper on GitHub
2. License: LGPL-2.1
3. Project website
4. README
5. Releases