تشغيل أي مهارة في Manus بنقرة واحدة

conventional-commits

النجوم١

التفرعات١

آخر تحديث١٠ يونيو ٢٠٢٦ في ١٠:٢٥

Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

jnMetaCode

jnMetaCode/skillet

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

name	conventional-commits
description	Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.
version	1.0.0
license	MIT
keywords	["git","commits","conventional-commits","changelog","workflow"]

conventional-commits

Write the message from the diff, not from the conversation. The reader is a stranger running git log in two years.

Procedure

Read what is actually staged: git diff --cached --stat then the diff itself.
Classify the change — pick ONE primary type:
- feat new user-visible capability · fix corrects wrong behavior
- refactor no behavior change · perf faster, same behavior
- docs · test · build · ci · chore (only when nothing else fits)
Scope = the subsystem a reader would filter by: feat(parser): …. Omit if the repo doesn't use scopes (check git log --oneline -20 and match style).
Subject line: imperative, lowercase, no period, ≤ 72 chars, and it must state the effect, not the activity — "fix: reject expired tokens" not "fix: update token check".
Body (when the why isn't obvious): 1–3 sentences on why the change was needed and any non-obvious consequence. Wrap at 72. Never narrate the diff.
Breaking change → footer BREAKING CHANGE: <what breaks and the migration>, and add ! after the type: feat(api)!: ….

Anti-patterns to reject

One commit doing two unrelated things — split it (git add -p).
"update", "misc fixes", "address comments" — say what changed.
Restating the conversation ("as discussed…") — the log has no conversation.
Explaining that the change is correct — that belongs in the PR, not the log.

Example

fix(ingest): treat mtime regressions as edits, not new files

Restored backups can move mtime backwards; we indexed those as fresh
documents, duplicating every chunk. Key on inode+path instead.

المزيد من هذا المستودع

نفس المستودع

self-evolve

jnMetaCode/skillet

Make the agent improve with every task — review the run, distill lessons into durable memory, and reinforce what worked. Use at the end of any non-trivial task, or when the user asks the agent to "learn from this".

2026-06-101

incident-postmortem

jnMetaCode/skillet

Write a blameless, actionable incident postmortem from the raw facts. Use after an outage/incident, or when asked to write up "what happened" for the team.

2026-06-101

pr-description

jnMetaCode/skillet

Write a reviewer-first pull-request description from the actual branch diff. Use when opening a PR or asked to write/improve a PR description.

2026-06-101

systematic-debugging

jnMetaCode/skillet

Root-cause a bug with a hypothesis-driven loop instead of shotgun edits. Use when a bug isn't obvious after the first look, or when asked to "find out why" something fails.

2026-06-101

test-writing

jnMetaCode/skillet

Write tests that catch real regressions — behavior-focused, minimal mocking, edge cases chosen from the code's actual branches. Use when adding tests for new code or backfilling tests for a fix.

2026-06-101

changelog

jnMetaCode/skillet

Generate or update a CHANGELOG.md in Keep a Changelog format from real git history. Use when cutting a release, tagging a version, or asked "what changed since…".

2026-06-101

name	conventional-commits
description	Write precise Conventional Commits messages from the actual staged diff. Use whenever committing code or asked to write/fix a commit message.
version	1.0.0
license	MIT
keywords	["git","commits","conventional-commits","changelog","workflow"]

conventional-commits

Write the message from the diff, not from the conversation. The reader is a stranger running git log in two years.

Procedure

Read what is actually staged: git diff --cached --stat then the diff itself.
Classify the change — pick ONE primary type:
- feat new user-visible capability · fix corrects wrong behavior
- refactor no behavior change · perf faster, same behavior
- docs · test · build · ci · chore (only when nothing else fits)
Scope = the subsystem a reader would filter by: feat(parser): …. Omit if the repo doesn't use scopes (check git log --oneline -20 and match style).
Subject line: imperative, lowercase, no period, ≤ 72 chars, and it must state the effect, not the activity — "fix: reject expired tokens" not "fix: update token check".
Body (when the why isn't obvious): 1–3 sentences on why the change was needed and any non-obvious consequence. Wrap at 72. Never narrate the diff.
Breaking change → footer BREAKING CHANGE: <what breaks and the migration>, and add ! after the type: feat(api)!: ….

Anti-patterns to reject

One commit doing two unrelated things — split it (git add -p).
"update", "misc fixes", "address comments" — say what changed.
Restating the conversation ("as discussed…") — the log has no conversation.
Explaining that the change is correct — that belongs in the PR, not the log.

Example

fix(ingest): treat mtime regressions as edits, not new files

Restored backups can move mtime backwards; we indexed those as fresh
documents, duplicating every chunk. Key on inode+path instead.