본문으로 건너뛰기
cccskills
무료GitHub에 공개

pm-weekly-update

Generate weekly or monthly status updates from local PM data. Use this skill when: - It's end of week and you need a status update for leadership or stakeholders - You need a monthly executive summary - You want to draft an email update using data from meetings, tracker tickets, and decisions - The user says "weekly update", "status report", "what happened this week?", "weekly summary" - The user says "Friday update", "send status email", "EOW update" Pulls from work logs, meetings, ticket tracker, and decisions — no manual input needed.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구Slack
설치 방법 보기

포함된 파일(1)

  • SKILL.md6.1 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

PM Weekly / Monthly Update Generator

Generate structured status updates by reading local PM data from .local/. No manual input needed — everything is pulled from synced data.

Prerequisites

Before generating an update, ensure data is fresh:

  1. Refresh ticket-tracker data (e.g., /pm-sync if available)
  2. Ensure meetings from the period are processed

If data looks stale (e.g., sprint file is from 3 days ago), warn the user and offer to sync first.

Weekly Update Workflow

Step 1: Gather Data

Read these files from .local/:

SourceFileWhat to Extract
Sprint progresstracker/sprints/<active-sprint>.mdPoints done vs total, issues moved
Meetingsmeetings/processed/*.md (this week only)Meeting count, key discussions
Action itemsmeetings/meeting-action-items.mdNew items this week, closed items
Decisionsdecisions/decision-log.mdDecisions made this week
Epicstracker/epics.mdEpic-level progress

Also cross-reference meetings for this week to ensure completeness (list meetings with a this_week time range, compare against processed files).

Also pull from the ticket-tracker API directly for most current data:

  • Tickets created this week: project = [PROJECT_KEY] AND created >= startOfWeek()
  • Tickets resolved this week: project = [PROJECT_KEY] AND resolved >= startOfWeek()
  • Tickets in progress: project = [PROJECT_KEY] AND status = "In Progress"

Step 2: Generate the Update

Write to .local/updates/weekly/YYYY-WNN.md:

# Weekly Update — Week N (Mon DD – Fri DD, Month YYYY)

> Project: [your project] ([PROJECT_KEY])
> Author: [your name]
> Generated: DD-MM-YYYY

## Sprint Progress: "<Sprint Name>"
- **Velocity**: X/Y story points completed (Z%)
- **Issues**: A done, B in progress, C to do (of D total)

### Completed This Week
| Key | Summary | Type | Points |
|-----|---------|------|--------|
| [PROJECT-XX] | ... | Story | 3 |

### In Progress
| Key | Summary | Assignee | Points |
|-----|---------|----------|--------|
| [PROJECT-XX] | ... | Name | 5 |

### Blocked / At Risk
| Key | Summary | Blocker |
|-----|---------|---------|
<!-- If any -->

## Key Decisions
| Decision | Context | Date |
|----------|---------|------|
| ... | From meeting X | Mon |

## Meetings This Week
- **Mon**: <Meeting title> — <1-line summary>
- **Tue**: <Meeting title> — <1-line summary>
- ...

## Action Items Status
- **New this week**: X items
- **Closed this week**: Y items
- **Still open**: Z items

## Risks & Blockers
<!-- From decisions log and meetings -->

## Next Week Focus
<!-- Infer from in-progress items and upcoming meetings -->

Step 3: Generate Shareable Formats

Also produce a short version for Slack/email at the bottom of the file:

---

## Slack / Email Version

**[your project] — Week N Update**

Sprint: X/Y pts done (Z%)
- <Top 3 things completed>
- <Top 3 things in progress>
- <Any blockers>

Decisions: <1-2 key decisions>
Next week: <Focus areas>

Step 4: Offer to Send

After generating, ask:

  • "Update saved. Want me to draft an email version for leadership?"
  • If yes, write a polished email to .local/mail/drafts/weekly-YYYY-WNN.md

Monthly Executive Summary Workflow

When the user asks for a monthly summary:

Step 1: Gather Monthly Data

  • Read all weekly updates from .local/updates/weekly/ for the month
  • Read all decisions from the month
  • Pull tracker data: tickets created/resolved in the month

Step 2: Generate Summary

Write to .local/updates/monthly/YYYY-MM.md:

# Monthly Executive Summary — <Month YYYY>

> Project: [your project] ([PROJECT_KEY])
> Author: [your name]

## Highlights
- <Top 3-5 achievements this month>

## Sprint Summary
| Sprint | Planned (pts) | Completed (pts) | Velocity |
|--------|--------------|-----------------|----------|
| Sprint N | X | Y | Z% |

## Key Metrics
- **Tickets created**: X
- **Tickets resolved**: Y
- **Story points delivered**: Z
- **Active epics**: N

## Major Decisions
| Decision | Date | Impact |
|----------|------|--------|
| ... | ... | ... |

## Risks & Mitigations
| Risk | Status | Mitigation |
|------|--------|------------|

## Next Month Focus
- <Planned epics/features>
- <Key milestones>

Important Rules

  1. Data-driven — every claim must be backed by a ticket, meeting note, or decision log entry
  2. No fluff — stakeholders want facts, not filler
  3. Highlight blockers — never hide problems. Surface them with proposed mitigations
  4. Keep it scannable — tables over paragraphs, bullets over prose
  5. Time-box data — only include data from the relevant period (week/month)
  6. Always offer the short version — stakeholders read chat more than docs

Anti-Patterns

  1. Fabricating numbers when data is missing — always cite source or mark "data unavailable"
  2. Rewriting the same narrative for both weekly and monthly — roll up, don't repeat
  3. Listing every ticket instead of aggregating — stakeholders want signal, not a changelog
  4. Hiding blockers to make the update look better — surfacing risks builds trust

Quality Checklist

  • Every metric has a source (ticket ID, meeting file, decision log)
  • Blockers and risks are explicitly called out
  • Short version (Slack/email) is present alongside the full update
  • Dates are formatted DD-MM-YYYY
  • Ticket IDs are hyperlinked to the tracker
  • Next-week focus is inferred from in-progress items, not invented

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Design statistically rigorous experiments to test data science hypotheses. Use when the user says "design an A/B test", "run an experiment", "test this hypothesis", "is this difference significant", "how many samples do I need", "randomized controlled trial", "causal inference", "uplift test", "holdout group", "significance test", "power calculation", "avoid p-hacking", or needs to determine whether an observed effect is real before making a product or model decision. For lean build-measure-learn product experiments without the statistics, use experiment-design instead.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

qa-aman의 스킬 모두 보기

이 스킬의 문제 신고