Menú
Use when writing a git commit message or PR title — format it as a Conventional Commit (type(scope): summary) with a body that explains why, matching this repo's history.
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
Use when writing or reviewing OpenAidy addon UI code (app/index.html, app/index.js) that calls sdk.ui.* — covers component mounting semantics and composed usage patterns beyond the one-line reference in addon_create's tool description.
Use when calling external REST APIs or querying databases on the user's behalf through available tools or MCP servers — read-only by default, parametrized queries, and confirmation before any write.
Use when reading, extracting from, or generating real-world document files — PDFs, spreadsheets (CSV/Excel/Sheets), and slide decks — with available tools; preserve the source and verify the output.
Use when working with calendars — checking availability, finding meeting times, and creating or updating events through an available calendar integration — with careful timezone handling and confirmation before inviting others.
Use when posting to chat or email on the user's behalf — Slack, Discord, Telegram, or mail — through an available integration. Get the recipient and content right, and confirm before anything goes out.
Use when a task needs a real browser — navigating sites, filling and submitting forms, clicking through flows, extracting page data, or taking screenshots — driving whatever browser tool or MCP server is available.
| name | Conventional Commits |
| description | Use when writing a git commit message or PR title — format it as a Conventional Commit (type(scope): summary) with a body that explains why, matching this repo's history. |
Commit messages are read far more often than they're written. A consistent, structured message makes history skimmable and explains why a change exists — which the diff can't.
type(scope): short summary in the imperative
Optional body: what changed and, more importantly, WHY. Wrap at ~72
columns. Reference the problem this solves, not a restatement of the diff.
Optional footer: BREAKING CHANGE: ..., refs #123, Co-Authored-By: ...
mcp, skills, cli, server.
Optional but encouraged; match scopes already used in git log.feat new feature · fix bug fix · refactor behavior-preserving
change · test tests only · docs docs only · chore tooling/deps ·
perf performance · ci pipeline. Full list in
references/cheatsheet.md.
The summary says what; the body says why. Good bodies answer:
Skip the body only for truly self-evident one-liners.
git log --oneline and reuse existing scopes and
phrasing rather than inventing new conventions.--no-verify) or signing unless explicitly asked.Add a BREAKING CHANGE: footer (or ! after the type/scope, e.g.
feat(api)!:) describing what breaks and how to migrate.