Work Log and Weekly Update Builder from Git and Issue Activity

The problem new engineers have remembering their own work

Keeping a record of your work is one of the most useful habits in a first job and one of the most commonly skipped. Weekly updates to your manager, one-on-ones and performance reviews all need evidence, and memory is unreliable after a few weeks. When review season arrives, junior engineers scroll through months of GitHub history trying to reconstruct what they did and why it mattered. The "why" is usually lost.

The people with this pain are developers in their first few years, especially at companies with formal review cycles, and anyone preparing for a promotion conversation.

What already exists and the gap

• Julia Evans' brag document idea is a widely shared template for writing down your work, but it is a manual document.
• BragDoc is a tool that analyses your git commits locally with AI and turns them into achievements and documents for your manager.
• Standup bots such as Geekbot collect daily updates in Slack for teams, driven by the team rather than the individual.
• GitHub's own profile and search show activity but not impact.

The gap is a small, individual, privacy-first tool that pulls activity from the source of truth and asks you for one line of context while you still remember it, with no AI required and no source code stored.

What you build

One user role: the developer. The main flows:

1. Sign in with GitHub, see a clear explanation of scopes, and pick which repositories to include.
2. Sync the week: merged pull requests, reviews given and closed issues.
3. On the weekly screen, add a one-line note to the items that mattered.
4. Generate a weekly update (shipped, in progress, blocked, need from others), edit it and copy it.
5. Watch the monthly brag document grow and export it as Markdown.
6. Export or delete everything at any time.

The technically interesting part

The hard part is a correct, polite sync against a rate-limited API. GitHub paginates results and enforces rate limits; your job must follow pagination links, read the remaining-quota headers, back off when needed, and resume without re-fetching everything. Store each item's source id with a unique constraint so a second sync is a no-op, and use a sync cursor per user so incremental syncs only fetch new activity. This is the same idempotent sync pattern used by every integration product.

The second part is least privilege. Compare an OAuth App with a GitHub App with fine-grained, read-only permissions, choose one and justify it. Store tokens encrypted, never log them, and document exactly which fields you persist.

How to evaluate it

• Idempotency: run the sync twice on the same range and show zero new rows; test with a fixture of paginated API responses.
• Rate limits: simulate a low quota and show the job pauses and resumes correctly.
• Usefulness: five developers (interns or recent graduates) use it for three weeks; record how many items get notes and whether they used the generated update with their manager.
• Time saved: ask each tester how long a weekly update took before and after.
• Privacy: a checklist showing scopes requested, fields stored, and that deletion removes every row.

Suggested plan

1. Week 1: OAuth sign-in, scope decision and a plain-language data page.
2. Week 2: sync job with pagination, rate limit handling and deduplication.
3. Week 3: weekly view, notes, update generator.
4. Week 4: brag document, export and delete, tests in CI.
5. Weeks 5 to 6: three-week pilot with five developers and the write-up.

Path to a product

The first users are you and your classmates starting internships. Keep it open source so developers can self-host and trust it; that is the honest route to adoption for a tool that touches work data. A hosted version with a small monthly subscription for extra sources (GitLab, Jira, Linear) is a realistic model. A team version for managers is possible later, but it changes the privacy story, so treat it carefully.

Scope warning

Do not store or analyse source code. Do not build an AI summariser in version one; the user's own notes are the point. Do not add team dashboards or manager views. Many companies do not allow third-party apps on their organisation, so design for personal or permitted accounts and say so in the README.

Learn what you need on Sefism

• Backend roadmap : APIs, databases and background jobs for the sync.
• OAuth 2.0 Simplified : the OAuth flow and scopes, explained clearly.
• Get Your Work Recognized: Write a Brag Document : the habit this tool supports.
• Next.js Documentation : routes, server actions and auth for the app.
• How do I get promoted from junior to mid-level developer? : why a record of impact matters.

Get help with this idea

This is a small, finishable project with a real daily user: you. Tauseef can help you choose the right GitHub auth model, tighten the privacy design and plan a pilot that shows the tool helps. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session