How do I install the Lerd Open Pr skill?

Run npx skillmds@latest add lerd-env/lerd-open-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Lerd Open Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Lerd Open Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Lerd Open Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Lerd Open Pr?

lerd-env (@lerd-env) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Lerd Open Pr by lerd-env — Agent Skill

Name: Lerd Open Pr
Author: lerd-env

Lerd Open Pr

Draft and open a pull request the lerd way — issue-first, correct issue linking, human prose, none of the banned sections. Use when asked to open, prepare, or draft a PR for lerd. Never creates anything on GitHub without explicit per-action approval.

lerd-env 5894dd8 1.9 KB Updated Sep 17, 2026

File contents

Open a lerd PR

Every write to GitHub (create/edit/close/reopen/merge/comment on an issue or PR) needs explicit approval each time. Draft the text, show it, and wait. Do not run gh pr create or any state-changing gh command until the human says go.

Before the PR

An issue should already exist for the work, framed as future work. If it doesn't, draft one and ask before creating it.
Run /lerd-preflight — the PR is not ready until the local gate is green.
Confirm the branch is off main, not main itself, and staged by explicit path (never git add -A). git status first.

PR body — write it as a human would

Prose paragraphs, single-line (no column wrapping), explaining what changed and why. Then the issue link:

Feature PR → Closes #N (auto-closes on merge).
Bug-report issue → Refs #N (stays open until the stable release ships).
Security issue → Closes #N (closes once the fix merges to main).

Never include

A Test plan section.
A Verified / Tested / Manual testing section or trailer.
A checklist of any kind (- [ ] / - [x], "Release checklist"…).
A "Notes for reviewers" section — we own the project, there is no external reviewer.
file:line citations, em dashes, Co-Authored-By, or "Generated with…" footers.
Prose about tests, TDD, or coverage; and don't mention incidental cleanup.

PR and issue comments

Casual plain prose. No markdown, no bullets, no hyphens — commas instead. Don't open with boilerplate like "Pulled it down and put it on my install." Vary it.

After pushing

Return immediately. Don't sit polling CI; failures get flagged by the human.

---name: lerd-open-prdescription: Draft and open a pull request the lerd way — issue-first, correct issue linking, human prose, none of the banned sections. Use when asked to open, prepare, or draft a PR for lerd. Never creates anything on GitHub without explicit per-action approval.---# Open a lerd PREvery write to GitHub (create/edit/close/reopen/merge/comment on an issue or PR)needs explicit approval **each time**. Draft the text, show it, and wait. Do notrun `gh pr create` or any state-changing `gh` command until the human says go.## Before the PR1. **An issue should already exist** for the work, framed as future work. If it doesn't, draft one and ask before creating it.2. Run `/lerd-preflight` — the PR is not ready until the local gate is green.3. Confirm the branch is off `main`, not `main` itself, and staged by explicit path (never `git add -A`). `git status` first.## PR body — write it as a human wouldProse paragraphs, single-line (no column wrapping), explaining what changed andwhy. Then the issue link:- Feature PR → `Closes #N` (auto-closes on merge).- Bug-report issue → `Refs #N` (stays open until the stable release ships).- Security issue → `Closes #N` (closes once the fix merges to main).## Never include- A Test plan section.- A Verified / Tested / Manual testing section or trailer.- A checklist of any kind (`- [ ]` / `- [x]`, "Release checklist"…).- A "Notes for reviewers" section — we own the project, there is no external reviewer.- `file:line` citations, em dashes, `Co-Authored-By`, or "Generated with…" footers.- Prose about tests, TDD, or coverage; and don't mention incidental cleanup.## PR and issue commentsCasual plain prose. No markdown, no bullets, no hyphens — commas instead. Don'topen with boilerplate like "Pulled it down and put it on my install." Vary it.## After pushingReturn immediately. Don't sit polling CI; failures get flagged by the human.

Frequently asked questions