القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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.