| name | speckit-changelog-notify |
| description | Generate stakeholder notifications summarizing spec changes for team communication |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"github-spec-kit","source":"changelog:commands/speckit.changelog.notify.md"} |
Changelog Notify
Generate ready-to-send stakeholder notifications that summarize what changed in the spec. Produces formatted messages suitable for Slack, email, PR descriptions, or standup updates — so the team always knows what's happening with requirements.
User Input
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty). The user may specify:
- Channel format (e.g., "slack", "email", "pr-description", "standup")
- Audience (e.g., "engineering", "product", "leadership", "full team")
- Timeframe (e.g., "today's changes", "this sprint", "since v1.0")
- Urgency (e.g., "breaking change alert", "routine update")
Prerequisites
- Confirm you are inside a git repository.
- Resolve the active feature by running
.specify/scripts/bash/check-prerequisites.sh --json from the repo root and parsing FEATURE_DIR and AVAILABLE_DOCS. The spec artifacts live in $FEATURE_DIR/ (under specs/<feature>/), not under .specify/. Always quote "$FEATURE_DIR" in shell snippets — the resolved value is absolute and may contain spaces.
- Get recent spec changes:
git log --oneline -10 -- "$FEATURE_DIR/spec.md".
- Read the current spec.md.
- Read the previous version for comparison.
- If plan.md or tasks.md changed, include those changes.
Outline
-
Identify Changes: Determine what changed since last notification point.
Collect:
- Requirements added, modified, removed
- Scope impact (effort delta)
- Breaking changes or blockers
- Priority shifts
-
Generate Slack Format: Short, scannable, emoji-enhanced.
## Slack Notification
📋 **Spec Update: User Auth System**
*3 changes since yesterday:*
➕ Added: Email verification requirement
✏️ Changed: JWT expiry reduced from 24h → 1h
❌ Removed: Social login (deferred to v2)
📊 Impact: +8h effort | Complexity: 52 → 66
⚠️ Breaking: JWT clients need refresh token support
_Full changelog: `/speckit.changelog.generate`_
-
Generate Email Format: More detailed, context-rich.
## Email Notification
**Subject:** Spec Update — User Auth System (3 changes, +8h effort)
Hi team,
The User Auth spec was updated with 3 changes that affect the current sprint:
**New Requirements:**
- Email verification: Users must verify email before accessing protected resources
- Effort: +5h | Phase: 2a | Priority: P1
**Modified Requirements:**
- JWT token expiry reduced from 24h to 1h (security hardening)
- Effort: +2h for refresh token implementation
- ⚠️ Breaking: All API clients need to implement token refresh
**Deferred:**
- Social login (Google, GitHub) moved to v2.0
- Effort saved: -3h this sprint
**Net Impact:** +8h effort | Sprint fit: 🟡 Tight (48h needed, 40h available)
**Action needed:** Engineering team to review JWT breaking change by EOD Wednesday.
Best,
[Auto-generated by Spec Changelog]
-
Generate PR Description Format: Technical, diff-focused.
## PR Description
## Spec Changes
This PR updates the User Auth spec with 3 requirement changes:
| Change | Requirement | Impact |
|--------|------------|--------|
| ➕ Added | Email verification | +5h effort, new Phase 2a task |
| ✏️ Modified | JWT expiry (24h → 1h) | +2h effort, breaking change |
| ❌ Removed | Social login | -3h effort, deferred to v2 |
**Complexity:** 52 → 66 (+27%)
**Effort:** 42h → 50h (+8h)
### Breaking Changes
- JWT token expiry reduced — clients must implement refresh token flow
### Reviewers
- [ ] @backend-team — JWT changes
- [ ] @product — Scope change approval
-
Generate Standup Format: Ultra-brief, verbal-friendly.
## Standup Update
**Spec changes (User Auth):**
- Added email verification (+5h)
- Hardened JWT tokens — expiry now 1h instead of 24h (+2h)
- Dropped social login for now (-3h)
- Net: +8h, sprint is tight but doable if we defer admin polish
-
Output: Deliver all requested notification formats (default: all four).
Rules
- Read-only — never modify any files, only analyze and generate notification text
- Git-authoritative — all change data comes from git history
- Multi-format — support Slack, email, PR description, and standup formats
- Audience-aware — adjust detail level and language for the target audience
- Action-oriented — always highlight what action is needed from recipients
- Breaking changes first — lead with urgent/breaking items in every format
- Quantified impact — always include effort and complexity deltas
- Copy-paste ready — notifications should be directly usable without editing