agentleFS
Sign inStart free
mmtaeemmtaee/ocserv-dashboard/.agents/skills/release-pr-notes/SKILL.md

release-pr-notes

Skill275 starsChanged 35 days agoMITView on GitHub

Create or update Ocserv Dashboard RELEASE.md and PULL_NOTE.md from a Git range, verified issue evidence, and the established v5 release-note format.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill when the task asks to create, update, or review RELEASE.md or PULL_NOTE.md for this repository.

    line 8
  2. Distinctive:

    Use commit diffs and test output for implementation and validation claims.

    line 14
  3. Distinctive:

    When issue references are requested, verify their current titles and labels from GitHub.

    line 15
  4. Distinctive:

    Follow the public v5.0 release structure when applicable:

    line 19
  5. Distinctive:

    Write for operators and users.

    line 29
  6. Distinctive:

    Write for reviewers. Include a suggested PR title, a suggested merge-commit message, a compact change summary, fixed-issue references, …

    line 33
  7. Distinctive:

    Keep the note scoped to the selected Git range.

    line 37
  8. Very specific:

    Keep RELEASE.md and PULL_NOTE.md in the requested ignore files when they are local-only artifacts.

    line 38
  9. Distinctive:

    Run git diff --check after edits.

    line 39
  10. Distinctive:

    Do not stage, commit, push, create a GitHub release, or modify application code unless explicitly requested.

    line 40

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Release and PR notes

Use this skill when the task asks to create, update, or review RELEASE.md or PULL_NOTE.md for this repository. These are local drafting artifacts and may be intentionally ignored by Git.

Gather evidence first

  • For a release note, identify the requested base tag and inspect <tag>..HEAD. If no tag is specified, ask or state the range used.
  • For a pull note, inspect the requested branch/range and current working-tree changes.
  • Use commit diffs and test output for implementation and validation claims. Do not infer that an issue is fixed from its label, title, or TODO entry.
  • When issue references are requested, verify their current titles and labels from GitHub. Separate fixed issues from related or unresolved references.

RELEASE.md

Follow the public v5.0 release structure when applicable:

  1. # Ocserv Dashboard <release label>
  2. ## Highlights
  3. ## Docker images when image publishing changes
  4. ## Security and compatibility when applicable
  5. ## Documentation when applicable
  6. ## Fixed issues only for issues directly resolved in the range
  7. ## Validation

Write for operators and users. State expected image locations and tag behavior, but never say an image was published unless a registry or completed workflow verifies it. Preserve exact Git tag examples and clearly distinguish stable releases from prereleases.

PULL_NOTE.md

Write for reviewers. Include a suggested PR title, a suggested merge-commit message, a compact change summary, fixed-issue references, validation, and upgrade or deployment notes when relevant. Keep related backlog issue references separate from fixes.

Completion checks

  • Keep the note scoped to the selected Git range.
  • Keep RELEASE.md and PULL_NOTE.md in the requested ignore files when they are local-only artifacts.
  • Run git diff --check after edits.
  • Do not stage, commit, push, create a GitHub release, or modify application code unless explicitly requested.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free