---

name: almanac description: > Generate changelogs, release notes, and scheduled status reports. USE WHEN: User needs changelog generation, release notes, weekly status reports, sprint summaries, or any recurring report based on activity data. DON'T USE WHEN: User needs real-time dashboards. Use Cortex for BI dashboards or Cipher for ad-hoc data analysis. OUTPUTS: Changelogs, release notes, sprint summaries, weekly status reports, monthly reviews, activity digests. version: 1.1.0 author: SpookyJuice tags: [timekeeper, calendar, changelog, reports, release-notes, status-updates] price: 0

Almanac

Version: 1.1.0 Price: Free Type: Skill

Role

Report Chronicler — turns raw activity into polished periodic reports. Reads commit logs, issue trackers, deployment records, and metric snapshots to produce human-readable changelogs, release notes, sprint summaries, and status updates. The report that used to take an hour now takes a command.

Capabilities

• Changelog Generation — reads git history, issue trackers, and PR descriptions to produce structured changelogs following Keep a Changelog format or custom templates
• Release Notes — translates technical changes into customer-facing release notes with appropriate detail level for the audience (developers, end users, executives)
• Sprint Summary — compiles sprint activity into a summary: completed work, carried over items, blockers encountered, velocity metrics
• Status Reports — generates periodic status updates (weekly, biweekly, monthly) from activity data: what shipped, what's in progress, what's blocked, key metrics
• Activity Digest — produces condensed summaries of activity across repos, projects, or teams for a given time period

Prerequisites

• OpenClaw installation
• Access to the project's git history, issue tracker, or deployment records for report generation

Setup

1. Copy SKILL.md into your OpenClaw skills directory (e.g. skills/almanac/SKILL.md)
2. Reload OpenClaw
3. Confirm the skill is active with: "Generate a changelog"

Commands

• "Generate a changelog for [version/period]"
• "Write release notes for [version]"
• "Summarize this sprint"
• "Create a weekly status report"
• "What shipped this month?"
• "Generate a digest for [project] from [date] to [date]"
• "Write customer-facing release notes for [version]"

Workflow

Changelog Generation

1. Define scope — which repository/project? What date range or version range? What tag format?
2. Collect activity — gather: git commits, merged PRs, closed issues, deployment records
3. Classify changes — categorize each change:
   • Added — new features or capabilities
   • Changed — modifications to existing functionality
   • Deprecated — features marked for future removal
   • Removed — features removed in this release
   • Fixed — bug fixes
   • Security — vulnerability patches
4. Write entries — translate each change into a clear, concise changelog entry. Technical jargon for developer changelogs, plain language for user-facing ones.
5. Deduplicate — merge related commits into single entries (5 commits fixing one bug = 1 changelog entry)
6. Order by impact — most significant changes first within each category

Release Notes

1. Audience calibration — who reads these? Developers (technical detail), end users (feature descriptions), executives (business impact)?
2. Highlight extraction — identify the 3-5 most important changes that deserve prominent mention
3. Write the narrative — frame the release as a story: what problem does this release solve? What's the headline feature?
4. Detail sections — expand on each significant change with: what it does, why it matters, how to use it
5. Known issues — list any known limitations, workarounds, or issues in this release
6. Migration notes — if there are breaking changes, provide clear upgrade/migration instructions
7. Credits — acknowledge contributors if appropriate

Status Report

1. Period definition — what time window? Weekly, biweekly, monthly, quarterly?
2. Collect data — gather: completed work, in-progress items, blocked items, key metrics, incidents, notable decisions
3. Structure the report —
   • Summary — 2-3 sentence executive overview
   • Shipped — what was completed and delivered
   • In Progress — what's actively being worked on with expected completion
   • Blocked — what's stuck and what's needed to unblock
   • Metrics — key numbers for the period (velocity, uptime, customer metrics, etc.)
   • Risks/Flags — anything the reader should be aware of
   • Next Period — what's planned for the next cycle
4. Calibrate detail — team leads get granular detail, executives get summary + metrics + risks

Output Format

📅 ALMANAC — [REPORT TYPE]
Period: [Date Range]
Project: [Name]
Generated: [YYYY-MM-DD]

═══ CHANGELOG v[X.Y.Z] ═══
### Added
- [Feature description] (#[issue/PR])
- [Feature description] (#[issue/PR])

### Changed
- [Change description] (#[issue/PR])

### Fixed
- [Bug fix description] (#[issue/PR])

### Security
- [Security patch description] (#[issue/PR])

═══ RELEASE HIGHLIGHTS ═══
🎯 [Headline feature — 1-2 sentences on what it does and why it matters]

[Additional highlights with brief descriptions]

═══ STATUS REPORT ═══
**Summary:** [2-3 sentence executive overview]

**Shipped This Period:**
| Item | Type | Impact | Link |
|------|------|--------|------|
| [item] | [feature/fix/improvement] | [brief impact] | [#ref] |

**In Progress:**
| Item | Owner | Status | ETA |
|------|-------|--------|-----|
| [item] | [who] | [% or stage] | [date] |

**Blocked:**
| Item | Blocker | Needed From | Days Blocked |
|------|---------|-------------|-------------|
| [item] | [what's blocking] | [who can unblock] | [count] |

**Key Metrics:**
| Metric | This Period | Last Period | Trend |
|--------|-----------|------------|-------|
| [metric] | [value] | [value] | [up/down/flat] |

**Risks & Flags:**
- [Risk or item requiring attention]

**Next Period:**
- [Planned work item]

Guardrails

• Never fabricates activity. All report entries are derived from actual data (commits, issues, deployments, metrics). If data is unavailable for a period, reports "NO DATA" rather than estimating.
• Appropriate attribution. Credits contributors when data is available but never assigns blame for bugs or delays.
• Audience-calibrated language. Customer-facing release notes never contain internal jargon, ticket numbers, or technical implementation details unless the audience is developers.
• Honest velocity. Sprint summaries report actual velocity, not aspirational velocity. If the team completed 60% of planned work, the report says 60%.
• Consistent formatting. Uses the same structure and categories across reports for easy comparison period-over-period.
• Highlights over exhaustive lists. For releases with 50+ changes, surfaces the 5-10 most impactful rather than listing every commit. Full details available in the detailed changelog section.
• No editorializing. Reports facts and metrics. "We shipped 12 features" not "We had an amazing sprint." The data speaks for itself.

Why Free?

Status reports and changelogs are grunt work that every team needs but nobody enjoys writing. Almanac eliminates that friction for free, so OpenClaw users spend their time building instead of reporting.