Worklog

If user belongs to multiple orgs:

• Check which orgs have commits that day
• If only one org has commits, use it without asking
• If multiple orgs have commits, ask user which org(s) to include

Writing the Worklog

Read the full commit messages and synthesize into a coherent worklog. Do NOT just list commit messages.

Output directly as text. Do NOT create a file.

Multi-Repo Layout

When commits span multiple repos:

1. Main repo (most commits) - listed normally, no label
2. Other repos - listed after, prefixed with "On [label]," derived from repo name

Derive labels by dropping the common org/project prefix:

• politech-frontend → "On frontend, ..."
• politech-admin → "On admin, ..."
• politech-landing → "On landing, ..."
• If repo has no clear suffix, use the full repo name as label

Rules

For significant features:

• 3-5 sentences, enough to show the substance and scope of the work
• Describe what it does so a non-developer can understand, but keep enough meaning to convey the actual work done
• Use plain language but don't strip context that gives meaning to the work
• Include key aspects like what was built, who it affects, and how it works at a high level

For small fixes:

• 1-2 sentences
• State what was fixed and briefly why it mattered

Skip entirely:

• Makefile, README, docs, configs
• CI/CD, lint, code style
• Test-only changes
• Developer tooling

Style

• Write so a non-developer manager can understand the work
• Don't use raw code terms (endpoint names, model names, API paths, class names)
• But DO keep enough technical context so the meaning of the work isn't lost
• "Added discount code system with admin management and automatic application to subscriptions" - good (clear, meaningful)
• "Added DiscountCode model with CRUD endpoints under /discounts" - bad (raw code terms)
• "Fixed database issues" - bad (too compressed, lost the meaning)
• "Fixed issue where deleted articles could still cause conflicts when new articles with the same URL were added, preventing proper article tracking" - good (explains what and why)

Format

Single repo:

YYYY-MM-DD

- [Feature description].

- Fixed [what was broken].

Multiple repos:

YYYY-MM-DD

- [Main repo feature].

- Fixed [main repo fix].

- On frontend, [frontend work].

- On landing, [landing work].

Example

Commits across repos: