Menú
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.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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.
| 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.