OmexIT/skills/release-notes
skills/release-notes/SKILL.md
--- name: release-notes description: Draft release notes from a set of PRs/commits or a feature description. Produces user-facing notes, internal notes, known issues, and rollout steps. Triggers: "release notes", "changelog", "what shipped". argument-hint: "[version | date range | PR list]" disable-model-invocation: true --- # Release notes ## Inputs - Version number or date range - List of merged PRs or commit range (or a summary of what shipped) - Audience: external users, internal stakehold
$ install --global
skillsauthnpx skillsauth add OmexIT/claude-skills-pack skills/release-notesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 23, 2026, 8:13 PM221.4s2 files scanned
SKILL.md
- name:
- release-notes
- description:
- Draft release notes from a set of PRs/commits or a feature description. Produces user-facing notes, internal notes, known issues, and rollout steps. Triggers: "release notes", "changelog", "what shipped".
- argument-hint:
- [version | date range | PR list]
- disable-model-invocation:
- true
Release notes
Inputs
- Version number or date range
- List of merged PRs or commit range (or a summary of what shipped)
- Audience: external users, internal stakeholders, or both
How I'll think about this
- Audience-first writing: External users care about what changed for them. Internal teams care about what might break, what to monitor, and what to tell support. Write different sections for different readers.
- Outcomes over implementation: "You can now export reports as PDF" not "Added PDFExportService with async rendering pipeline." Users don't care how — they care what and why.
- Breaking changes need migration paths: Every breaking change must include: what broke, who's affected, what to do about it, and a timeline. Never just say "Breaking: API v2 removed."
- Be honest about known issues: Shipping with known issues is fine. Shipping without telling anyone is not.
- Group by impact: Highlights (big features) → Improvements (enhancements) → Fixes (bugs) → Breaking changes. Most readers stop after highlights.
Anti-patterns to flag
- Jargon-heavy notes that only engineers understand
- "Various bug fixes and improvements" (uninformative)
- Breaking changes buried in a list without migration guidance
- Missing rollback/rollforward instructions for operators
- No mention of monitoring or alerts for high-risk changes
Quality bar
- A non-technical user can understand the highlights section
- Breaking changes include specific migration instructions
- Internal operations section has rollback plan and monitoring guidance
- Known issues are listed with workarounds (if any)
- Links to PRs, dashboards, and runbooks are included for internal audience
Workflow context
- Typically follows:
code-review:code-review(official plugin),/test-plan - Feeds into:
/stakeholder-update, customer communications - Related:
/experiment-design(staged rollout notes),/incident-response(if rollout causes issues)
Output
Fill templates/release-notes.md.
Output contract
produces:
- type: "release-notes"
format: "markdown"
path: "claudedocs/<feature>-release-notes.md"
sections: [highlights, breaking_changes, migration, rollback]
Related Skills
OmexIT/verify-impl
tools
VerifiedTrustedCommunity
Use this skill to verify a completed implementation through live testing — API calls, database state checks, and UI automation with Playwright. Triggers include: "test the implementation", "verify this works", "run API tests", "check the database", "test the UI", "end-to-end verify", "smoke test", "sanity check the implementation", "manually test", or any time an implementation needs post-build validation beyond unit tests. Also triggered automatically by spec-to-impl during the integration review phase. Use this when you want real evidence the system works — not just that tests compile. Can consume a pre-generated e2e/test-plan.yaml from spec-to-impl for fully automated test execution.
13SKILL.mdUpdated Apr 23, 2026
OmexIT/skills/ux-review
development
VerifiedTrustedCommunity
--- name: ux-review description: Evaluate a UI/UX design or implementation using heuristic analysis, accessibility audit, and cognitive walkthrough. Triggers: "UX review", "usability review", "heuristic evaluation", "accessibility audit", "is this usable". argument-hint: "[feature / screen / URL / mockup]" effort: high --- # UX review ## What I'll do Evaluate a design or implementation for usability, accessibility, and user experience quality using established heuristic frameworks. ## Inputs
13SKILL.mdUpdated Apr 23, 2026
OmexIT/skills/user-flow
development
VerifiedTrustedCommunity
--- name: user-flow description: Map user journeys through a feature or product, identifying key paths, decision points, friction, error states, and edge cases. Triggers: "user flow", "user journey", "flow diagram", "happy path", "user path". argument-hint: "[feature / user goal]" effort: medium --- # User flow ## What I'll do Map the complete user journey for a feature — from entry point through completion — including happy paths, error states, edge cases, and decision points. > **user-flow
13SKILL.mdUpdated Apr 23, 2026
OmexIT/ui-design
development
VerifiedTrustedCommunity
Use this skill to produce complete UI/UX design artifacts from a specification document or panel analysis. Triggers include: "design the UI for this spec", "create wireframes", "design this panel", "UX design from spec", "generate component specs", "design tokens", "create the UI design for", "design system for", "wireframe this feature", "design a UI", "create a design system", "design this component", "design the layout", "create a style guide", "design a screen", "UI/UX review", "typography system", "color system", "spacing system", "design this feature", "design the dashboard", "design the onboarding", "create a component library", "design review", "audit the design", "improve the UI", "redesign this", "design system documentation", "create design guidelines", "responsive design", "mobile design", "dark mode design", "design the brand", or any time a spec/panel analysis document needs to be transformed into actionable UI/UX deliverables before implementation. Also triggers for standalone design system creation, component design, design reviews, dark mode/responsive variants, and developer handoff — even before code is involved. Orchestrates a multi-agent design team (UX Lead, UI Designer, Component Architect, Accessibility Reviewer, Design System Engineer, Design Reviewer) in parallel waves. Outputs feed directly into spec-to-impl's FE agent and figma-to-code.
13SKILL.mdUpdated Apr 23, 2026