Open SWE is an open-source software factory that gives coding tasks to an asynchronous agent, which investigates repositories, changes code, validates the results, and delivers pull requests. Engineering teams use it to automate code changes, reviews, CI follow-up, and related repository work from dashboards and connected tools.
Borrowing it
Nothing to install: this file belongs to langchain-ai/open-swe. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/langchain-ai/open-swe/main/.agents/skills/writing-pr-body-title-description/SKILL.mdgit clone --depth 1 https://github.com/langchain-ai/open-sweWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/langchain-ai/open-swe/writing-pr-body-title-description)<a href="https://agentmods.dev/skills/langchain-ai/open-swe/writing-pr-body-title-description"><img src="https://agentmods.dev/badge/skills/langchain-ai/open-swe/writing-pr-body-title-description/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/langchain-ai/open-swe/writing-pr-body-title-description"><img src="https://agentmods.dev/badge/skills/langchain-ai/open-swe/writing-pr-body-title-description.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00018 | $0.00275 |
| Opus 5.5 | $0.00007 | $0.00110 |
| Sonnet 5.5 | $0.00004 | $0.00055 |
| Haiku 4.5 | $0.00002 | $0.00028 |
Grade A, and why
writing-pr-body-title-description scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday Changed · +11 lines 2b590ba3657d
- 2d ago Changed 9b803d792c1c
- 5d ago Changed c8530ef0abd7
- 12d ago Changed d30146b983b1
- 1mo ago First seen · 7 lines · 18 tokens per session scan A da6d97b0ea5a
writing-pr-body-title-description is a skill published in the GitHub repository langchain-ai/open-swe (11,133 stars, last pushed today), licensed MIT. It adds 18 tokens to every session and 275 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-23.
Other skills, from other repositories
pr-screenshot-comparison
Create clear, polished before-and-after screenshots from the actual running product for a GitHub pull request. Use when a UI change needs visual proof: capture matching product states, crop to the relevant UI, stitch and caption one comparison image, attach it natively to the PR, and keep the image out of the…
pr-description
Write or update a GitHub PR description a teammate understands in one quick read: clear before/after behavior, useful visual evidence, and plain sentences grounded in the diff and real verification. Use when opening a PR or editing its description.
code-review
This skill should be used when the user asks for a code review of a change — a pull request, merge request, branch, commit range, working-tree change, or pasted diff — covering correctness, security, performance, structure, and repository-specific rules. Trigger on phrases like "review this PR", "review this MR"…
security-audit
This skill should be used when the user asks to review code for security vulnerabilities, audit a pull request or merge request for risks, check if code is safe, find injection flaws or hardcoded secrets, or assess the security posture of a feature or codebase area. Use this skill even when the user doesn't say…
pr-self-review
Draft explanatory author-context comments for the user's own PR or local diff. Use for self-review or reviewer context, not a formal review submission. Posting requires approval.
swe-review
Review an SWE brief, research report, spec, delivery plan, execution state, implementation diff, branch, or pull request. Use for fresh-context, evidence-backed findings before the human chooses the next action.