Adoption

Agent Skills are supported by leading AI development tools.

VS Code Gemini CLI GitHub Goose Amp Cursor Claude Code Letta OpenCode Claude OpenAI Codex Factory VS Code Gemini CLI GitHub Goose Amp Cursor Claude Code Letta OpenCode Claude OpenAI Codex Factory

mostafa-drz/release-notes

Name: release-notes
Author: mostafa-drz

code/release-notes/SKILL.md

npx skillsauth add mostafa-drz/claude-skills release-notes

Clean

TrivyContainer and dependency vulnerability scanner

Clean

SemgrepStatic code analysis for vulnerabilities

Clean

mcp-scan (Snyk)Model Context Protocol security validation

Skipped

Snyk (dep)Open source security scanning

Skipped

Socket.devSupply chain security analysis

Skipped

VirusTotalMulti-engine malware detection

Skipped

CrowdStrikeAdvanced threat intelligence

Skipped

OSV-ScannerOpen Source Vulnerability database check

Skipped

OWASP Dep-Check

Release Notes

Generate release notes for a release PR. Brief, truth-based, no fabrication.

Configuration

On startup, use the Read tool to load ~/.claude/skills/release-notes/preferences.md.

Tracker-agnostic — works with any issue tracker (Linear, Jira, GitHub Issues, Asana, ClickUp, Shortcut, Plane, Notion, custom). You configure two things: how to detect ticket IDs in PR bodies, and how to link them.

Expected keys:

- ticket-prefix: <PREFIX>                    # Optional. Tracker key — e.g., ENG, PROJ, ABC, JIRA. Used to detect IDs as <PREFIX>-NNNN. If unset, falls back to the generic regex [A-Z]{2,5}-\d+ (any uppercase prefix + dash + digits).
- ticket-url-template: <url-with-{TICKET}>   # Optional. URL template with literal `{TICKET}` placeholder. Examples:
                                             #   Linear:        https://linear.app/myorg/issue/{TICKET}
                                             #   Jira:          https://myteam.atlassian.net/browse/{TICKET}
                                             #   GitHub Issues: https://github.com/myorg/myrepo/issues/{TICKET}
                                             #   Asana:         https://app.asana.com/0/{TICKET}
                                             #   Shortcut:      https://app.shortcut.com/myorg/story/{TICKET}
                                             #   Plane:         https://app.plane.so/myorg/projects/.../issues/{TICKET}
                                             # If unset, ticket IDs render as bare text without links.

Behavior when keys are missing:

No ticket-prefix → use the generic regex [A-Z]{2,5}-\d+. Works for most trackers.
No ticket-url-template → render bare ticket IDs (e.g., Closes ENG-1234.). Mention once at the end: "Set ticket-url-template in preferences.md to enable clickable ticket links."

Hard rules

Truth only. Every claim must be sourced from a merged PR's actual title/body. Never invent features, motivations, or impact statements that aren't in the source PRs.
Brief. Each PR section is 1–3 sentences max. Cut file enumerations, architecture diagrams, dead-code lists, "what changed" prose blocks. Mirror the source PR's ## Summary, not its full body.
Never git add -A and never push the release notes without showing them to the user first and getting explicit approval.
No drive-bys. Do not add commentary, suggestions, or "follow-ups" the source PRs didn't flag.

Steps

1. Resolve the release PR

If $ARGUMENTS is a number → that's the PR.
Else → gh pr list --base prod --state open --limit 5 --json number,title,headRefName and ask the user which one if multiple, or use the only open one.
Capture: number, title, baseRefName, headRefName, url.

2. List the squash-merged PRs in the release

gh pr view <release-pr> --json commits --jq '.commits[].messageHeadline'

Each squash-merged commit headline ends in (#NNN) — extract the PR numbers. If commits is sparse (squash-merge collapsed history), fall back to:

git log origin/<base>..origin/<head> --oneline

and grep (#\d+) from the headlines.

3. Fetch each child PR

For each PR number, in parallel:

gh pr view <num> --json title,body,number,url,labels

Extract from each:

title (use as section heading after stripping conventional-commit prefix if helpful)
## Summary paragraph (or first 1-3 sentences of the body if no Summary section)
Issue-tracker ticket IDs from anywhere in the body — match <TICKET-PREFIX>-NNNN (where TICKET-PREFIX comes from preferences, falling back to [A-Z]{2,5}-\d+). When ticket-url-template is set, substitute {TICKET} to build the link; otherwise render the bare ticket ID.
PR URL (for the #NNN link, GitHub auto-links)

If a PR's Summary is more than ~3 sentences, halve it, then halve again. Keep only the user-visible/product-visible bits. Cut implementation prose ("service-side normalizers", "Zod widens", file paths) unless that is the product change.

4. Build the body

Template:

## What's in this release

**1. <Short topic — strip cc-prefix> — #<PR>**
<1–3 sentence summary, sourced from the PR body. User-visible framing.>

Closes [<TICKET>](<ticket-url-template with {TICKET} substituted>)<` · [<TICKET-2>](...)` if multiple>. If no template configured, render as `Closes <TICKET>.` (no link).

**2. <Short topic> — #<PR>**
<1–3 sentences.>

Closes [<TICKET>](...).

## How to test

- <One bullet per PR — pulled from that PR's test plan, simplified to the manual-verify path.>
- <...>

If — and only if — a source PR explicitly flags a follow-up that blocks prod (deploy ordering, flag flip, infra step), add:

## Follow-ups

- <The blocking item, verbatim from the source PR.>

Otherwise, skip the Follow-ups section. Do not invent follow-ups.

5. Title

Format: Release YYYY-MM-DD — <2–6 word theme>

The theme should name the 1–2 biggest user-visible changes (e.g., "PMI UI + migration cleanup"). Use today's date.

6. Show, then push

Print the full proposed title + body to the user. Then ask:

Push this to PR #<num>? (yes / edit / no)

yes → write the body to a temp file, then push via REST (works around the Projects-classic GraphQL deprecation that blocks gh pr edit on this org):
```
gh api -X PATCH "repos/<org>/<repo>/pulls/<num>" \
  -f title="<title>" \
  -F body=@/tmp/pr-<num>-body.md \
  --jq '"OK: " + .title + " — " + .html_url'
```
Try gh pr edit first if you prefer; if it errors with Projects (classic) is being deprecated, fall back to the REST call above. The edit does not land on the GraphQL failure — always verify via gh pr view <num> --json title --jq .title.
edit → ask what to change, regenerate, ask again
no → leave the PR alone, exit

7. Verify

After push, gh pr view <num> --json title,body --jq '.title' to confirm the edit landed. Report the URL.

Style reminders (drawn from user prefs)

Cut: file paths, line counts, "Adds/Removes/Migrates" tables, architecture diagrams, Figma node IDs, internal scaffolding details.
Keep: what changed for the user, what it closes, how to verify it on staging.
If a source PR is purely internal (refactor, test infra, dep bump) and has no user-visible surface, still list it but flag it as such in one sentence: "Internal — <one-liner>." No padding.
If two source PRs are part of the same chunked feature, group them under one numbered section with both #NNN links rather than splitting.

mostafa-drz/release-notes

code/release-notes/SKILL.md

Generates brief, truth-based release notes for a release PR (typically main → prod) by listing each squash-merged PR, a one-paragraph summary drawn from each PR body, and the linked issue-tracker tickets (Linear, Jira, GitHub Issues, Asana, ClickUp, Shortcut, Plane, etc. — any tracker, configured via a URL template). Use when opening or updating a release PR.

1 stars

tools

Updated May 11, 2026

$ install --global

skillsauth

npx skillsauth add mostafa-drz/claude-skills release-notes

Install 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.

Scanners Passed

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: May 11, 2026, 6:13 AM302.1s1 file scanned

SKILL.md

name:: release-notes
description:: >-
argument-hint:: [pr-number]
disable-model-invocation:: true

Release Notes

Generate release notes for a release PR. Brief, truth-based, no fabrication.

Configuration

On startup, use the Read tool to load ~/.claude/skills/release-notes/preferences.md.

Expected keys:

- ticket-prefix: <PREFIX>                    # Optional. Tracker key — e.g., ENG, PROJ, ABC, JIRA. Used to detect IDs as <PREFIX>-NNNN. If unset, falls back to the generic regex [A-Z]{2,5}-\d+ (any uppercase prefix + dash + digits).
- ticket-url-template: <url-with-{TICKET}>   # Optional. URL template with literal `{TICKET}` placeholder. Examples:
                                             #   Linear:        https://linear.app/myorg/issue/{TICKET}
                                             #   Jira:          https://myteam.atlassian.net/browse/{TICKET}
                                             #   GitHub Issues: https://github.com/myorg/myrepo/issues/{TICKET}
                                             #   Asana:         https://app.asana.com/0/{TICKET}
                                             #   Shortcut:      https://app.shortcut.com/myorg/story/{TICKET}
                                             #   Plane:         https://app.plane.so/myorg/projects/.../issues/{TICKET}
                                             # If unset, ticket IDs render as bare text without links.

Behavior when keys are missing:

No ticket-prefix → use the generic regex [A-Z]{2,5}-\d+. Works for most trackers.
No ticket-url-template → render bare ticket IDs (e.g., Closes ENG-1234.). Mention once at the end: "Set ticket-url-template in preferences.md to enable clickable ticket links."

Hard rules

Truth only. Every claim must be sourced from a merged PR's actual title/body. Never invent features, motivations, or impact statements that aren't in the source PRs.
Brief. Each PR section is 1–3 sentences max. Cut file enumerations, architecture diagrams, dead-code lists, "what changed" prose blocks. Mirror the source PR's ## Summary, not its full body.
Never git add -A and never push the release notes without showing them to the user first and getting explicit approval.
No drive-bys. Do not add commentary, suggestions, or "follow-ups" the source PRs didn't flag.

Steps

1. Resolve the release PR

If $ARGUMENTS is a number → that's the PR.
Else → gh pr list --base prod --state open --limit 5 --json number,title,headRefName and ask the user which one if multiple, or use the only open one.
Capture: number, title, baseRefName, headRefName, url.

2. List the squash-merged PRs in the release

gh pr view <release-pr> --json commits --jq '.commits[].messageHeadline'

Each squash-merged commit headline ends in (#NNN) — extract the PR numbers. If commits is sparse (squash-merge collapsed history), fall back to:

git log origin/<base>..origin/<head> --oneline

and grep (#\d+) from the headlines.

3. Fetch each child PR

For each PR number, in parallel:

gh pr view <num> --json title,body,number,url,labels

Extract from each:

title (use as section heading after stripping conventional-commit prefix if helpful)
## Summary paragraph (or first 1-3 sentences of the body if no Summary section)
Issue-tracker ticket IDs from anywhere in the body — match <TICKET-PREFIX>-NNNN (where TICKET-PREFIX comes from preferences, falling back to [A-Z]{2,5}-\d+). When ticket-url-template is set, substitute {TICKET} to build the link; otherwise render the bare ticket ID.
PR URL (for the #NNN link, GitHub auto-links)

4. Build the body

Template:

## What's in this release

**1. <Short topic — strip cc-prefix> — #<PR>**
<1–3 sentence summary, sourced from the PR body. User-visible framing.>

Closes [<TICKET>](<ticket-url-template with {TICKET} substituted>)<` · [<TICKET-2>](...)` if multiple>. If no template configured, render as `Closes <TICKET>.` (no link).

**2. <Short topic> — #<PR>**
<1–3 sentences.>

Closes [<TICKET>](...).

## How to test

- <One bullet per PR — pulled from that PR's test plan, simplified to the manual-verify path.>
- <...>

If — and only if — a source PR explicitly flags a follow-up that blocks prod (deploy ordering, flag flip, infra step), add:

## Follow-ups

- <The blocking item, verbatim from the source PR.>

Otherwise, skip the Follow-ups section. Do not invent follow-ups.

5. Title

Format: Release YYYY-MM-DD — <2–6 word theme>

The theme should name the 1–2 biggest user-visible changes (e.g., "PMI UI + migration cleanup"). Use today's date.

6. Show, then push

Print the full proposed title + body to the user. Then ask:

Push this to PR #<num>? (yes / edit / no)

yes → write the body to a temp file, then push via REST (works around the Projects-classic GraphQL deprecation that blocks gh pr edit on this org):
```
gh api -X PATCH "repos/<org>/<repo>/pulls/<num>" \
  -f title="<title>" \
  -F body=@/tmp/pr-<num>-body.md \
  --jq '"OK: " + .title + " — " + .html_url'
```
Try gh pr edit first if you prefer; if it errors with Projects (classic) is being deprecated, fall back to the REST call above. The edit does not land on the GraphQL failure — always verify via gh pr view <num> --json title --jq .title.
edit → ask what to change, regenerate, ask again
no → leave the PR alone, exit

7. Verify

After push, gh pr view <num> --json title,body --jq '.title' to confirm the edit landed. Report the URL.

Style reminders (drawn from user prefs)

Cut: file paths, line counts, "Adds/Removes/Migrates" tables, architecture diagrams, Figma node IDs, internal scaffolding details.
Keep: what changed for the user, what it closes, how to verify it on staging.
If a source PR is purely internal (refactor, test infra, dep bump) and has no user-visible surface, still list it but flag it as such in one sentence: "Internal — <one-liner>." No padding.
If two source PRs are part of the same chunked feature, group them under one numbered section with both #NNN links rather than splitting.

Related Skills

mostafa-drz/code/triage-board

development

VerifiedTrustedCommunity

--- name: triage-board description: >- Generates a structured triage artifact from the current conversation's findings — a self-contained Desktop folder with a JSON Schema, schema-conformant report.json, prose markdown, and a single-file HTML viewer. Viewer ships with MD / CSV / JSON download buttons in the header and a per-finding "Copy as Markdown" action that produces a GitHub/Linear/Notion-ready ticket block. Stateless — triage state lives in the user's ticket system, not in the

1SKILL.mdUpdated May 17, 2026

mostafa-drz/code/triage-board

mostafa-drz/audit-ui-e2e

development

VerifiedTrustedCommunity

Runs a beginner-mind end-to-end UI audit of any running app — local dev server, staging, production, or a specific URL. Drives Chrome through every interactive element on the target surface, collects structured findings (severity, category, where, symptom, impact, repro, triage), and hands the result off to `/triage-board` which produces the Desktop folder (schema + JSON + Markdown + single-file HTML viewer with MD/CSV/JSON exports and a per-finding Copy as Markdown button). Use when you want fresh-eyes verification of a feature, page, modal, flow, branch, or whole app — before shipping, before review, before a demo, or any time the UI deserves a careful poke.

1SKILL.mdUpdated May 17, 2026

mostafa-drz/audit-ui-e2e

mostafa-drz/emotional-recap

development

VerifiedTrustedCommunity

Reviews the user's past Claude Code conversations from a wellbeing perspective — sentiment, tone, emotional arc, recurring patterns — and generates a supportive, science-grounded report in both Markdown and HTML. Default lookback is 48 hours across all projects. Uses recognised emotion frameworks (Plutchik, Ekman, Russell's circumplex, Pennebaker linguistic markers) and cites the science behind every observation. Learns the user's baseline tone over time so future reports flag genuine shifts, not noise. Use when the user asks for an emotional/wellbeing recap, mood check, sentiment review, or wants to understand their own ups and downs across recent work sessions.

1SKILL.mdUpdated May 15, 2026

mostafa-drz/emotional-recap

mostafa-drz/code/workflow-advisor

development

VerifiedTrustedCommunity

--- name: workflow-advisor description: >- Analyzes recent Claude Code conversations and local Claude state (skills, settings, memory files, CLAUDE.md), researches the latest Claude Code features and best practices online, and suggests one workflow improvement at a time with reasoning and a concrete action item. Can save accepted suggestions to memory for tracking. Use when you want to discover underused Claude Code features, improve your development workflow, stay current with the lat

1SKILL.mdUpdated May 11, 2026

mostafa-drz/code/workflow-advisor

Download

For Claude Desktop. Download once, then upload the file in the app — no terminal needed.

Need help? View full Cowork setup guide →

Install manually

Choose your platform

# Clone the repo
git clone https://github.com/mostafa-drz/claude-skills.git

# Copy into Claude Code skills folder (global)
cp -r claude-skills/code/release-notes ~/.claude/skills/

Claude Code Skills — official skills path docs.

Repository

mostafa-drz/claude-skills

1 stars

Compatible with

Claude Code

OpenAI Codex CLI

ChatGPT