Turn GitHub Activity Into a Weekly Client Delivery Brief

A client asks, “What did the team finish this week?” The answer should be easy. The proof is already in GitHub. Yet someone still spends Friday afternoon opening repositories, reading pull requests, checking issues, and turning technical notes into a clear update.

That work matters. Clients need to see progress, risks, and decisions without reading a commit log. But rebuilding the update by hand every week is slow, and small details are easy to miss.

A safer approach is to give an Agentic Workers Super Agent one narrow recurring job: collect approved GitHub activity, turn it into a draft client brief, and stop for review before anything is sent.

The business problem is not missing data

Most software teams already record the raw facts. Commits show code changes. Pull requests show reviewed work. Issues show open questions and completed tasks. The problem is that these records were written for the people doing the work, not for the client paying for the outcome.

A useful client brief must answer different questions:

• What was completed?
• What is different for the client or their users?
• What is still in progress?
• What is blocked or at risk?
• What decision or approval is needed next?

The agent should not invent those answers. It should gather evidence, translate technical activity into plain language, flag gaps, and prepare a draft for a person to approve.

Give the agent a small, stable set of inputs

Start with one client, one repository group, and one weekly reporting window. More sources create more chances for duplicate or misleading claims.

The first version needs:

1. The approved GitHub repositories.
2. The start and end of the reporting week.
3. The client name and project goal.
4. A short glossary for internal names, features, and workstreams.
5. The brief format and its owner.
6. A list of labels or branches to exclude, such as experiments or internal maintenance.

Agentic Workers has a GitHub connector that can retrieve repository, issue, pull request, and commit information. Connect only the account and actions needed for this job. If the brief only needs to read activity, do not grant write access.

Set up the workflow before you schedule it

First, write the output contract. A simple weekly brief can contain five sections:

• Delivered: completed work with links to supporting pull requests or issues.
• In progress: active work that has not been presented as finished.
• Risks and blockers: missing access, failed checks, unresolved questions, or work that slipped.
• Decisions needed: clear questions with an owner and due date.
• Next week: planned work that is supported by the project plan, not guessed from code activity.

Then define the translation rules. A merged pull request is evidence that code was merged, not proof that a feature reached production. A closed issue is evidence that the issue was closed, not proof that the client accepted the result. Commit volume is activity, not business value.

Use the product’s guidance for connecting apps and tools: start with the smallest useful permission set, test exact access with a narrow request, and require approval for sensitive actions.

Run the brief in seven steps

1. Collect the week’s activity

The Super Agent reads the approved repositories for the agreed date range. It gathers merged pull requests, closed and open issues, selected commits, review activity, and failed or pending checks.

It should record source links beside each fact. If a repository cannot be read, the run should say so instead of treating the missing repository as quiet.

2. Remove noise and duplicates

The agent groups commits under their pull request when possible. It removes bot updates, dependency noise, merge commits, and excluded labels. It also keeps work from different clients or projects separate.

This step should be rule-based. The agent should not decide that a technical change is unimportant just because its name sounds small.

3. Classify the work

Each item goes into one of four states: delivered, in progress, blocked, or needs review. Items with unclear state go into an exception list.

A change belongs in “delivered” only when the evidence matches your definition of done. If deployment status is not available, the wording should say “merged” rather than “released.”

4. Translate the evidence

The agent turns technical records into short client-facing explanations. It keeps the source link and avoids claims the evidence cannot support.

For example, “Refactored auth middleware” might become “Simplified the sign-in code so future access changes are easier to maintain.” That sentence is acceptable only if the pull request supports it. If the business effect is unclear, the agent should quote the technical fact and ask for clarification.

5. Check the draft against the evidence

Before presenting the brief, the agent checks that every delivered item has a source, every blocker has an owner or an explicit “owner needed” label, and no item appears twice.

It should also compare this week with the prior brief. That catches work that was reported twice and blockers that disappeared without a recorded resolution.

6. Stop for human review

The account lead or project lead reviews the draft. They confirm the business meaning, remove confidential internal detail, add context from meetings, and approve the final wording.

The agent may prepare the update in a document, client workspace, or message draft. It should not send or publish the brief in the first version of the workflow.

7. Schedule only after the dry run works

Run the workflow manually with a past week first. Compare its draft with the update the team actually sent. Fix the source scope, definitions, and exclusions before adding a schedule.

Agentic Workers supports recurring jobs with dry runs, time zones, owners, approvals, and run history. Start weekly. Check the first few run traces before treating the brief as routine.

Keep permission and approval boundaries clear

The safest first version is read-only in GitHub and draft-only everywhere else.

The agent may:

• read approved repository activity;
• organize evidence;
• draft plain-language summaries;
• flag missing facts and conflicting states;
• prepare a review copy.

The agent may not:

• merge code or change issues;
• claim deployment without deployment evidence;
• expose private repository details to the wrong client;
• send the brief without approval;
• guess at business impact, timelines, or owner intent.

For agencies running this across several clients, use separate client workspaces and separate repository scopes. Do not rely on the agent to remember which client may see which project.

Define stop conditions and failure handling

A good recurring workflow knows when not to produce a normal-looking report.

Stop the run and request help when:

• a required repository cannot be read;
• the date range is missing or wrong;
• project ownership cannot be resolved;
• source links point to another client;
• deployment status conflicts with issue or pull request state;
• the brief has no evidence for a claimed delivery;
• the output destination or reviewer is unavailable.

For a partial failure, produce an exception note, not a polished brief that hides the gap. Keep the last approved brief unchanged. After access or rules are repaired, rerun the same reporting window so the result can be compared.

Review the workflow, not just the writing

For the first month, review each run. After that, check the workflow monthly or whenever repository structure, permissions, reporting rules, or client ownership changes.

Useful measures are simple:

• percentage of brief items with a valid source link;
• number of corrections made during review;
• number of missing repositories or failed reads;
• duplicate items caught before approval;
• time from scheduled run to approved draft;
• client questions caused by unclear or unsupported wording.

Do not measure success by commit count or word count. The goal is a trustworthy update that takes less effort to verify.

Start with one reversible test

Choose one active client and one completed week. Give the Super Agent read-only access to two or three repositories. Ask it to create the five-section brief, but keep the result private.

Have the account lead mark every sentence as supported, unclear, or wrong. If the draft is easy to verify and the errors are fixable with better rules, run a second weekly test. Schedule it only after two clean dry runs.

This workflow was inspired by an Agent Use Cases example and the original DEV Community project. Their pipeline turns weekly GitHub activity into draft content. The business adaptation here keeps the evidence-gathering pattern but changes the outcome to a reviewed client delivery brief.

Start with one Agentic Workers workspace