Skip to content

feat: add morning-briefing skill#4

Open
saiboyizhan wants to merge 4 commits intoChatAndBuild:mainfrom
saiboyizhan:morning-briefing
Open

feat: add morning-briefing skill#4
saiboyizhan wants to merge 4 commits intoChatAndBuild:mainfrom
saiboyizhan:morning-briefing

Conversation

@saiboyizhan
Copy link

Summary

Adds a Morning Briefing skill that gives users a unified daily kickoff overview.

  • Scans connected tools (Calendar, Slack/Teams, GitHub, Notion, Linear/Jira, Email)
  • Triages into "needs action today" vs "worth knowing", discards noise
  • Outputs a concise briefing: today's schedule, urgent items, updates, suggested focus
  • Adapts to context: warns on meeting-heavy days, encourages deep work on light days, includes Monday/Friday-specific logic
  • Works with any combination of tools, or none (falls back to asking the user)

Relationship to other skills

Pairs with the weekly-review skill (#3) to form a daily + weekly productivity loop. Different from daily-meeting-update which generates a standup report to share with the team — this briefing is for the user themselves.

Checklist

  • SKILL.md with valid frontmatter (id, name, description, category)
  • Category: productivity
  • Under 4000 token limit (~718 words)
  • No external URLs
  • No prompt injection patterns
  • Includes usage examples

@christelbuchanan
Copy link
Contributor

wow this is great @saiboyizhan thanks so much! we will review

@christelbuchanan
Copy link
Contributor

@saiboyizhan thanks for your contribution!

What I’d improve

1) Frontmatter tweaks

  • requires: - text is a bit unclear. Better options:

    • If you mean “no special dependencies”: requires: []
    • If you mean “needs tool connectors”: add explicit names like calendar, email, slack, github, notion, jira/linear. (Even if optional.)
  • Add:

    • language: en (to support multilingual later)
    • privacy: minimal (signals “don’t store content, only summarize”)
    • default_time_window: last_24h (helps triage consistency)

Example:

requires: []
privacy: minimal
default_time_window: "since last briefing or last 24h"
timezone: user

2) 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:

  • Only query sources that are actually connected; otherwise omit.

Also: specify the time window for each source, e.g.:

  • Slack: since last briefing (or last 18h)
  • GitHub: PRs assigned to you + mentions + failed checks
  • Email: unread + flagged only (don’t dump subjects unless important)

3) Improve triage rules so it prioritizes correctly

Your 3 buckets are good. I’d add two deterministic tie-breakers:

Priority scoring heuristic

  • P0: time-bound in next 3 hours OR blocking others OR overdue + high impact
  • P1: due today OR requires reply from you
  • P2: FYI

And a dedupe rule:

  • If something is in “Schedule”, don’t repeat it elsewhere unless there’s an action (agenda to prep, doc to read, reply needed).

4) Add “Ask vs Do” boundary

Morning briefing should summarize, not start taking actions (sending replies, merging PRs) unless user asks.

Add under Guidelines:

  • “Do not perform actions (send messages, merge PRs, reschedule meetings) unless the user explicitly requests.”

5) Tighten “Keep it short” into a measurable constraint

“One screen” is subjective. Make it concrete:

  • Max 8 bullets in “Needs Your Attention”
  • Max 5 bullets in “Updates”
  • Max 6 rows in Schedule (collapse the rest into “+3 more”)

6) Make “Today’s Focus” more deterministic

Right now it’s open-ended (fine), but you’ll get better results if you define the selection rule:

  • Choose 1–3 items from “Needs action today”, biased toward:

    • earliest deadline
    • highest impact
    • longest lead-time
  • If meetings > 4 hours, suggest one focus item only.

7) Add two “nice” UX sections

  • Prep Pack (optional): for the next meeting only

    • “Next up: X in 45 mins — here’s the doc link / last notes”
  • Risks / Watchouts (1 line max):

    • “Risk: back-to-back meetings 10:30–1:00; no lunch gap.”

8) Scheduling / automation compatibility

If this is meant to be automated, add a note like:

  • “Designed to run every morning at a user-defined time.”

And define what “since yesterday” means:

  • “Since the last run timestamp.”

- 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
@saiboyizhan
Copy link
Author

Thank you Christel! Happy to contribute.

@saiboyizhan
Copy link
Author

Thank you for the detailed feedback! I've addressed all 8 points:

  1. Frontmatter: requires: [], added language, privacy, default_time_window, timezone
  2. Scan: only query connected sources, added time window per source
  3. Triage: P0/P1/P2 priority scoring + deduplication rules
  4. Added "Observe, don't act" boundary
  5. Measurable brevity: max 8/5/6 item limits
  6. Focus selection rules: earliest deadline / highest impact / longest lead-time
  7. Added Prep Pack and Risks/Watchouts sections
  8. Added automation note with run timestamp semantics

Please let me know if anything needs further adjustment!

@christelbuchanan
Copy link
Contributor

wow super fast thank you @saiboyizhan , @snowmanxm will double check now

markusha77 pushed a commit that referenced this pull request Mar 17, 2026
@snowmanxm
Copy link

@saiboyizhan , please fix test phase

@greptile-apps
Copy link

greptile-apps bot commented Mar 18, 2026

Greptile Summary

This PR adds a morning-briefing skill that delivers a structured daily kickoff overview by scanning connected tools (Calendar, Slack/Teams, GitHub, Notion, Linear/Jira, Email), triaging results into a prioritised briefing, and adapting output to day-of-week and meeting load. The skill is thoughtfully designed with a clear 4-step workflow and sensible output constraints.

However, there are several issues that should be addressed before merging:

  • Undocumented frontmatter fields (language, privacy, default_time_window, timezone) are not part of the schema defined in CONTRIBUTING.md and are likely to fail the automated "Valid SKILL.md frontmatter" check or be silently ignored on ingest.
  • P0 definition conflict: the Triage section defines P0 as including "overdue + high impact" items, but the Verify step omits that criterion — meaning the model would strip legitimately P0 items during the self-check pass.
  • Category mismatch: frontmatter declares Lifestyle while the PR checklist states productivity; CONTRIBUTING.md lists productivity as a defined category but does not list Lifestyle.
  • Version 2.0.0 is an unusual starting point for a first-time registry submission; semver convention reserves major bumps for breaking changes on an existing skill.
  • Slack time window (18h) is narrower than the declared default_time_window of 24h, which could silently drop DMs and mentions from the 18–24h range.
  • Duplicate principle: "Observe, don't act" appears verbatim in both the Principles section and the Guidelines section.

Confidence Score: 2/5

  • Not safe to merge — the undocumented frontmatter fields risk failing automated validation, and the P0 definition conflict introduces a logic bug in priority triage.
  • Multiple concrete issues exist beyond style preferences: the non-standard frontmatter keys could break the CI schema check that gates all PRs, and the P0 inconsistency between Triage and Verify will cause the model to silently downgrade legitimately urgent items. Combined with the previously flagged category, version, time-window, and duplicate-rule issues, the skill needs several corrections before it is ready.
  • skills/morning-briefing/SKILL.md — all issues are concentrated in this single file

Important Files Changed

Filename Overview
skills/morning-briefing/SKILL.md New skill with well-structured 4-step workflow, but has several issues: four undocumented frontmatter fields not in CONTRIBUTING.md schema (likely to fail automated validation), a P0 definition conflict between the Triage and Verify steps, category set to Lifestyle instead of productivity (checklist mismatch), version set to 2.0.0 for a brand-new submission, a narrower Slack time window (18h) than the declared default (24h), and a duplicate "Observe, don't act" rule across Principles and Guidelines.

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])
Loading

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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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.

Suggested change
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 |
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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.

Suggested change
| **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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 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.

Suggested change
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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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:

Suggested change
- **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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Duplicate principle

"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.
Comment on lines +8 to +12
language: en
privacy: minimal
default_time_window: "since last briefing or last 24h"
timezone: user
requires: []
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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:

Suggested change
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
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 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:

Suggested change
- **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

@saiboyizhan
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants