Update-Kit

A reusable skill for drafting any recurring update — weekly status reports, biweekly OKR check-ins, sprint recaps, monthly research summaries, quarterly leadership briefings, daily standups, anything cyclical. The format is fully defined by the user's config file. This skill makes no assumptions about sections, status conventions, cadence, or sources.

When to use this skill

Use any time someone asks to:

• Draft a recurring update (weekly, biweekly, monthly, quarterly, or other cadence)
• Summarize the last cycle's activity into a standard report format
• Refresh a status update, sprint recap, leadership briefing, research roundup, etc.
• "Run update-kit" or similar phrasing

If the user does not yet have a config, walk them through setup (see Step 0 below) and offer to save the result as a YAML file for next time.

Core principle: follow the user's config, don't impose structure

This skill is declarative-driven. The user's YOUR-CONFIG.yaml (or whatever they've named it) is the source of truth for:

• Section names and order
• Whether each section iterates over a list (e.g. one block per workstream) or is a flat narrative
• Whether status indicators are used at all, and if so what the convention is (R/Y/G, A/B/C, numeric, custom labels)
• Which sources to pull from (or whether to rely only on pasted content)
• Tone, voice, length, and output format

Do NOT add sections, statuses, or formatting the config does not specify. Do NOT impose an OKR/KR framing, a R/Y/G convention, or any other format unless the config asks for it.

Step-by-step

Step 0 — Locate or create the config

Look for a YAML config file in (in priority order):

1. Attached files in the current message
2. The user's working folder
3. Their Claude Project knowledge

Common filenames: YOUR-CONFIG.yaml, update-config.yaml, <team-name>-config.yaml. The user may have named it anything.

If no config is found, run the first-time setup below using the AskUserQuestion tool, then offer to save the result as a YAML file.

Step 1 — Pull source material

Use whatever sources the config enables. For each enabled source, pull material covering the configured cycle window (e.g. last 7 days for weekly, last 14 for biweekly, last 30 for monthly).

If the user has connectors configured but didn't attach explicit material, offer to pull from those sources rather than asking them to paste.

Step 2 — Map source material into the config's sections

For each section the config defines:

• If the section is a flat list or narrative, gather the relevant bullets/points and draft directly.
• If the section iterates over a list of items (e.g. one block per workstream, project, person, KR, customer), draft one block per item, in the order the config specifies. If an item has no new activity, follow the config's if_no_update rule (typically: write "No change since last cycle" rather than omitting the item).

If a piece of source material doesn't map cleanly to any section, set it aside and ask the user where it belongs rather than guessing.

Step 3 — Apply the config's status convention (if any)

• If the config defines a status convention, apply it. The convention's values list determines what's allowed.
• If the config has status_convention.enabled: false or no status convention at all, do not introduce status indicators on your own initiative.

Step 4 — Honor sensitivities and placeholders

The config's sensitivities list flags topics that need softer language or placeholders (e.g. unannounced changes, pending approvals, personnel matters in flight). For each sensitive topic:

• Use *[Placeholder: …]* language the user can swap before finalizing
• Don't commit to specifics (dates, names, dollar amounts) you can't trace to a source the user provided

Step 5 — Honor tone and length

Follow the tone and length directives in the config. If the config says "factual and short," skip filler adjectives. If it says "warm and narrative," allow more prose. If a voice or style notes field is provided, follow it literally.

Step 6 — Produce the deliverable in the configured format

The output.format field determines what to produce:

• chat (most common): render the draft directly in the chat thread as markdown
• markdown_file: write a .md file to the user's selected folder
• docx: use the docx skill to produce a Word doc
• email_draft: format as plain text suitable for pasting into an email client

After rendering, offer (without doing automatically):

• A different output format if the user might prefer one
• Appending to the live destination doc (Notion page, Google Doc, Confluence, etc.) if the relevant connector is available and the config specifies a destination

First-time setup (if no config is found)

Use AskUserQuestion (in Cowork) or numbered questions (elsewhere) to gather:

1. Name and audience — what's this update called? Who reads it?
2. Cadence — daily / weekly / biweekly / monthly / quarterly / other
3. Sections — what sections does the update have, in order? For each: a name, a short description, and whether it iterates over a list (and if so, what list — e.g. workstreams, projects, KRs, people)
4. Status convention — do you use a status indicator on items? (R/Y/G, A/B/C, On Track / Off Track, percentage complete, custom labels, or none)
5. Sources — where does the source material live? (Notion / Slack / Drive / Gmail / pasted / metrics dashboard / etc.) Specific URLs, channels, queries.
6. Standing context — code names, ongoing initiatives, anything you don't want to re-explain each cycle
7. Sensitivities — topics needing placeholder language
8. Output format — chat / markdown file / docx / email
9. Prior update location — where does the last cycle's output live, so we can avoid repeating it?

Offer to save the answers as a YAML file in the user's folder, named something the user picks (suggest YOUR-CONFIG.yaml or <update-name>-config.yaml).

What to flag back to the user before finalizing

• Any section where the source material was thin (so you had to extrapolate)
• Any data point you couldn't trace to a source
• Any sensitive item that may need softening
• Any item the config expects but you couldn't find content for

What this skill explicitly avoids

• Inventing metrics, numbers, dates, or people. If you don't have a source, flag the gap.
• Auto-sending. Always produce a draft for the user to review.
• Imposing a structure the config doesn't define. The config is the contract.

Keywords

update, status report, weekly update, biweekly update, monthly update, quarterly update, sprint recap, standup, briefing, summary, recurring report, status indicators, R/Y/G, RAG, configurable, declarative, team update