Menu
Load this skill before creating, drafting, modifying, or submitting PR on GitHub
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Find and remove AI slop — the generic, machine-default visual and copy tics of vibe-coded products — from a web project. Use when the user asks to "kill AI slop", "de-slop", "remove the AI look", "make this not look AI-generated", or clean up a landing page / UI / docs that feels templated. Detects and fixes the catalogue of tells: indigo→violet gradients, gradient-clip headlines, the default semantic palette, one-hue status boxes, atmospheric gradients, serif-italic emphasis, highlighted keywords, AI copywriting voice ("not just X — it's Y"), emoji everywhere, glowing status dots, colored-left-border callouts, pastel icon tiles, glassmorphism, over-rounding, oversized shadows, borders that die at corners, badge & pill spam, AI-drawn SVG icons, kickers over every heading, flat type hierarchies, invented stat rows (10k+ / 99.9% / 24/7), 01/02/03 section markers, cards nested in cards, the default Inter/Space Grotesk look, and more. Works on HTML/CSS, React/Vue/Svelte/Astro, Tailwind, PHP, and Markdown copy.
High-fidelity HTML design and prototype creation. Use this skill whenever the user asks to design, prototype, mock up, or build visual artifacts in HTML — including slide decks, interactive prototypes, landing pages, UI mockups, animations, or any visual design work. Also use when the user mentions Figma, design systems, UI kits, wireframes, presentations, or wants to explore visual design directions. Even if they just say "make it look good" or "design a screen for X", this skill applies.
You are required to load this before writing code. Load this skill for code-related task. Do not use this skill for simple reading code or analyze tasks unless it's related to personal codestyle.
Finds root cause before applying fixes for errors, crashes, regressions, failing tests, broken behavior, and screenshot-reported defects. Use when users report in any language errors, crashes, broken behavior, regressions, failing tests, screenshot evidence, or something that used to work and now fails. Not for code review or new features.
Turns rough ideas into approved, decision-complete plans with validated structure before coding. Use when users ask in any language for planning, architecture, design direction, feasibility, value judgment, or whether a feature is worth doing before implementation. Not for bug fixes or small edits.
Void skill for app development and CLI operations. Use this skill to route user requests to the appropriate bundled Void docs.
| name | creating-pr |
| description | Load this skill before creating, drafting, modifying, or submitting PR on GitHub |
For most projects, maintainers use squash and merge. We should follow Conventional Commits for PR title.
<type>[optional scope]: <description>
The type of PR is decided on the code behavior changes. For example, even if a PR is linked to a Bug issue, but it actually adds the missing feature to close it, its type still should be feat.
We generally use a lowercase starting imperative sentence as the <description> part.
For example
feat(cli): add global packages support
If no special requirement provided, submit draft PR.
Always check Allow edits by maintainers.
PR description should always follow simple and human-readable principles.
Avoid excessive headings and checklists when simple paragraphs are enough. Try to use short paragraphs to express your idea and implementation details. Try using sentences like This PR adds ..., The current behavior ..., Follows ...'s behavior, It means that, It doesn't mean that. Avoid too long paragraphs as well.
If this PR is linked to an issue, put a Close #xyz on the top of the description.
For bug fixes without an issue, you should describe the bug first. And then describe this PR's changes.
For projects with .github/workflows, we do not need to describe Validation part because CI will help verify your implementation.
In order to make the pr description simple and easy to read, we should use words and sentences as simple as possible. Some well-known project specifications and everyday-chores may also be omitted. (For example, a snap test added in a fix pr, we do not need to mention this addition).
Add a line 🤖 Generated with [The Agent Tool's Name] in the bottom of the description.
A good PR description should like this, comments should be removed in practice. Paragraphs inside CORE DESCRIPTION part can be repeated or skipped as needed.
Close #1 <!-- If there is a linked issue -->
<!-- CORE DESCRIPTION START -->
The current ... <!-- Describe a bug or current behavior if no issue linked-->
This PR adds ... <!-- Describe behavior changes if there is -->
This PR includes ... <!-- Describe implement details if it is worth telling like refactor, module movements,especially for chore/refactor PR -->
No behavior changes. <!-- If this is a chore/refactor PR -->
<!-- CORE DESCRIPTION END -->
🤖 Generated with [Agent Name] <!-- Replace [Agent Name] with the tool you're using, e.g. Codex / Claude Code. -->
After you set up your PR, you may be required to change some details, you can create new commits or just leave the changes unstaged, but do not modify the existing commits.