status-report
The status-report skill generates concise weekly, monthly, or quarterly progress summaries optimized for rapid consumption by managers and stakeholders. It structures outputs into shipped items, in-flight work with ETAs, blockers requiring action, optional metrics, and prioritized next steps, using plain language and outcome-focused bullets rather than activity descriptions. Use this skill when users request status updates, project summaries, or progress reports at any cadence from daily standups to quarterly reviews.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/status-report && cp -r /tmp/status-report/skills/status-report ~/.claude/skills/status-reportSKILL.md
# Status Report
## When to Use
Trigger phrases: "weekly update", "monthly report", "status report", "project update", "1:1 prep", "周报", "月报", "工作汇报".
Match the cadence implied by the request:
- **Daily / standup**: 3 bullets max, "yesterday / today / blockers"
- **Weekly**: full template below
- **Monthly**: weekly template + "themes" section + metrics over time
- **Quarterly / OKR**: include progress against named goals + risk assessment
This skill optimizes for **the reader's time, not yours**. A status report is read in 60 seconds or skipped.
## The Weekly Template
```markdown
# <Your Name / Team Name> — Week of <YYYY-MM-DD>
## TL;DR
<2 sentences. What's the state of the world? Use plain English.>
## ✅ Shipped This Week
- <bullet — outcome, not activity. Link if relevant.>
- <bullet — outcome.>
## 🔄 In Flight
- <project> — <what stage, expected ship date>
- <project> — <what stage, expected ship date>
## ⚠️ Risks / Blockers
- <risk> — <impact + what's needed to unblock>
## 📊 Metrics (optional)
| Metric | This Week | Last Week | Δ |
|--------|-----------|-----------|---|
| <name> | <value> | <value> | <±> |
## 📅 Next Week
- <top 3 priorities, in order>
```
## Workflow
1. **Gather inputs** via `recall_memory` (if scope=session/project) and `ask_user_question`:
- Date range covered (default: last 7 days)
- Audience (manager? cross-functional? company all-hands?) — affects depth and jargon
- Key projects to cover
- Whether metrics are required and what the baseline is
2. **Categorize ruthlessly** — every bullet must fit exactly one bucket:
- **Shipped** = merged / launched / delivered / decided. Past tense.
- **In Flight** = work in progress, not yet shipped. Has an ETA.
- **Risks/Blockers** = something that will hurt the plan if not addressed. Has a specific owner ask.
3. **Write outcomes, not activity**:
- Bad: "Worked on auth migration. Had 3 design meetings."
- Good: "Auth migration: design approved, infra ready. Cutover scheduled for May 5 (low risk)."
4. **Quantify when possible**:
- "Shipped feature X" → "Shipped feature X (5% adoption in week 1, target was 3%)"
- "Faster builds" → "CI builds dropped from 12m → 7m (median)"
5. **Sequence priorities by impact** — the first item in "Next Week" should be the highest-leverage thing. Don't bury it.
6. **Save state** — offer to save the report to memory or to compose an email via `email-draft`:
```
Save this status to memory for next week's diff?
Send to <manager> as an email?
```
## Style Rules
- **TL;DR is mandatory** — readers should know whether to read further in 5 seconds
- **Bullets, not paragraphs** — long sentences are a sign of unclear thinking
- **One bullet = one item** — don't smuggle 3 things into "and also"
- **Past tense for shipped, present for in flight, conditional for risks**
- **Drop hedge words** — "I think we kind of made progress on …" → "We shipped …" or "We're 70% done with …"
- **No vanity metrics** — if it's going up regardless of your effort, it's not your metric
- **Acknowledge what didn't ship** — silence on planned-but-undelivered items damages trust more than honesty
## Cadence-Specific Adjustments
### Daily / Standup (≤3 bullets)
```markdown
- Yesterday: <one outcome>
- Today: <one focus>
- Blockers: <none / specific ask>
```
### Monthly (add to weekly template)
```markdown
## 🎯 Themes
- <pattern across the 4 weeks: what got better, what's recurring>
## 📈 Trends
| Metric | Month-over-Month | Notes |
|--------|------------------|-------|
| ... | ... | ... |
## 🔭 Looking Ahead (next month)
- <strategic priorities, not tactical tasks>
```
### Quarterly / OKR (replace template)
```markdown
# Q<N> Review — <Team>
## Goals Status
| OKR | Target | Actual | Status | Confidence |
|-----|--------|--------|--------|------------|
| <name> | <metric> | <metric> | <On Track / At Risk / Off Track> | <0.0–1.0> |
## What Went Well
- <pattern, not single incident>
## What Didn't
- <honest pattern, with the lesson>
## Q<N+1> Bets
- <top 3 priorities for next quarter, with rationale>
```
## Audience-Specific Adjustments
| Audience | Adjust |
|----------|--------|
| Direct manager | Include risks honestly; manager wants to help unblock |
| Cross-functional team | More context; less internal jargon |
| Company all-hands | Outcomes only; cut planning details |
| Skip-level / exec | TL;DR + 3 bullets total; skip metrics unless they're 1-2 headline numbers |
| External (board, investors) | Headline outcomes + roadmap; never blockers without solutions |
## Common Pitfalls
| Mistake | Fix |
|---|---|
| Listing every Jira ticket | Group into ≤5 outcomes, name them |
| "Working on …" everywhere | Pick a stage: design / implementation / review / shipped |
| Burying bad news | Lead with "TL;DR: <project> slipping by 1 week, here's why" |
| Vague metrics ("better", "faster") | Specific numbers or skip the metric |
| Same priorities every week | Either reframe progress or admit it's stuck |
| No "next week" section | Always have one — shows you're proactive, not just reactive |
| Word-soup TL;DR | Two sentences max. If you can't compress, you don't understand the state. |
## Example
Input: "Write my weekly update — I shipped the auth refactor PR, I'm finishing the dashboard search feature, the embedding migration is blocked on infra, and I want to start the i18n rewrite next week."
Output:
```markdown
# Alice — Week of 2026-04-25
## TL;DR
Shipped auth refactor; dashboard search done by Friday. Embedding migration blocked on infra capacity (need decision by Tuesday).
## ✅ Shipped This Week
- Auth refactor PR merged (#1234) — removes legacy session middleware, paves way for OAuth migration.
## 🔄 In Flight
- Dashboard search — backend + UI complete, integration tests pending. Ship target: Friday.
## ⚠️ Risks / Blockers
- Embedding migration — blocked waiting on infra team's capacity decision. **Need by Tuesday** or May ship date slips.
## 📅 Nex>
Use when the user asks to draft, polish, translate, or reply to an email. Produces a clean draft with subject line, greeting, body, and sign-off, plus a pre-send self-check.
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘) upload/download, wiki (知识库) link resolution, approval (审批) instance create/cancel/query, calendar (日历) event create/list/update + attendees, contact (联系人) user/department lookup, hire (招聘) job/talent/application listing. Trigger on phrases like 'OKR 周报', '把这份文档发到飞书云盘', '给团队拉个评审会议', '查 [姓名] 的联系方式', '撤销那条审批', '/wiki 链接', or any request that mentions a feishu / lark URL / token (doxcn.../bascn.../wikcn.../boxcn.../om_...).
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha / camera-prompt / dialog blocks progress. Load this skill whenever you reach for the `browser` tool. Trigger on: user asks the agent to open / control / click / scrape / log into / verify something in a web app ('open X and click Y', '打开 X 然后点击 Y', 'log into my Gmail', 'scrape this page', 'fill out the form on X'); user reports a flow that requires real browser context (cookies, JS-rendered content, OAuth).
Hope-native review of uncommitted, staged, commit, branch, or PR changes: discover concrete regressions, independently verify candidates, and report actionable findings first without speculative noise.
Hope-native baseline for implementing, fixing, refactoring, and maintaining code: inspect the repository first, protect user changes, keep scope narrow, and finish with direct evidence.
Hope-native implementation planning for non-trivial code changes: ground the plan in repository evidence, order dependencies, name critical files and risks, define verification, then continue execution when allowed.
Hope-native local-first data analysis and Artifact reporting. Use for CSV/XLSX analysis, KPI readouts, metric diagnosis, product/business analysis, data-quality review, dashboards, charts, analytical reports, 数据分析, 指标诊断, 数据质量, 分析报告, or when the user wants a shareable offline HTML/ZIP/Markdown/PDF result. Produces the versioned AnalysisArtifactV1 contract and registers it with the artifact tool; never guesses missing data or requires public web deployment.