writing-pr-body-title-description

$npx mdskill add langchain-ai/open-swe/writing-pr-body-title-description

Keep PR titles and bodies concise; do not write essays. Focus on bullet points, Mermaid diagrams, and useful code samples or snippets. Do not include test-running or validation sections. This repository is public. Write for a reader who can't see internal repositories, Slack or Notion: say in plain words what a linked private PR or discussion does instead of relying on the link, and explain why Open SWE does something itself rather than only that it does. Do not narrate intermediate PR details; describe the final squash-merge outcome. For visual changes, include a before/after table with uploaded images or videos. Default screenshots to dark mode; request or capture both light and dark mode only when the change affects theme-specific behavior or appearance, or the user explicitly requests both. In GitHub PR descriptions, always embed screenshots using explicit HTML `<img>` tags with an explicit `width` (for example, `width="640"`), including inside before/after table cells; never use Markdown image syntax. Preserve exact signed image URLs and follow the shared screenshot guidance for published-body, rendered-image, and anonymous GET verification. For benchmarks, always include a before/after table. For truly impressive changes, use a technical-blog style while remaining focused.

SKILL.md

.github/skills/writing-pr-body-title-descriptionView on GitHub ↗
---
name: "writing-pr-body-title-description"
description: "Use when writing or editing a pull request title or body."
---

Keep PR titles and bodies concise; do not write essays.
Focus on bullet points, Mermaid diagrams, and useful code samples or snippets.
Do not include test-running or validation sections.
This repository is public.
Write for a reader who can't see internal repositories, Slack or Notion: say in plain words what a linked private PR or discussion does instead of relying on the link, and explain why Open SWE does something itself rather than only that it does.
Do not narrate intermediate PR details; describe the final squash-merge outcome.
For visual changes, include a before/after table with uploaded images or videos.
Default screenshots to dark mode; request or capture both light and dark mode only when the change affects theme-specific behavior or appearance, or the user explicitly requests both.
In GitHub PR descriptions, always embed screenshots using explicit HTML `<img>` tags with an explicit `width` (for example, `width="640"`), including inside before/after table cells; never use Markdown image syntax.
Preserve exact signed image URLs and follow the shared screenshot guidance for published-body, rendered-image, and anonymous GET verification.
For benchmarks, always include a before/after table.
For truly impressive changes, use a technical-blog style while remaining focused.

More from langchain-ai/open-swe

SkillDescription
baby-sitMonitor a GitHub pull request until CI is green, diagnose failures, and rerun only evidence-backed flaky GitHub Actions jobs.
dashboard-previewDrive this checkout's dashboard (`ui/`) against the shared preview deployment's real threads, with no local backend. Use to verify a UI change in a browser, count the requests a page makes, or compare a page's behaviour before and after a change.
html-artifactsAuthor the HTML for a plan artifact, dashboard iframe, or Slack attachment — structure, design plan, available runtime, theming, and craft. Read this before writing HTML for publish_artifact, output_iframe, or slack_attach_html.
linear-ticketsCreate or update high-quality Linear tickets while preserving the originating report, diagnostic links, attachments, and reporter/requester attribution. Read this whenever someone asks to create, recreate, or update a Linear issue.
local-gh-devRun the Open SWE dashboard locally against real GitHub data, signed in with the `gh` CLI instead of a per-machine GitHub App. Use when asked to run the app locally, test a dashboard change against real PRs, reproduce something a screenshot shows, or when local login fails with "GITHUB_APP_CLIENT_ID not configured".
workspacesHow an Open SWE workspace's sandbox image works and how to change it — create one, edit or fork an existing one, start from scratch, what setup_script and update_script are for, why a nightly refresh failed, where the build logs are, and how to read a rebuild in progress. Read this whenever someone asks about workspaces, snapshots, sandbox images, or a refresh, whether or not this is an admin thread.