Weekly Report

Generate Weekly Report

Build a weekly work report from three sources of evidence: local Codex sessions, local Claude Code sessions, and GitHub pull requests. Write it as Markdown or a single self-contained HTML deck. No external services are required for the HTML, which opens straight from disk.

Workflow

1. Determine the date range.

• If the user specifies dates, use those exact dates.
• Otherwise use the last 7 calendar days ending today, inclusive, in the user's current timezone.
• Always render dates as YYYY-MM-DD.
• Use Weekly Report YYYY-MM-DD to YYYY-MM-DD as the report H1.
• Use Weekly-Report-YYYY-MM-DD-to-YYYY-MM-DD.{md,html} as the filename. No spaces in report filenames.

1. Collect local coding-agent activity.

• Unless the user explicitly scopes the report to one agent, collect both Codex and Claude Code activity.
• Run scripts/collect_codex_activity.py --start YYYY-MM-DD --end YYYY-MM-DD --format markdown for Codex. It scans $CODEX_HOME/sessions, $CODEX_HOME/archived_sessions, ~/.codex/sessions, and ~/.codex/archived_sessions.
• Run scripts/collect_claude_activity.py --start YYYY-MM-DD --end YYYY-MM-DD --format markdown for Claude Code. It scans $CLAUDE_CONFIG_DIR/projects (or ~/.claude/projects).
• Treat a session as active when any event timestamp falls inside the range, not just when the file was created.
• Use user prompts, working directories, git branches, final assistant messages, changed files, git commands, commit hashes, PR URLs, and pr-link events as evidence. Do not copy raw logs into the report.
• Each collector's --max-sessions defaults to 40; raise it for a busy week. If either output is truncated, say so.
• If one agent has no session store or no activity in the range, continue with the other source and mention the missing coverage only when it materially limits the report.

1. Collect GitHub PRs.

• Prefer the GitHub connector/MCP tools if available. Identify the authenticated user, search authored PRs created or updated in the range, then fetch metadata (and discussions for important ones).
• Otherwise, if gh is authenticated: gh search prs --author @me --updated ">=YYYY-MM-DD" --json number,title,url,state,createdAt,updatedAt,closedAt,repository, then enrich the key PRs with gh pr view --repo --json mergedAt,additions,deletions,changedFiles,reviewDecision.
• Note: gh search prs does not support mergedAt/additions/reviewDecision in --json — get those from gh pr view.
• If neither is available, fall back to local git log from repos seen in the sessions and note that PR coverage may be incomplete.

1. Deduplicate and classify.

• Merge Codex, Claude Code, and PR evidence when they describe the same work. Avoid counting the same change twice when it appears in both coding agents.
• Drop meta-work such as the report-generation session itself, unless the user wants to report on tooling maintenance.
• Most important first: rank merged/shipped PRs and user-visible fixes above investigations, chores, and routine follow-up.
• Classify by outcome, not by tool: Highlights, Merged PRs, Open / In Review, Investigations, Infrastructure / Cleanup, Risks / Blockers, Next Focus. Omit empty sections.

1. Write the report. Choose the format from the request:

• Markdown (default) — save as weekly-reports/Weekly-Report-…​.md.
• HTML deck — when the user asks for HTML / slides / a deck / visual / 图文并茂. Save as weekly-reports/Weekly-Report-…​.html. See HTML Deck Output.
• Create weekly-reports/ in the current workspace unless the user names another destination.
• Match the user's language (write in Chinese for Chinese requests, etc.).
• Include concrete PR links, repo names, and dates when available; keep bullets outcome-oriented (what changed, why it mattered, current status).

1. Hand it back. Print the file path. For the HTML deck, tell the user they can open it directly: open / xdg-open (or just double-click), or preview locally with python3 -m http.server in the folder. It is one self-contained file — no build, no server required.

Report Shape (Markdown)

# Weekly Report YYYY-MM-DD to YYYY-MM-DD

## Highlights
- ...
## Merged PRs
- ...
## Open / In Review
- ...
## Investigations
- ...
## Infrastructure / Cleanup
- ...
## Risks / Blockers
- ...
## Next Focus
- ...

HTML Deck Output

Produce a single self-contained .html file (inline CSS + JS; the only external reference is a Google-Fonts CDN link, which degrades gracefully to system fonts offline). No build step — it opens directly from disk.

Theme — pairs with the html-ppt skill. This skill owns the content; the html-ppt skill owns the design. Pick the design path:

• If the html-ppt skill is available (installed, or the user asks for a specific theme,

presenter mode, or a non-default look): use it. Invoke/read it, pick the theme the user wants from its 36 (tokyo-night, corporate-clean, swiss-grid, academic-paper, xiaohongshu-white, …) or start from its weekly-report full-deck template, and author the slides there. That unlocks its layouts, animations, presenter mode (speaker notes), and render-to-PNG export.

• Otherwise (default, zero-install): use the bundled assets/deck-template.html, which

ships a single fixed theme (tokyo-night). For a quick restyle without html-ppt, swap the :root design tokens (e.g. a light corporate palette) — never hand-edit literal colors per element.

Authoring the bundled template:

• Copy assets/deck-template.html to the .html destination, then replace only the slide content inside …. Keep the `, .deck-head, progress/overview chrome, and the ` runtime unchanged.
• The template's example content is fictional sample data — replace it wholesale with the real report.
• The template's top comment carries the slide-mapping recipe (Cover → KPIs → Highlights → Pipeline → Merged PRs → Open/Closed → Investigations → Risks → Next → Closing). Drop a slide whose section is empty; add the Pipeline slide only when one feature spans multiple repos.
• Map evidence to components: .kpi stat cards, .feat feature cards, .pipe/.stage/.arrow cross-repo pipeline, .pr rows with size bars (bar width = additions / max-additions * 100%), .badge for PR state, .blocker risks, .next-row next steps. Tags: t-feat/t-fix/t-infra/t-build/t-doc. Give each slide a data-title.
• Built-in keyboard runtime: ← →/Space navigate, O overview grid, F fullscreen, 1-9 jump, #/N deep-link, touch-swipe.
• To restyle, swap the :root design tokens (e.g. a light corporate palette) — never hand-edit literal colors per element.

Quality Bar

• Prefer verified PR metadata over inferred session intent.
• Separate completed work from ongoing work.
• Never include secrets, tokens, raw environment dumps, or long command output.
• Don't overstate impact. If the evidence only shows investigation or debugging, say that.
• If coverage is incomplete (e.g. gh not authenticated, an agent store is unavailable, or sessions are truncated), add a short Data Notes line.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: tang-t21
• Source: tang-t21/weekly-report
• License: MIT

Install and usage instructions live in the source repository linked above.