القائمة
Write Conventional Commits messages (v1.0.0) — type(scope): subject format for changelogs and semver. Use when drafting commit messages, PR titles, or release notes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Renders markdown to self-contained HTML with a custom dark stylesheet and opens in browser. Use when previewing markdown documents, generating styled HTML from README or report files.
Inform the user what is happening — skip passive lookups
Manage version control with Jujutsu (jj) — no staging area, immediate changes, smart rebasing. Use when navigating history, squashing, or pushing to Git remotes.
Programmatic hunk selection for Jujutsu — split, commit, or squash specific hunks without interactive prompts. Use when making partial commits or selective squashes.
Gather facts from the web using evidence-first approach with mandatory citations. Use when researching topics, answering factual questions, or any task requiring web-sourced evidence.
Model minimum-move problems as BFS over a state space. Use when solving bucket pouring puzzles, sliding tiles, or any problem asking for the shortest sequence of moves to reach a goal.
| name | conventional-commits |
| topic | Conventional Commits |
| description | Write Conventional Commits messages (v1.0.0) — type(scope): subject format for changelogs and semver. Use when drafting commit messages, PR titles, or release notes. |
| token_cost | 150 |
| keywords | ["commit","message","conventional","changelog","version","release","git"] |
| related | ["jj-core","sem"] |
Produce consistent commit messages that parse into changelogs and drive semantic versioning.
type(scope): description
[optional body]
[optional footers]
Rules: header on one line, scope is always included, separate sections with blank lines. Add ! before : for breaking changes (e.g., feat(api)!: remove v1).
User-facing changes:
feat: new user-visible behavior — new CLI flags, UI components, API endpointsfix: corrected behavior — fixes crashes, handles edge cases, corrects outputMaintenance:
refactor: structure change without behavior change — renaming, extracting utilitiesperf: performance improvement — faster algorithms, reduced allocationschore: general maintenance — dead code removal, tooling updatesstyle: formatting only — whitespace, semicolons, no logic changestest: test-only changes — .test.ts, .spec.ts filesbuild: build system — package.json, Cargo.toml, bundler configci: CI/CD pipelines — GitHub Actions, deployment scriptsdocs: documentation files only — .md, .txt. Code comments use the type matching the actual code change.Reverts:
revert: undo a previous commit — revert: <original-message>When unsure: new user behavior → feat, corrected behavior → fix, otherwise → chore or a more specific maintenance type.
Use imperative mood, be specific, avoid generic words like "stuff" or "changes".
✅ feat(auth): add passwordless login
✅ fix(api): handle empty pagination cursor
❌ docs(agent): add behavioral guidelines and core principles (too vague)
✅ docs(agent): add rules for dead code removal, build verification, security (specific)
Mark in the header with !:
feat(api)!: remove deprecated v1 endpoints
Or add a BREAKING CHANGE: footer when you need an explanation:
feat(api): remove deprecated v1 endpoints
BREAKING CHANGE: /v1/* endpoints are removed; migrate to /v2/*.
fix → patchfeat → minor! or BREAKING CHANGE:) → majorBREAKING CHANGE: footer for breaking changesCollect what changed, the scope/module, whether it's user-facing, and any issue IDs. Then produce a conventional header with optional body and footers.