feat: add morning-briefing skill#4
Conversation
|
wow this is great @saiboyizhan thanks so much! we will review |
|
@saiboyizhan thanks for your contribution! What I’d improve1) Frontmatter tweaks
Example: requires: []
privacy: minimal
default_time_window: "since last briefing or last 24h"
timezone: user2) Make “Scan” implementation-safe (don’t promise what isn’t connected)Right now it says “Silently check which tools are available…” , good, but then the table assumes specific tools. Add one line:
Also: specify the time window for each source, e.g.:
3) Improve triage rules so it prioritizes correctlyYour 3 buckets are good. I’d add two deterministic tie-breakers: Priority scoring heuristic
And a dedupe rule:
4) Add “Ask vs Do” boundaryMorning briefing should summarize, not start taking actions (sending replies, merging PRs) unless user asks. Add under Guidelines:
5) Tighten “Keep it short” into a measurable constraint“One screen” is subjective. Make it concrete:
6) Make “Today’s Focus” more deterministicRight now it’s open-ended (fine), but you’ll get better results if you define the selection rule:
7) Add two “nice” UX sections
8) Scheduling / automation compatibilityIf this is meant to be automated, add a note like:
And define what “since yesterday” means:
|
- Frontmatter: requires: [], add language/privacy/default_time_window/timezone - Scan: only query connected sources, add time window per source - Triage: P0/P1/P2 priority scoring + deduplication rules - Add "Observe, don't act" boundary in Principles and Guidelines - Measurable brevity: max 8/5/6 item limits per section - Today's Focus: deterministic selection rules (deadline/impact/lead-time) - Add Prep Pack and Risks/Watchouts sections - Add automation compatibility note with run timestamp semantics
|
Thank you Christel! Happy to contribute. |
|
Thank you for the detailed feedback! I've addressed all 8 points:
Please let me know if anything needs further adjustment! |
|
wow super fast thank you @saiboyizhan , @snowmanxm will double check now |
|
@saiboyizhan , please fix test phase |
Greptile SummaryThis PR adds a However, there are several issues that should be addressed before merging:
Confidence Score: 2/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A([User triggers Morning Briefing]) --> B{Any tools connected?}
B -- No --> C[Ask user what to review]
B -- Yes --> D[Step 1: SCAN\nQuery each connected source\nwithin its time window]
D --> D1[Calendar → Today's events]
D --> D2[Slack/Teams → DMs & mentions since 18h]
D --> D3[GitHub → Open PRs & CI checks]
D --> D4[Notion / Linear / Jira → Due tasks]
D --> D5[Email → Unread count + flagged]
D1 & D2 & D3 & D4 & D5 --> E[Step 2: TRIAGE\nScore each item P0 / P1 / P2]
E --> E1{P0 or P1?}
E1 -- Yes --> F[Needs Your Attention section]
E1 -- P2 --> G[Updates section]
E1 -- Below P2 --> H[Discard silently]
F & G --> I[Step 3: DELIVER\nRender structured briefing\nApply Adaptation Rules]
I --> I1{Monday?}
I1 -- Yes --> I2[Append Friday open-items recap]
I1 -- Friday --> I3[Append weekend wrap-up note]
I1 -- Meeting-heavy --> I4[Warn about meeting load]
I2 & I3 & I4 --> J[Step 4: VERIFY\nSilent self-check against 7 rules]
J --> K{All checks pass?}
K -- No --> L[Fix & re-check]
L --> K
K -- Yes --> M([Output briefing to user])
Last reviewed commit: "fix: add verificatio..." |
| id: morning-briefing | ||
| name: Morning Briefing | ||
| description: Start your day with a unified briefing — today's calendar, pending tasks, messages needing attention, and PRs to review. | ||
| category: Lifestyle |
There was a problem hiding this comment.
Category mismatch with PR checklist
The frontmatter declares category: Lifestyle, but the PR checklist explicitly states "Category: productivity". Looking at the sibling skill daily-meeting-update, it uses category: Business. The category value affects how the skill is discovered and grouped in the registry, so this should be intentional and consistent with the checklist claim.
| category: Lifestyle | |
| category: productivity |
| | Source | What to pull | Time window | | ||
| |--------|-------------|-------------| | ||
| | **Calendar** | Today's events — times, titles, attendees. Flag back-to-back meetings and large gaps. | Today | | ||
| | **Slack/Teams** | Unread DMs, @mentions, key channel highlights. | Since last briefing or last 18h | |
There was a problem hiding this comment.
Inconsistent time window for Slack
The frontmatter defines default_time_window: "since last briefing or last 24h", but the Slack row in the scan table specifies "Since last briefing or last 18h" — a different (shorter) fallback. This discrepancy means Slack will silently use a narrower window than all other sources, which could cause the user to miss DMs/mentions from the 18–24h range. Either align this with the default (24h) or document the intentional difference.
| | **Slack/Teams** | Unread DMs, @mentions, key channel highlights. | Since last briefing or last 18h | | |
| | **Slack/Teams** | Unread DMs, @mentions, key channel highlights. | Since last briefing or last 24h | |
| description: Start your day with a unified briefing — today's calendar, pending tasks, messages needing attention, and PRs to review. | ||
| category: Lifestyle | ||
| author: saiboyizhan | ||
| version: 2.0.0 |
There was a problem hiding this comment.
Unexpected version for a new skill
version: 2.0.0 on a first-time submission to the registry is unusual — semver conventions reserve 2.0.0 for backwards-incompatible major releases of an existing skill. Starting at 1.0.0 is more appropriate and avoids confusion for consumers who may interpret a major version bump as a breaking change from a prior 1.x version.
| version: 2.0.0 | |
| version: 1.0.0 |
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| - **Meeting-heavy day** (>4 hours): Warn the user ("You have 6 hours of meetings today — protect your lunch break for deep work"). | ||
| - **Light day** (≤1 meeting): Encourage focus ("Only 1 meeting today — great day for heads-down work"). | ||
| - **Overdue items**: Surface them clearly but without guilt ("These items are past due — want to reschedule or drop any?"). | ||
| - **Monday**: Include a brief recap of what was left open on Friday if data is available. |
There was a problem hiding this comment.
Monday recap incompatible with default time window
The adaptation rule says "Include a brief recap of what was left open on Friday if data is available", but the default scan time window is "last 24h" for first-time / unknown-last-run users. On Monday morning, 24 hours only reaches back to Sunday — Friday's open items will not be retrieved. The Monday rule will silently produce nothing for new users or after a multi-day gap.
Consider extending the Monday fallback window, or explicitly documenting that the Monday recap only works when a prior "last briefing" timestamp is available:
| - **Monday**: Include a brief recap of what was left open on Friday if data is available. | |
| - **Monday**: Include a brief recap of what was left open on Friday — only when "since last briefing" resolves to a timestamp before the weekend. If last run was today or yesterday, skip the recap. |
| - **Speed over completeness**: The user wants a 2-minute read, not a 20-minute report. Summarize aggressively. | ||
| - **Signal over noise**: Only surface things that need attention today. Yesterday's resolved items are irrelevant. | ||
| - **No tool, no problem**: Work with whatever is connected. If nothing is connected, ask the user what they'd like to review. | ||
| - **Observe, don't act**: Do not perform actions (send messages, merge PRs, reschedule meetings) unless the user explicitly requests. |
There was a problem hiding this comment.
"Observe, don't act" is listed identically in both the Principles section (line 32) and the Guidelines section (line 146). Having the same rule in two sections adds noise and can create confusion about which one is authoritative if they ever diverge. Consider keeping it in Principles only and removing the duplicate in Guidelines.
Add Step 4: Verify with a self-check checklist covering fabrication, item limits, deduplication, priority accuracy, empty sections, timezone, and actionable language — per reviewer feedback.
| language: en | ||
| privacy: minimal | ||
| default_time_window: "since last briefing or last 24h" | ||
| timezone: user | ||
| requires: [] |
There was a problem hiding this comment.
Undocumented frontmatter fields will likely fail automated validation
CONTRIBUTING.md defines exactly four optional frontmatter fields: author, version, requires, and examples. The PR adds four extra fields — language, privacy, default_time_window, and timezone — that are outside that schema.
The automated review check listed in CONTRIBUTING.md includes "Valid SKILL.md frontmatter", which means these unknown keys could cause the PR to fail CI or be silently stripped on ingest. Comparing to the only other skill with similar complexity (daily-meeting-update), none of those extra keys appear there either.
Consider removing or moving these to inline comments within the skill body instead:
| language: en | |
| privacy: minimal | |
| default_time_window: "since last briefing or last 24h" | |
| timezone: user | |
| requires: [] | |
| id: morning-briefing | |
| name: Morning Briefing | |
| description: Start your day with a unified briefing — today's calendar, pending tasks, messages needing attention, and PRs to review. | |
| category: Lifestyle | |
| author: saiboyizhan | |
| version: 2.0.0 | |
| requires: [] | |
| examples: |
|
|
||
| ### Priority Levels | ||
|
|
||
| - **P0 — Do now**: time-bound in next 3 hours, OR blocking others, OR overdue + high impact |
There was a problem hiding this comment.
P0 definition diverges from the Verify step, causing silent reclassification
The Triage section (line 66) defines P0 as:
time-bound in next 3 hours, OR blocking others, OR overdue + high impact
However, the Verify table at line 142 defines it more narrowly as:
P0 items are truly time-bound (next 3h) or blocking. Don't inflate priority.
The "overdue + high impact" leg is absent from the Verify definition. As a result, any item correctly assigned P0 during Triage for being "overdue + high impact" would be silently downgraded during the Verify pass (the model would interpret it as priority inflation), stripping it from the "Needs Your Attention" section entirely.
The two definitions need to agree. Either add "overdue + high impact" back into the Verify rule, or remove it from the Triage definition:
| - **P0 — Do now**: time-bound in next 3 hours, OR blocking others, OR overdue + high impact | |
| - **P0 — Do now**: time-bound in next 3 hours, OR blocking others |
|
Hi @snowmanxm — added Step 4: Verify phase (commit aa2aab2) with a self-check checklist covering no fabrication, item limits, deduplication, priority accuracy, empty section removal, timezone correctness, and actionable language. Let me know if this is what you had in mind! |
Summary
Adds a Morning Briefing skill that gives users a unified daily kickoff overview.
Relationship to other skills
Pairs with the
weekly-reviewskill (#3) to form a daily + weekly productivity loop. Different fromdaily-meeting-updatewhich generates a standup report to share with the team — this briefing is for the user themselves.Checklist
SKILL.mdwith valid frontmatter (id, name, description, category)productivity