Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Cristhianzl/claude-skills-czl --skill writing-pull-requestsgit clone --depth 1 https://github.com/Cristhianzl/claude-skills-czlWrote 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/cristhianzl/claude-skills-czl/writing-pull-requests)<a href="https://agentmods.dev/skills/cristhianzl/claude-skills-czl/writing-pull-requests"><img src="https://agentmods.dev/badge/skills/cristhianzl/claude-skills-czl/writing-pull-requests/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/cristhianzl/claude-skills-czl/writing-pull-requests"><img src="https://agentmods.dev/badge/skills/cristhianzl/claude-skills-czl/writing-pull-requests.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.00066 | $0.01207 |
| Opus 5 | $0.00033 | $0.00603 |
| Sonnet 5 | $0.00013 | $0.00241 |
| Haiku 4.5 | $0.00007 | $0.00121 |
Grade A, and why
writing-pull-requests 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 12d ago.
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.
How it starts
The opening of the file, as written. The whole thing — 93 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing Pull Requests
Produce a PR title, a commit message, and a PR description from the current diff, using a conventional-commit format. Output is always printed in chat, never written to a file.
When to apply
Apply when the user says any of: "create a PR", "PR title", "PR description", "commit message", "title for the commit", "write the PR".
Skip / push back when:
- The diff is empty or untracked-only — ask the user what to compare against.
- The diff bundles multiple unrelated changes — propose splitting first; a PR whose title needs "and" is a smell.
- The user already pasted a title/description — don't rewrite unless asked.
Read first (always)
Before doing anything else, list learnings/ and read every file whose name looks relevant to the current PR. Project-specific scopes, type aliases, vocabulary, or hard constraints live there and override the defaults in this SKILL.md. If a learning conflicts with this file, the learning wins — mention it to the user so they can refine it.
If learnings/ contains only README.md, proceed with the defaults below.
Workflow
-
Inspect the diff →
git status+git diff --stat <base>..HEAD(or staged with--cached). Identify files added/modified/deleted and the dominant area. → verify: you can name the affected module(s) and the dominant intent (feat/fix/refactor/etc.). -
Pick the type from the table below. If two types tie, the change is mixed — flag it and ask whether to split the PR. → verify: one type, defensible from the diff alone.
-
Pick the scope from folder names, file paths, or the imports that changed most. Single token, lowercase. Optional — omit if the change is repo-wide. → verify: scope appears in the diff paths.
-
Write the summary in imperative mood, ≤72 chars total title length, no trailing punctuation, first letter capitalized after the colon. → verify:
<type>(<scope>): <Summary>≤72 chars. -
Write the description: one-sentence Objective, ≤5 bullet Changes, optional Notes for edge cases. Whole description ≤150 words. → verify: each bullet starts with a verb; no implementation noise that a reviewer can read from the diff.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago First seen · 93 lines · 66 tokens per session scan A d6b1be1c1ab9
writing-pull-requests is a skill published in the GitHub repository Cristhianzl/claude-skills-czl (5 stars, last pushed 2d ago), licensed MIT. It adds 66 tokens to every session and 1,207 once invoked, about $0.0003 per session on Opus 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-08-31.
Other skills, from other repositories
spec-finish
Post-implementation completion workflow for Spec-backed Plans. Use after spec-implement completes to validate, review, create stacked commits, and open a PR via code-pull-request. Triggers only with an active Spec-backed Plan after spec-implement completes, including when the user says "finish", "done", or "complete"…
pre-publish-review
Nuclear-grade 12-agent pre-publish release gate. Runs /get-unpublished-changes to detect all changes since last npm release, spawns up to 10 ultrabrain agents for deep per-change analysis, invokes /review-work (orchestrator manual QA plus one gate reviewer) for holistic review, and 1 oracle for overall release…
work-with-pr
Full PR lifecycle in a fresh task-owned git worktree: implement via the ulw-loop skill with mandatory evidence-bound manual QA → reviewer-readable English PR → verification loop (CI + Cubic, where Cubic is skipped only when its quota is exhausted) → merge by default → worktree cleanup. Decomposes one task into the…
pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
validate-changes
Evaluate staged changes using LLM-as-a-Judge before committing.