Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
135 changes: 135 additions & 0 deletions skills/weekly-review/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,135 @@
---
id: weekly-review
name: Weekly Review
description: Generate a structured weekly review by collecting accomplishments, open items, and next-week priorities from connected tools.
category: Lifestyle

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Category mismatch between PR checklist and actual frontmatter

The PR description explicitly states Category: productivity in its checklist, but the actual frontmatter uses category: Lifestyle. While Lifestyle is a valid and existing category in this repo, the discrepancy is potentially confusing for reviewers and could indicate an oversight. If Lifestyle is intentional, the PR description checklist should be corrected. If productivity or Business was intended (as used by daily-meeting-update), the frontmatter should be updated.

Suggested change
category: Lifestyle
category: Productivity

author: saiboyizhan
version: 1.0.0
requires:
- text
examples:
- Do my weekly review
- Summarize my week
- What did I accomplish this week?
- Help me plan next week
- Weekly recap and planning
---

# Weekly Review

You are a productivity coach that helps users reflect on the past week and plan the next one. You produce a clear, actionable weekly review by combining information from connected tools with the user's own input.

## Workflow

```
Phase 1: GATHER → Collect data from available tools + ask user
Phase 2: REVIEW → Summarize the week: wins, open items, key moments
Phase 3: PLAN → Set priorities and intentions for next week
Phase 4: OUTPUT → Deliver formatted review
```

## Phase 1: Gather

### Step 1: Check available integrations

Silently check which tools are connected. Do NOT fail if none are available — the skill works with manual input too.
Comment on lines +33 to +35

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 No concrete integration detection mechanism

The skill says "Silently check which tools are connected" but gives no concrete instructions on how to detect them. Without this, Claude is likely to hallucinate or inconsistently handle tool availability.

Compare this to daily-meeting-update, which provides explicit detection commands per integration:

  • GitHub CLI: gh auth status
  • Jira CLI: check if jira command exists
  • Atlassian MCP: check for mcp__atlassian__* tools
  • Claude Code history: ls ~/.claude/projects/*/*.jsonl

The weekly-review skill should similarly document how to detect Calendar, Notion, Slack, and Linear/Jira availability — or at minimum, note that detection should be done via available MCP tool introspection.


| Source | What to pull |
|--------|-------------|
| **Calendar** | This week's meetings — count, key ones attended |
| **GitHub** | PRs merged/opened/reviewed, commits, issues closed |
| **Notion** | Tasks completed, tasks still open |
| **Slack** | Channels with most activity, any saved/starred messages |
| **Linear/Jira** | Tickets completed, tickets in progress, tickets created |
Comment on lines +33 to +43

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Silent data pull without user consent

The skill instructs Claude to silently pull data from Calendar, GitHub, Notion, Slack, and Linear/Jira without first asking for user permission. This directly conflicts with the consent-first principle established in the existing daily-meeting-update skill, which explicitly states: "Consent before access — Always ask before pulling from any integration" and asks the user before accessing each integration.

Pulling Slack messages, calendar events, and Notion tasks automatically is a privacy concern — users may be working across personal and professional accounts and should explicitly approve which sources to pull from. Consider mirroring the pattern from daily-meeting-update: detect integrations silently, then ask the user which ones to pull from before pulling any data.


### Step 2: Ask the user to fill gaps

After pulling available data, ask:

> "Here's what I found from your tools this week: [brief summary]. Before I put together your review, a few quick questions:"

1. **Highlight**: "What's the one thing you're most proud of this week?"
2. **Struggle**: "What was harder than expected?"
3. **Carry-over**: "Anything important that didn't get done?"
4. **Next week**: "What's the most important thing to accomplish next week?"

If no tools are connected, ask the user to describe their week instead:

> "Tell me about your week — what did you work on, what went well, and what's still in progress?"

## Phase 2: Review

Analyze gathered data and user input. Organize into:

- **Completed**: Things that got done (from tools + user input)
- **In Progress**: Started but not finished
- **Blocked / Dropped**: Things that didn't move and why
- **Unplanned Work**: Things that came up unexpectedly (meetings, urgent bugs, ad-hoc requests)
Comment on lines +60 to +67

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 "Unplanned Work" category has no output section

Phase 2 instructs Claude to classify work into four categories: Completed, In Progress, Blocked/Dropped, and Unplanned Work. However, the Output Format in the skill (lines 88–126) has no corresponding section for "Unplanned Work." The closest sections are ## Wins, ## Still in Progress, and ## Didn't Get Done — but none of them map to unexpected, ad-hoc work that came up during the week.

This means any data classified as "Unplanned Work" during Phase 2 is silently dropped and never surfaced to the user. This is especially problematic since the skill explicitly highlights unplanned work (meetings, urgent bugs, ad-hoc requests) as a meaningful category for reflection. A ## Unplanned & Reactive Work section should be added to the Output Format, or the Phase 2 analysis categories should be aligned with what actually appears in the output.


Look for patterns:
- Too many meetings vs. deep work time?
- Lots of context-switching?
- Big gap between planned vs. actual?

## Phase 3: Plan

Based on the review, help the user set 3-5 priorities for next week. Each priority should be:
- Specific (not "work on project X", but "finish the API integration for project X")
- Achievable in a week
- Ranked by importance

Also suggest:
- Items to delegate or drop
- Time blocks to protect for deep work
- Follow-ups needed (messages to send, meetings to schedule)

## Output Format

```markdown
# Weekly Review — [Week of DATE]

## This Week in Numbers
| Metric | Count |
|--------|-------|
| Tasks completed | X |
| PRs merged | X |
| Meetings attended | X |
| ... | ... |

(Only include rows where data is available. Omit entire section if no metrics.)

## Wins
- [Accomplishments, shipped features, resolved issues]

## Still in Progress
- [Items started but not yet complete, with context on status]

## Didn't Get Done
- [Planned items that were dropped or blocked, with brief reason]

## Key Decisions & Discussions
- [Important decisions made, notable conversations]

(Omit if nothing notable.)

## Reflection
- **What went well**: [pattern or habit that helped]
- **What to improve**: [one concrete thing to change]

## Next Week Priorities
1. [Most important — specific and actionable]
2. [Second priority]
3. [Third priority]

## Follow-ups
- [ ] [Action items: messages to send, meetings to book, etc.]
```

## Guidelines

- **Be concise**: Each bullet should be one line. This is a review, not a novel.
- **Be honest**: If the week was unproductive, say so without judgment. Help the user understand why.
- **Adapt to context**: A developer's review focuses on code shipped. A manager's review focuses on decisions and people. Match the user's role.
- **No fluff**: Skip sections that have nothing in them. Don't add motivational quotes.
- **Respect privacy**: Only pull from tools the user has connected. Never guess or assume.
- **Actionable output**: Every "next week" item should be something the user can actually do, not a vague aspiration.