weekly-summary

name	weekly-summary
description	Generate a curated weekly summary of completed and in-flight work

Weekly Summary

A bulleted, concise summary of work completed since the last summary and work actually in flight or queued for this week's meetings. Output is saved to wiki/weekly/<period-end>.md and shown in conversation.

When to invoke

Trigger on any of:

• /weekly-summary
• "write a weekly summary"
• "weekly update"

Period

"Last summary to this summary" — not the calendar week. Look in wiki/weekly/ for the most recent file; the period starts the day after that file's period_end. If no prior summary exists, default to the last seven days.

Structure

Two top-level sections, each split into Theme and Admin:

1. Completed & In Review since last summary
2. In Progress and Upcoming

• Theme = tasks with an external backend reference (jira_ref, asana_ref, gh_ref, or any ref matching a configured backend's ref_pattern). These are the engineering / tracker-visible items.
• Admin = wiki-only tasks (source: internal, or no backend ref). These are vendor evals, internal investigations, process changes, infra/config work — anything the user owns but isn't tracked externally.

The Theme/Admin split is derived from existing frontmatter — no configuration. A workspace with no backends connected will have an empty Theme section, which is fine.

"In Review" surfaces with Completed, not Upcoming

Tasks with status: in-review (PR open, merged-but-not-released, awaiting deploy) are real progress and belong under Completed & In Review — never buried under In Progress. They're the work most likely to ship next and the user needs them visible alongside shipped work for weekly meetings.

An in-review task appears once, under ### Theme — In Review (or ### Admin — In Review if it has no backend ref). Do NOT duplicate it under In Progress and Upcoming.

Subsection headings

Always include the parent context in subsection headings — it's easy to lose track when scrolling. Use:

Under Completed & In Review since last summary:

• ### Theme — Completed
• ### Theme — In Review (omit if no items)
• ### Admin — Completed
• ### Admin — In Review (omit if no items)

Under In Progress and Upcoming:

• ### Theme — In Progress and Upcoming
• ### Admin — In Progress and Upcoming

Never use bare ### Theme or ### Admin headings.

Curation rules — important

The "In Progress and Upcoming" section is the one most likely to bloat. Do not dump the full backlog. Aim for ~6–10 Theme items and ~8–12 Admin items total. If you're at 15+ in either, you're listing too much.

Include:

• in-progress and in-review items
• blocked items if they're being actively escalated
• High-priority items the user has named in the last few dailies (carry-forwards, "tomorrow's first move")
• Items with due: dates inside the next ~2 weeks
• Items the user is mid-flow on
• Vendor evals with active follow-ups
• Self-authored tickets recently filed that need next-step decisions

Exclude:

• Long-running backlog items with no movement since the last summary
• to-do items just sitting in the backlog
• Parked / waiting-on-external items where no user action is expected
• Items owned by someone else with no user touchpoint
• Items already completed this period (those go in Completed, not Upcoming)
• For Asana-backed workspaces: items still in the intake board's "new submission" column. These are raw intakes that haven't been groomed yet — they don't belong on a weekly meeting list. See Backend ordering below for how to detect this.

When in doubt, leave it out. The user can ask "what about X?" if they want it surfaced — they can't easily un-see a 30-item list.

Bullet descriptions — substantive, not noisy

The wikilink carries the title. The section heading carries the status bucket. The description's job is to tell a meeting reader why this matters and where it stands — enough to discuss without opening the task page.

A good description answers two questions in one short clause:

1. Why this matters / what's driving it — business stake, requester, deadline, legal/compliance driver, hot-issue framing
2. Where it stands / what's the next move — owner, PR link, what it's pending on, blocker reason

Good examples:

• [[]] — Vendor legal directive; PR awaiting review
• [[]] — Customer-reported regression; teammate's PR awaiting review
• [[]] — Father's Day promo build; due 2026-05-22

Do NOT pack in:

• PR diff stats — belongs on the task page, not the summary
• Downstream roadmap / next-step plans
• Architecture or implementation notes
• Walls of commas/semicolons — if you need three clauses, you're listing too much

Don't over-prune either. A bullet that says only "" or only "due 5/22" tells a meeting reader nothing they couldn't get from glancing at the title. Aim for one short clause that earns its keep.

Intakes — summarize, don't enumerate

New intakes ingested during the period are a count + brief headline, not a wikilink dump. Write one Admin bullet like:

8 new intakes ingested (incl. , )

Pick 2–3 noteworthy ones to name inline (highest-impact, linked-to-existing ticket, or hot-issue). Skip the wikilinks — they bloat the page into a wall of purple text. Individual intakes that warrant their own bullet (immediately closed, deadline this week) get a normal bullet in Completed/Upcoming — not double-counted in the intake summary.

Backend ordering signal

Several backends expose ticket order on a board / sprint / project, and that order is often the user's real prioritization signal — higher in column = higher priority. The MCPs / APIs don't always expose this ordering.

Before curating the "In Progress and Upcoming" section, check the workspace's configured backends:

rubber-ducky backend list --json

For each backend whose ordering the MCP / API doesn't expose, ask the user for screenshots once at the start of curation:

Before I curate the "In Progress and Upcoming" list, can you drop a screenshot of your board's into raw/assets/? The MCP doesn't expose the manual rank order, and that's how you actually prioritize. I'll wait — no draft output yet so the response doesn't become a wall of half-done summary while you're grabbing it.

Backend-specific notes:

• Asana — manual within-column rank is not exposed by the MCP. Ask for the Backlog and In Progress columns at minimum; Pending/Review if a lot is in flight.
• Jira — sprint-rank and backlog order are exposed via the API, so screenshots are generally not needed.
• GitHub — issue order on Projects (v2) is exposed; skip the screenshot ask unless the user uses non-Projects ordering.

If no backends are configured, skip this step entirely.

Procedure

Step 1 — Find the period

ls -1 wiki/weekly/*.md 2>/dev/null | sort | tail -1

Read its period_end frontmatter. The new period_start is the day after. If no prior file, period_start is today minus 7 days. period_end is today.

Step 2 — Read the source material

Read in parallel:

• Every daily page in wiki/daily/ between period_start and period_end
• current-status.md if it exists (an EOD snapshot — common but optional)
• The most recent prior wiki/weekly/*.md for tone calibration

Step 3 — Backend screenshots (if applicable)

Run the Backend ordering signal step above. If screenshots are needed, stop and ask for them — do not preview any partial summary in this turn. Once screenshots are in raw/assets/, read each one, infer rank order and column membership, and use that when curating Step 5.

Step 4 — Build "Completed & In Review"

Scan the dailies in the period for ## Completed today entries and any "shipped" or "closed" annotations. Separate into Theme (has backend ref) vs Admin (no backend ref).

Note releases explicitly — each release gets a parent bullet under Completed and lists shipped tickets as sub-bullets.

For "In Review", scan wiki/tasks/ for status: in-review regardless of whether it appeared in a daily — these are the tickets most likely to ship in the next period.

Step 5 — Build "In Progress and Upcoming"

Apply the Curation rules above. Walk yesterday and today's daily for carry-forwards and "tomorrow's first move" lists; those are the load-bearing signal alongside any backend ordering from Step 3. Cross-reference current-status.md for status, but do not transcribe the full Active Tasks table — that's the backlog dump trap.

Skip items in any "new submission" column when the screenshots indicate them, per the Curation rules.

Step 6 — Write each bullet

Per the Bullet descriptions section — substantive (why this matters + where it stands), not noisy (no diff stats, no roadmap, no implementation notes), and not over-pruned (a bare owner name is too thin).

Step 7 — Save to wiki/weekly/<period-end>.md

rubber-ducky page create weekly --period-start <period-start> --period-end <period-end>

This scaffolds the file with frontmatter and section skeleton; write the content into the resulting file (Read + Edit). The CLI defaults period_end to today and period_start to seven days before, but pass them explicitly so the period reflects the actual prior-summary window.

Step 8 — Update the wiki index and log

rubber-ducky index rebuild
rubber-ducky log append "[weekly-summary] <period-start> → <period-end>. Theme: <N> completed, <M> upcoming. Admin: <N> completed, <M> upcoming."

Step 9 — Show the summary in conversation

Render it in chat, but keep section formatting tight — the file is the canonical record; the chat output is a read-back so the user can review.

Rules

• The split is derived, not configured. Theme/Admin comes from source / backend-ref frontmatter — never ask the user "is this Theme or Admin?".
• Backend screenshots are asked for once, at the start of curation. Don't preview any partial summary in the screenshot-request turn — the user explicitly doesn't want a wall of half-done text while grabbing files.
• "In Review" never duplicates into "In Progress and Upcoming". Pick one bucket per task.
• No backlog dumping. ~6–10 Theme + ~8–12 Admin in "In Progress and Upcoming". 15+ in either is too much.
• Wikilinks for tasks, plain counts for intakes. The intake summary is the only place wikilinks are skipped on purpose.
• No external writes. The summary is wiki-only. Releases / closings belong to /release and /close.

Output

A complete weekly summary file saved to wiki/weekly/<period-end>.md and rendered in conversation. No interruptions mid-stream; if the screenshot question is asked, the full summary follows only after the response.