Menú
Stages and commits changes following conventional commits. Use when the user asks to commit, stage files, or write a commit message.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Design engineering principles for making interfaces feel polished. Use when building UI components, reviewing frontend code, implementing animations, hover states, shadows, borders, typography, micro-interactions, enter/exit animations, or any visual detail work. Triggers on UI polish, design details, "make it feel better", "feels off", stagger animations, border radius, optical alignment, font smoothing, tabular numbers, image outlines, box shadows.
Use when finishing a feature, fixing a bug, before committing React code, or when the user wants to improve code quality or clean up a codebase. Checks for score regression. Covers lint, accessibility, bundle size, architecture diagnostics.
Scaffolds and fills the docs page for an existing Ora UI component, or restructures an existing docs page to follow current conventions. Use when the user asks to document, add docs for, create, or update the docs page for a UI component — e.g. "document the accordion", "add docs for dialog", "update the button-group docs".
Guides building Ora UI components with enforced requirements gathering. Use when user asks to build or create a new component, or rework an existing shadcn import to follow Ora conventions — e.g. "build a select", "create a tooltip", "convert the dialog to Ora conventions". Not needed for small changes to components that already follow conventions.
Scaffolds and fills the docs page for an existing Ora UI component, or restructures an existing docs page to follow current conventions. Use when the user asks to document, add docs for, create, or update the docs page for a UI component — e.g. "document the accordion", "add docs for dialog", "update the button-group docs".
Creates a GitHub issue with structured context. Use when the user asks to file a bug, log an issue, or create an enhancement request.
| name | git-commits |
| description | Stages and commits changes following conventional commits. Use when the user asks to commit, stage files, or write a commit message. |
| Type | When to use |
|---|---|
feat | New feature or capability |
fix | Bug fix |
chore | Build, tooling, deps, config — no production code change |
refactor | Code change that neither fixes a bug nor adds a feature |
style | Formatting, whitespace — no logic change |
test | Adding or updating tests |
docs | Documentation only |
perf | Performance improvement |
ci | CI/CD pipeline changes |
Scope — only add (scope) when the change is directly tied to a
specific, named context (e.g. a module, package, or subsystem). Omit it
otherwise.
Atomic commits — each commit should represent one logical unit of work. A unit of work is a cohesive change that accomplishes a single purpose — adding a feature layer, setting up a subsystem, fixing one bug. Multiple files often belong together; unrelated changes in the same file should be split. Ask: "Does this commit do one thing well?"
Grouping — group related files into one commit when they serve the
same purpose. Prefer fewer, well-named commits over many granular ones.
Examples:
Body / description — only add a body when:
Keep the body short and factual. No Co-authorship lines unless the user
explicitly asks.
[optional scope]:
[optional body]
git status and git diff --stat to understand what changed.