agentsclimarketplace
Sign in

Dynamo pr description

Skill DynamoDS/skills/skills/dynamo-pr-description

Generate PR descriptions for DynamoDS repositories that align with the team template. Use this skill whenever writing a pull request description, cleaning up a PR body, or generating a review-ready summary from a diff in a DynamoDS repo. Also use when the user says "write a PR", "PR description", or "prep this for review."From its SKILL.md

Install
npx -y skills add DynamoDS/skills --skill dynamo-pr-description

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, 647 tokens by cl100k_base, as published. Nobody here has run it

Dynamo PR Description

When to use

  • Writing a PR description from a diff in a DynamoDS repository.
  • Cleaning up or reformatting an existing PR body to match the team template.
  • Producing review-ready summaries quickly.

When not to use

  • Jira ticket triage -- use the dynamo-jira-ticket skill instead.

Inputs expected

A git diff, commit log, or description of the changes. Optionally a Jira key.

Output format

A complete PR body matching the repository's PR template (.github/PULL_REQUEST_TEMPLATE.md), ready to paste.

Workflow

  1. Read the diff (staged changes, commit history, or user-provided summary).
  2. Identify the why -- what problem does this solve?
  3. Fill the repository's .github/PULL_REQUEST_TEMPLATE.md from the diff and context.
  4. For each declaration checkbox, only check it if you've verified it's true.
  5. Write the release note from the user's perspective (one sentence, or N/A).
  6. Leave (FILL ME IN) placeholders for anything you can't determine from the diff.

Rules

  • Mirror section names and heading order from the template exactly.
  • Keep facts verifiable from the diff. Do not invent Jira keys, reviewers, or test results.
  • Call out breaking changes or migration steps explicitly in Purpose.
  • If the PR changes public API, mention the affected types and whether the API surface file was updated.
  • Release Notes is a mandatory section -- always include it, even if just N/A.
  • If the user provides explicit checklist bullets or section content, treat those as source of truth and override the defaults below.

PR Title

Format: DYN-1234: concise change summary (include Jira key when known).

Template

Read .github/PULL_REQUEST_TEMPLATE.md in the target repository for the exact template structure. Follow its sections in order.

Content guidance within those sections:

  • In Purpose, include a concise "Key changes:" bullet list when it helps readability.
  • For Release Notes, write one concise sentence from the user's perspective, or N/A when not user-facing.

Example: PR adding a new feature

### Purpose

DYN-5678: Add `String.Interpolate` node for string formatting with placeholders.

Key changes:
- New `StringInterpolate` method in the string utilities library
- Added to API surface file
- NUnit tests covering the new method
- Help files: `.dyn`, `.md`, `.jpg` added

### Declarations

- [x] Is documented according to the standards
- [x] The level of testing this PR includes is appropriate
- [x] Changes to the API follow Semantic Versioning and are documented in the API Changes document.

### Release Notes

Added String.Interpolate node for formatting strings with named placeholders.

### Reviewers

(FILL ME IN) Reviewer 1

### FYIs

(FILL ME IN, Optional)

Related Skills: dynamo-jira-ticket

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in 647 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

  • Use third-person for skill descriptionsin 54 of 1951, across 35 files
  • Start descriptions with Use whenin 43 of 1951, across 29 files
  • Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
  • Use active voicein 40 of 1951, across 36 files
  • Map file responsibilities before defining tasksin 36 of 1951, across 29 files
  • Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
  • Ask one question at a timein 35 of 1951
  • Offer execution options after saving the planin 33 of 1951, across 24 files
  • Include complete code in every stepin 33 of 1951, across 27 files
  • Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
  • Announce the skill usage at the startin 30 of 1951
  • Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

  • Read the diff or commit history
  • Mirror section names and heading order exactly
  • Write release notes from the user perspective
  • Use placeholders for undetermined information
  • Format title with Jira key and summary
  • Include breaking changes in the purpose section

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.