From workflow-skills
Drafts structured weekly software development reports from git logs, Obsidian work logs, YAML schedules, GitHub PRs, 云效 tasks, and calendars. Use for 周报 or end-of-week summaries.
npx claudepluginhub niracler/skill --plugin workflow-skillsThis skill uses the workspace's default tool permissions.
软件研发周报生成助手。自动扫描 `~/code/` 下所有项目的 schedule YAML 和 git log,
Conducts structured weekly retrospectives: scans git repos for commits, checks GitHub issues/projects, interviews user on business topics, creates verified issues, updates canonical files.
Generates async daily standup notes from Git commits, Jira tickets, Obsidian vault, and calendar events for remote team coordination.
Generates async standup notes from Git commit history, Jira tickets, Obsidian vaults, and calendars for remote team coordination and visibility.
Share bugs, ideas, or general feedback.
软件研发周报生成助手。自动扫描 ~/code/ 下所有项目的 schedule YAML 和 git log,
结合前几周周报做对比,生成结构化的三段式周报,写入 Obsidian 日记。
| Tool | Type | Required | Install |
|---|---|---|---|
| git | cli | Yes | brew install git |
| reminders-cli | cli | Yes | brew install keith/formulae/reminders-cli |
| macOS Calendar | system | Yes | Built-in, access via osascript |
| gh | cli | No | brew install gh then gh auth login — for GitHub PR/Issue data |
| yunxiao | skill | No | For 云效 MR/Task/Bug data (invoke via Skill tool) |
| Path | Purpose | Required |
|---|---|---|
~/code/*/ | Monorepo workspaces (git repos + schedule YAMLs) | Yes |
~/code/*/planning/schedules/*.yaml | Project schedule definitions | No (skip projects without schedule) |
~/code/*/repos/*/ | Sub-repos within each monorepo workspace | No (scanned automatically if present) |
| Obsidian daily notes directory | Daily diary files with Work Log entries + report output | Yes |
The Obsidian vault path is auto-detected by scanning ~/Library/Mobile Documents/iCloud~md~obsidian/.
If not found, ask the user.
Do NOT proactively verify tools or paths on skill load. If a command fails due to a missing tool, skip that data source and continue with what's available.
┌──────────────────────────────────────────────────────────────────┐
│ weekly-report 完整流程(~20min) │
└──────────────────────────────────────────────────────────────────┘
┌──────────────┐
│ 用户触发周报 │
└──────┬───────┘
│
▼
┌────────────────────────────────────┐
│ 1. 确认周期 + 定位文件 (~1min) │
└──────┬─────────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ 2. 查找前几周周报 (~1min) │
│ 提取上周「下周工作计划」 │
└──────┬─────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ 3. 并行数据收集(subagent) (~3-5min) │
│ ┌─ 本周日记 Work Log(各工作日) │
│ ├─ Schedule YAML(本周 + 下周模块) │
│ ├─ Git log(~/code/*/ 全扫描) │
│ ├─ GitHub PR/Issue(gh CLI) │
│ └─ 云效 MR/Task/Bug(yunxiao skill) │
└──────┬──────────────────────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ 4. 交叉比对 + 生成草稿 (~3min) │
│ 上周计划 vs 本周实际 │
└──────┬─────────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ 5. 用户审阅 + 修改 (~5min) │
│ 展示草稿 → 用户调整 → 写入日记 │
└──────┬─────────────────────────────┘
│
▼
┌────────────────────────────────────┐
│ 6. 创建下周日程 + 提醒 (~3min) │
│ Calendar time block │
│ Reminders 任务列表 │
└──────┬─────────────────────────────┘
│
▼
┌──────┐
│ 完成 │
└──────┘
## 2 Work Log, as ### 软件研发周报(M/D - M/D)~/Library/Mobile Documents/iCloud~md~obsidian/
or ask the user if not foundIf today is Saturday/Sunday, default to the previous Friday's daily note. Confirm with the user before proceeding.
Scan recent daily notes (previous 14 days) for the heading pattern ### 软件研发周报.
From the most recent previous report, extract:
If no previous report found, skip comparison and proceed — this is normal for the first report.
Launch subagents concurrently. The five data sources are independent — run as many in parallel as possible. If any source fails or is unavailable, skip it and continue.
Read the daily notes for each workday in the report period (Monday through Friday).
Extract content under ## 2 Work Log from each day's note.
This is the richest data source — daily work logs often contain context, decisions, and details that git commits and PR titles don't capture. Prioritize this content when writing the report.
Scan ~/code/*/planning/schedules/*.yaml — same directory structure as code-sync
(~/code/*/ monorepo workspaces).
For each YAML found:
project, title, timeline.start, phases, modulesceil((today - timeline.start) / 7)weeks includes current week → this week's workweeks includes next week → next week's planstatus: done modules in current phase → progress fraction (e.g., 4/6)Scan ~/code/*/ and ~/code/*/repos/*/ for git repos (same candidates as code-sync's
scan.sh pattern), then for each:
git log --oneline --since="{monday}" --until="{saturday}" --author="{user}" --all
Where {user} is from git config user.name.
Group commits by workspace → repo. This supplements the daily notes — useful for catching work the user forgot to log in their diary.
gh available)# PRs authored this week
gh search prs --author=@me --created="{monday}..{saturday}" --json repository,title,number,state,url
# Issues authored/assigned this week
gh search issues --author=@me --created="{monday}..{saturday}" --json repository,title,number,state,url
Include merged PRs, open PRs, and closed issues in the report. PR numbers and titles provide concrete references for the boss.
Spawn a subagent to invoke yunxiao skill via Skill tool:
Agent tool:
- subagent_type: general-purpose
- prompt: |
Invoke the yunxiao skill to query work activity from {monday} to {friday}.
Get: MRs authored (merged + open), Tasks assigned (modified this week),
Bugs assigned (modified this week).
Return: list of items with identifier, title, status, and dates.
MR numbers (e.g., MR#67) and task identifiers (e.g., YWQO-4) add traceability to the report.
When the same work appears in multiple sources, merge intelligently:
| Priority | Source | Strength |
|---|---|---|
| 1 | Daily notes | Most context, user's own words, decisions and reasoning |
| 2 | Schedule YAML | Structured progress, phase tracking, module status |
| 3 | GitHub / 云效 | Concrete references (PR#, MR#, issue#, task ID) |
| 4 | Git log | Catch unreported work, verify claims |
The daily notes provide the narrative; schedule YAML provides structure; GitHub/云效 provide traceability; git log fills gaps.
| Source unavailable | Behavior |
|---|---|
| Daily notes missing for some days | Use available days, note gaps |
| No schedule YAML for a project | Include project based on git/daily notes alone, omit progress fraction |
gh not installed or auth failed | Skip GitHub data, note "GitHub 数据未获取" |
| yunxiao skill unavailable | Skip 云效 data, note "云效数据未获取" |
| Git log returns nothing | Project may have had non-code work (meetings, design) — check daily notes |
| All remote sources fail | Proceed with daily notes + git log only |
Compare last week's 「下周工作计划」 against this week's actual output:
| Last week planned | This week status | How to handle |
|---|---|---|
| Completed | Done | Include in 本周总结 |
| Partially done | In progress | Note progress in 本周总结, carry forward to 下周计划 |
| Not started | Missed | Flag in 其他事项 with reason if known |
| Unplanned work done | New | Add to 本周总结 as new item |
Do not hardcode groups. Instead, derive grouping from:
title field: use as display name~/code/<workspace>/ that share a
schedule can be grouped togetherOmit projects with zero activity this week.
Generate three sections following report-template.md.
本周工作总结:
进度 4/6) when available**bold key phrase**: + business-language description下周工作计划:
(2.5 天))**bold key phrase**: + expected outcome in business terms其他事项:
## 2 Work LogAfter the report is written, parse the 「下周工作计划」 section and create Calendar events and Reminders for next week. This closes the loop — what you wrote in the plan becomes actionable items on your schedule.
From each bullet in 下周工作计划, extract:
(N 天) is specifiedFirst check available lists with reminders show-lists, then create items in an
appropriate list (prefer "提醒" or the first available work-related list):
reminders add "提醒" "{project}: {task name}" --due-date "next monday"
If a task has a specific day mentioned (e.g., "周三前完成"), use that date instead.
If time estimates are available per project, suggest Calendar time blocks. Calculate actual next-week dates (not relative offsets) to ensure accuracy:
# Example: create a time block for next Monday (2026-03-16) 9:00-17:00
osascript -e '
tell application "Calendar"
tell calendar "工作"
set startDate to date "2026年3月16日 09:00:00"
set endDate to date "2026年3月16日 17:00:00"
make new event with properties {summary:"sylsmart: auth 接口适配", start date:startDate, end date:endDate}
end tell
end tell'
osascript -e 'tell application "Calendar" to get name of calendars')提醒Use current date with day offsets to calculate next week's dates. Do not use
hardcoded date strings — they cause locale-dependent parse errors on macOS.
set baseDate to current date
set time of baseDate to 0
set nextMon to baseDate + ({offset} * days)
set startTime to nextMon + (9 * hours) + (30 * minutes)
set endTime to nextMon + (11 * hours) + (45 * minutes)
Present the proposed schedule to the user first — only create after confirmation:
下周日程建议(Work 日历,9:30-11:45):
周一 3/23: sylsmart - xxx(1 天)
周二-周三 3/24-3/25: sunlite - xxx(2 天)
周四 3/26: HA 集成 - xxx(1 天)
周五 3/27: buffer / 周报
确认创建到 Calendar 和 Reminders 吗?
Do not remove items the user didn't mention. During review, the user will only call out things that need changing. Silence means approval. This is a lesson learned from real usage: removing "good" items to make room for user corrections breaks the report.
Business language, not technical jargon. The boss does NOT read code. Write what was done and what it enables, using domain terms (接口、页面、配置参数、用户可以...). Never use: implementation details (Router Factory, Playwright E2E, migration downgrade), internal process names (CLAUDE.md, openspec review schema), version bumps (v0.2.0→v0.2.1), commit/PR counts, or CI/CD details. These are valuable data for collection but must be translated to business outcomes in the final report.
Concrete with business numbers. Use domain-relevant numbers: 14 个接口, 17 个页面, 4 个配置参数, 18 个待确认问题. NOT: 13 commits, PR#78, 91% coverage.
Match previous report style. If a previous report exists, mirror its voice, detail level, and formatting choices. The goal is consistency across weeks so the boss sees a coherent narrative, not a different writing style each time.
| Issue | Fix |
|---|---|
| No daily notes found | Verify Obsidian vault path, check iCloud sync status |
| Schedule YAML parse error | Validate YAML syntax, check timeline.start date format |
| Previous report not found | Normal for first week — skip accountability check |
gh search returns 0 results | Check date range format, verify gh auth status |
| Calendar "工作" not found | Run osascript -e 'tell application "Calendar" to get name of calendars' to list available calendars, use an existing one |
| Reminders list not found | Run reminders show-lists and use an available list |
| Git log shows upstream commits | Filter by --author to exclude upstream noise |