My Weekly Report

/my-weekly-report — Weekly Status Update Generator

Generate a concise weekly update in the team's standard format.

Format

## Abin Simon

**What I worked on:**
- <bullet per notable thing done in the reporting week>

**What's next:**
- <bullet for each To Do ticket in the current sprint>

**Blockers:** None
**Upcoming leaves:** None
**Unplanned leaves last week:** None

Always output the report directly in the chat — do NOT write it to a file.

Critical: sandbox

Every command below hits a network API (Jira, GitHub, Confluence) and will fail with a TLS/certificate error under the default sandbox. Run every Bash call in this skill with dangerouslyDisableSandbox: true. This is the single most common failure mode when running this skill — if a command fails with tls: failed to verify certificate or similar, that's the sandbox, not a real problem.

Steps

1. Compute the reporting window

"What I worked on" covers the most recently completed Monday-Sunday week — not "since Monday of this week." Reports are typically generated a day or more into the new week, so the prior full week is what has actual completed work to report; the current week in progress rarely does.

~/.agents/skills/my-weekly-report/scripts/last-week-backlog.sh

With no argument this returns last week (Mon-Sun). Pass 0 instead to get the current week-to-date if the user explicitly asks for that.

The output labels every day with its weekday name and date, including Saturday/Sunday (shown as "(no entries)" if empty) — this lets you see the full week shape and decide whether weekend work is worth including.

Do not filter items out on the assumption they're personal. If it's ambiguous whether something is personal or work (e.g. "Apply for leave", "Schedule 1-on-1s"), leave it in your working notes and let the final "What I worked on" draft skip only the obviously-personal ones (banking, health, shopping). When genuinely unsure, include it — the user filters the final draft, not you.

Note on refiling — normally not something you need to think about. The target week should already be in Backlog.md's ## Before section, since that's the week just completed. This only becomes relevant if last-week-backlog.sh comes back empty for every single day (e.g. a manual re-run for an older week): the vault periodically refiles old ## Before entries out of Backlog.md into Backlog/Refiled/YYYY/MM/Backlog.md. Those refiled files drop the ## Before header — they're just bare ### YYYY-MM-DD (Day) sections at the top of the file. If you hit an all-empty week, check the matching Refiled/YYYY/MM/Backlog.md directly instead of assuming it was a light week.

2. Get the exact date range as YYYY-MM-DD

You'll need this for steps 3 and 4. Compute it the same way the script does:

dow=$(date +%u)
this_monday=$(date -d "-$((dow - 1)) days" "+%Y-%m-%d")
start=$(date -d "$this_monday -7 days" "+%Y-%m-%d")   # last Monday
end=$(date -d "$this_monday -1 days" "+%Y-%m-%d")     # last Sunday

3. Check GitHub PRs (authored + reviewed)

~/.agents/skills/my-weekly-report/scripts/pr-activity.sh "$start" "$end" $(cat ~/.config/datafiles/prs-repos)

Returns { "authored": [...], "reviewed": [...] } for that date range.

• authored: PRs you opened or that got merged in the window — evidence of completed work, use to enrich or add bullets.
• reviewed: PRs where you left a review or comment in the window (checked per-PR, not just by the PR's own updatedAt — a stale-looking PR can still have a fresh review from you). Roll these into a single "PR reviews" bullet with short refs (e.g. cpb#5152, cpb#5372) rather than listing each as its own bullet.

If this returns mostly empty, don't pad the report — a light week is a light week. But cross-check step 1's output first: PR review activity in particular is easy to under-report from GitHub data alone if the backlog already names who/what was reviewed.

4. Check Confluence for docs touched in the window

~/.agents/skills/my-weekly-report/scripts/confluence-updates.sh "$start" "$end"

If any design docs, runbooks, or notable pages were created or edited, add a bullet (e.g. "Continued Org Anchoring design — updated Tech Spec doc").

5. Get current sprint's To Do tickets

jira sprint list --plain --state active --table --no-headers --columns id,name

(Or just run sprint-tickets.sh, below — it does this lookup internally.)

~/.agents/skills/my-weekly-report/scripts/sprint-tickets.sh

Returns JSON grouped by status: done, in_progress, to_do. Only the to_do list feeds "What's next." Do not pull "What's next" from the backlog's Tomorrow/This Cycle/Next Cycle sections — those are personal planning, not the sprint board, and mixing them in was a mistake corrected in a past run of this skill. If done/in_progress are non-empty, they can supplement "What I worked on," but the backlog archive (step 1) is usually the richer source for that.

6. Build the report

What I worked on:

• Synthesize step 1 (backlog), step 3 (PRs), and step 4 (Confluence) into concise, deduplicated bullets — don't list the same underlying piece of work twice just because it showed up in two sources.
• Group related items (e.g. all Org Anchoring work in one bullet, all PR reviews in one bullet) rather than one bullet per raw backlog line.
• Include a Jira link where a ticket ID is known.

What's next:

• One bullet per to_do sprint ticket (step 5), with Jira link.

Blockers / leaves:

• Default all three fields to "None" unless the backlog explicitly says otherwise (leave requests, blocker notes).

Keep bullets as short phrases, not full sentences — match the style in /Users/meain/.local/share/sbdb/InfraCloud/Weekly Updates Submitted/.