feat(writing): add biweekly-collector skill

.claude-plugin/marketplace.json

@@ -45,7 +45,8 @@
         "./diary-assistant",
         "./diary-note",
         "./note-to-blog",
-        "./writing-assistant"
+        "./writing-assistant",
+        "./biweekly-collector"
       ]
     },
     {

CHANGELOG.md

@@ -5,6 +5,12 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/),
 and this project adheres to [Semantic Versioning](https://semver.org/).
 
+## [Unreleased]
+
+### Added
+
+- **biweekly-collector** — New writing skill that collects raw materials from 8 data sources (daily notes, Pinboard, Douban RSS, Telegram RSS, Apple Calendar, Apple Reminders, rss-agent digests, plrom git diff) for personal biweekly diary writing. Includes strict date filtering for Telegram RSS and graceful degradation when sources are unavailable.
+
 ## [0.2.1] - 2026-03-16
 
 ### Fixed

README.md

@@ -21,10 +21,10 @@ claude plugin marketplace add https://github.com/niracler/skill.git
 │  $ skill architecture                                    │
 │                                                          │
 │  External Dependencies:                                  │
-│    CLI: git(6) · gh(3) · curl(1) · reminders-cli(2)     │
-│         jq(2) · markdownlint-cli2(2) · osascript(2)     │
-│         aliyun-cli(1) · pre-commit(1)                    │
-│    API: Pinboard(1)                                      │
+│    CLI: git(7) · gh(3) · curl(2) · reminders-cli(3)     │
+│         jq(2) · markdownlint-cli2(2) · osascript(3)     │
+│         aliyun-cli(1) · pre-commit(1) · python3(1)      │
+│    API: Pinboard(2)                                      │
 │    MCP: yunxiao(3) · context7(1)                         │
 │                                                          │
 │  Skill Dependencies:                                     │
@@ -47,16 +47,18 @@ claude plugin marketplace add https://github.com/niracler/skill.git
 │    └╌╌▶ skill-creator           quality audit (built-in)  │
 │    workspace-init ◇ dev-config-template                  │
 │    workspace-planning ◇ dev-config-template              │
+│    biweekly-collector ◆ Pinboard API                     │
 │    pinboard-manager ◆ Pinboard API                       │
 │                                                          │
 │  Groups:                                                 │
 │    Workspace workspace-init · workspace-planning         │
 │    Workflow  git-workflow · yunxiao · schedule-mgr        │
 │             ha-integration-reviewer · markdown-lint      │
-│             skill-reviewer · code-sync · weekly-report    │
+│             skill-reviewer · code-sync · weekly-report   │
 │             pinboard-manager                             │
 │    Writing  writing-assistant · diary-assistant           │
 │             diary-note · note-to-blog                    │
+│             biweekly-collector                            │
 │    Learning anki-card-generator                          │
 │    Fun      zaregoto-miko                                │
 │                                                          │
@@ -97,6 +99,7 @@ Scope: EN-friendly · macOS only · personal/niche
 | [diary-assistant](skills/writing/diary-assistant/SKILL.md) | Daily journal with GTD task review and planning | reminders-cli, schedule-manager | macOS, personal |
 | [diary-note](skills/writing/diary-note/SKILL.md) | Quick-append notes to today's diary (experiences, TIL, insights) | — | |
 | [note-to-blog](skills/writing/note-to-blog/SKILL.md) | Scan Obsidian notes, evaluate blog-readiness, convert and create draft | writing-assistant | personal |
+| [biweekly-collector](skills/writing/biweekly-collector/SKILL.md) | Collect raw materials from 8 sources (diary, Pinboard, Douban, Telegram, Calendar, Reminders, RSS digests, plrom) for personal biweekly diary | curl, reminders-cli, osascript, git, python3, Pinboard API | macOS, personal |
 
 ### Learning
 

skills/workflow/weekly-report/SKILL.md

@@ -248,20 +248,24 @@ Generate three sections following [report-template.md](references/report-templat
 **本周工作总结:**
 
 - Group by project, each header includes phase progress (e.g., `进度 4/6`) when available
-- Each bullet: `**bold key phrase**：` + concrete description with numbers
-- Boss-readable: explain "what was done" + "why it matters", not implementation details
+- Each project 1-2 bullets max, compress into core deliverables
+- Each bullet: `**bold key phrase**：` + business-language description
+- Use domain numbers (接口数、页面数、参数个数), NOT internal numbers (commit 数、PR#)
+- Skip entirely: CI/CD changes, version bumps, SDK sub-releases, upstream open-source contributions, internal process improvements (CLAUDE.md, openspec schema)
+- sunlite and sylsmart are separate projects — never merge them
 
 **下周工作计划:**
 
 - Source from schedule YAML next-week modules + carry-forward items
-- Include time estimates when known (e.g., `（1 天）`)
-- Each bullet: `**bold key phrase**：` + expected outcome
+- Include time estimates when known (e.g., `（2.5 天）`)
+- Each bullet: `**bold key phrase**：` + expected outcome in business terms
+- sunlite and sylsmart must have separate headers with separate time allocations
 
 **其他事项:**
 
+- Carry-forward items from last week's plan that didn't get done, with brief reason
 - Handoffs, blockers, cross-team coordination
-- Carry-forward items from last week's plan that didn't get done
-- Status changes (task transferred to someone else, scope changes, etc.)
+- Keep it concise — no technical explanations in parentheses
 
 ## Step 5: User Review and Write
 
@@ -350,9 +354,15 @@ Present the proposed schedule to the user first — only create after confirmati
 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.
 
-**Concrete over vague.** Every bullet should have at least one specific number or reference:
-commit count, test coverage, API count, PR/MR number, issue number. "Completed auth module"
-is bad. "Completed auth module (9 endpoints, 91% coverage, MR merged)" is good.
+**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

skills/workflow/weekly-report/references/report-template.md

@@ -39,16 +39,30 @@ The weekly report follows this exact structure. Adapt content but preserve the h
 2. **Progress fraction**: Only for projects with schedule YAML (count done/total modules in current phase)
 3. **Time estimates**: In 下周计划, include `（N 天）` when the user has expressed time allocation
 4. **Bold pattern**: Start each bullet with `**bold key phrase**` followed by `：` (Chinese colon) then description
-5. **Concrete details**: Always include specific numbers — commit count, test count, coverage %, API endpoint count, PR/MR numbers, issue numbers
+5. **Concrete details**: Use business-value numbers (接口数量、页面数、配置参数个数), NOT internal numbers (commit 数、PR 编号、test coverage)
 6. **No markdown headers inside sections**: Use bold project names as line text, not `####` or `#####`
+7. **Each project 1-2 bullets**: Compress into core deliverables, don't list every sub-task
 
-## Style Reference
+## Style Reference — Boss-Readable Writing
 
-The report is read by a manager who is technical but doesn't read the code.
-Each bullet should answer "what was done" + "why it matters" or "what it means for the project".
+The report is for a manager who does NOT read code. Write in **business language**:
 
-Good: `**完成 auth 模块**：包含注册、登录、JWT 刷新等 9 个端点，37 个测试达到 91% 覆盖率，2 个 MR 已合并`
+- Explain **what was done** + **what it enables**, not how it was implemented
+- Use domain terms the boss understands (接口、页面、配置参数、用户可以...)
+- Do NOT use: technical jargon (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, CI/CD details
 
-Bad: `完成了 auth 相关的工作` (too vague, no numbers)
+### Good Examples
 
-Bad: `重构了 BaseService 提取 UUID 解析和成员查询逻辑到基类减少 350 行代码` (too implementation-focused, boss doesn't care about BaseService)
+`**System 模块开发完成**：完成项目管理、成员管理、角色权限共 14 个后端接口，支持四级角色权限体系`
+
+`**ha-dali-center v0.13.0 发布**：新增 4 个设备配置参数，用户可在 Home Assistant 中直接读写，无需依赖桌面软件。已完成端到端测试验证`
+
+### Bad Examples
+
+`完成了 auth 相关的工作` — too vague, no specifics
+
+`重构了 BaseService 提取 UUID 解析和成员查询逻辑到基类减少 350 行代码` — too implementation-focused
+
+`srhome-core 从 v0.1.0 发版到 v0.2.0（新增 INSTALLER 角色枚举）和 v0.2.1（中文 API 描述），sunlite / sylsmart submodule 同步升级` — internal version/infra details, boss doesn't care
+
+`添加 Claude Code GitHub Workflow（PR#77），修复 fork PR 无法访问上游 secrets` — CI internals, skip entirely