What does this skill do, and when should you use it?
writing-pr is one of 10 internal skills bundled in the tester-army/e2e repository at .dev/skills/writing-pr/SKILL.md, marked `internal: true`. It defines how PRs to that repo are written: Conventional Commits titles that survive squash-merge, bodies built from bullets, mermaid diagrams, code references, and before/after tables, plus a required `## Verified` section documenting local testing. It also lists what to leave out (CI-reported checks, intermediate history, unrequested checklists) and which AI-writing tells to strip via an unslop pass. It is a documentation-style skill tied to the repo's contribution process, with no scripts.
- Produces Conventional Commits-style PR titles matching the repo's squash-merge convention, including
!for breaking changes - Structures PR bodies as bullets + mermaid diagrams for flow/state + fenced code blocks + file:line references and GitHub permalinks
- Generates before/after tables for visual changes,
| main | this branch |bug/fix tables for fixes, and benchmark tables with the target branch as baseline - Enforces a
## Verifiedsection whose first line states whether it ran locally and why not when it didn't, with media uploaded viagh 2.99+ --attach - Runs an unslop voice check to strip filler like 'This PR introduces...', 'comprehensive', 'ensures'
- Excludes intermediate refactoring history, line-by-line diff restatement, and unprompted checklists
- A contributor fixing a bug in tester-army/e2e who must show the bug and fix side by side with local verification evidence
- A developer landing an architectural change to runner phases or engine hooks that needs a mermaid flow diagram and before/after architecture
- An author of a performance PR who needs a benchmark table with main as the baseline and the PR as candidate
- A docs-only or CI-only contributor who must honestly declare 'Ran it locally: no' with a reason
- Anyone whose AI-drafted PR description needs the marketing tone stripped before posting
- Contributors outside the e2e repo: the rules bind to that repo's squash-merge flow, verify skill, and path conventions, so adopting it elsewhere requires rewriting
- Users with no way to run or verify changes locally: every PR must carry real verification evidence
- Anyone wanting generic PR copy generation: this is a strict editorial standard, not a copywriter
How do you install this skill?
- The skill is repo-internal (internal: true) with conventions specific to this repository (squash-merge, suiteVersion, the verify skill); direct transplant to other repos will not fit.
- Referenced ../verify/SKILL.md and the unslop skill file are absent from this evidence; confirm those paths exist before use.
- The recommended gh --attach behavior requires gh 2.99+; verify on older environments.
- English-only guidance, no Chinese-language support.
- Static review only; no verification workflow was executed.
- Shell / CLI
- Network access
- Local filesystem
GitHub CLI (gh 2.99+ for media uploads)
The source gives no command to install this skill separately. It is an internal skill inside the tester-army/e2e repo, obtained by cloning:
git clone https://github.com/tester-army/e2eThe README only documents installing the e2e testing framework itself (npx e2e init); it provides no steps for installing the writing-pr skill into Claude Code or other Agent Skills clients, so none are invented here.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Draft the PR title and body per writing-pr for this runner prepare hook fix, including a Verified section
- Rewrite this PR description to drop filler like 'comprehensive' and 'ensures' and use bullets with evidence
- The change alters the replay flow; draw a mermaid diagram for the PR body
- I ran the fix locally; organize the bug-vs-fix before/after table and the gh --attach command
The skill triggers when writing or editing a PR title or body (its description states this directly). The flow: title in Conventional Commits form; a short bullet body with evidence (diagrams, code refs, comparison tables); then a ## Verified section. Upload media with:
gh pr edit <pr> --body-file body.md --attach ./main.png --attach ./branch.png --attach ./video.webmReference images in the body as ; gh uploads attachments and rewrites those paths. Do not write video paths in the body: attached videos are appended at the end as players. Run the unslop pass on the final text before posting.
What are this skill's strengths and limitations?
- Rules are concrete and actionable, with reusable Markdown templates for Verified, benchmarks, and mermaid diagrams
- Targeted checklist for AI-writing tells (filler phrases, bold label lists, em dashes, padding bullets to three)
- Clear boundary between what must be written (Verified evidence) and what to leave out
- Marked internal and deeply tied to the e2e repo's squash-merge flow, verify skill, and path conventions; cross-repo reuse requires rewriting
- No scripts or automation; everything is prose standards followed manually or by an agent
- The mandatory Verified section and local-run requirement burden contributors who cannot verify locally
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| writing-pr: PR Title & Body Standards this page | 58 · Recommended | ★ 8.7k | 1d ago | Apache-2.0 |
| Ship a PR (e2e repo PR delivery workflow) | 59 · Recommended | ★ 8.7k | 1d ago | Apache-2.0 |
| CodeRabbit Code Review | 57 · Use with care | ★ 188 | 4d ago | MIT |
| RenderCV PR Reviewer | 55 · Use with care | ★ 18k | 6mo ago | MIT |
| Codex Pull Request Editor ✓ OpenAI · Official | 50 · Use with care | ★ 128k | 3d ago | Apache-2.0 |
The source names no competitor, but it references two companion skills in the same repo: verify (local verification) and unslop (voice check); the three work as a set.
How did FollowSkills review this skill?
Pure writing guidance: no command execution, no permission requests, no external side effects or sensitive-data handling; the only external interaction is the gh CLI media-attachment workflow, transparently described. Deducted for unverified publisher attribution and no discussion of the information boundary when pasting content into PRs.
Instructions are self-consistent and well structured (title/body/Verified/templates), templates are directly reusable, and the gh --attach usage is concrete. Deducted because the referenced ../verify/SKILL.md and unslop skill files are not in the evidence, so path existence is unconfirmed; as prose-only guidance there is no abnormal-input handling to assess.
Trigger condition is explicit (when writing or editing a PR title or body), the description matches content, and false-trigger risk is low. Deducted for internal: true scoping with repository-specific conventions (squash-merge, suiteVersion, the verify skill) that do not transfer to other repos; no Chinese-language support; depends on GitHub/gh and image uploads with no declared non-fit boundary.
Well-layered documentation: principles first, details after, with templates, anti-patterns (Leave out, Voice) and frontmatter present. Deducted for the skill file's lack of versioning or changelog, no in-file maintenance ownership, and an out-of-tree unslop reference path (../../../.claude/skills/) absent from the evidence, a hidden assumption.
Concrete, actionable format and content rules for the PR-writing task, offering real marginal value over generic guidance. Deducted because static review cannot confirm outputs are directly usable, and some rules (gh 2.99+ --attach behavior, squash-merge title convention) rest on external facts not reproduced in this evidence.
Core claims (gh --attach path rewriting, repo merge conventions) have no independent corroboration within the provided files; other repository material (CI workflows, SECURITY.md) is only weakly related to the skill's own claims. Static-review constraints cap this score.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →