Menu
Write a changelog from recent PRs and commits, grounded in feature context. Use after shipping, at the end of a sprint, or for release notes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Scope a single product increment end-to-end โ context, spec, implementation, wireframes, and engineering considerations. Use when a feature or bet needs a shippable document before building โ typically the option chosen out of /workshop's divergence. Leads to /critique-product.
Print a quick-reference cheatsheet of all Acumen skills, organized by layer.
Pull latest code from main, summarize recent changes in product-friendly terms, and report .acumen/ context health (what exists, what's fresh, what's stale, what's missing). Preserves all .acumen/ context files.
Evaluate and validate a PM artifact โ score for rigor, test riskiest assumptions, and decide if it's ready to ship. Use when reviewing a PRD, spec, increment, strategy, or roadmap.
Find what's broken and what's underexploited โ problems AND opportunities โ grounded in data, value delivery per persona, and current features. The entry point to ideation; hands sharp problems and opportunities to /workshop.
One-time setup that gathers product context for your project and saves it to .acumen.md. Run once to establish persistent product guidelines.
Based on SOC occupation classification
| name | changelog |
| description | Write a changelog from recent PRs and commits, grounded in feature context. Use after shipping, at the end of a sprint, or for release notes. |
| user-invocable | true |
| argument-hint | [time range] |
Invoke /product-thinking โ it contains the Context Gathering Protocol and the AI Slop Test. Follow the protocol before proceeding.
A changelog is not a commit log. It's a story about what changed for users, written in their language. Engineers care about what was built. Users care about what they can do now. A good changelog bridges both โ it's specific enough for engineers to recognize their work, and clear enough for users to understand the impact.
Ask the user:
Use git log to gather all commits and merged PRs in the specified time range. For each:
Read .acumen/features.md to understand the business context behind each change:
Read .acumen.md for product positioning โ frame changes in terms of the product's value proposition, not its architecture.
Group changes into:
Drop changes that are purely internal (refactors, dependency updates, CI changes) unless they affect performance or reliability in a way users would notice.
# Changelog โ [date range]
## New
- **[Capability name]** โ what users can do now that they couldn't before. One sentence, benefit-first.
## Improved
- **[Feature name]** โ what got better and why it matters. Be specific: "Export is 3x faster" not "performance improvements."
## Fixed
- **[What was broken]** โ what users experienced and what they'll experience now.
## Changed
- **[What changed]** โ what's different and what users need to do (if anything). Flag breaking changes clearly.
Rules:
After the text changelog, generate a companion video script:
## Video Script โ [date range]
**Duration:** [estimated minutes, aim for 2-5 min]
### Intro (15 sec)
[Opening line โ what this update covers, keep it conversational]
### [Section 1: Most impactful change] (30-60 sec)
- **Show**: [what to demonstrate on screen]
- **Say**: [script, conversational tone, benefit-first]
- **Transition**: [bridge to next section]
### [Section 2: Next change] (30-60 sec)
...
### Wrap-up (15 sec)
[Summary of what shipped, what's coming next if known, call to action]
Rules for video script:
Present the changelog to the user for review. Ask if any changes should be reframed, elevated, or removed.
Do NOT save to .acumen/reports/ unless the user confirms โ changelogs are typically published externally, not stored internally.