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

ابدأ الآن

commit

النجوم٣

التفرعات٠

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

Read this skill before making commits

التثبيت

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

تشغيل في Manus

المصدر

Attamusc

Attamusc/dotfiles

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

تنزيل

تشغيل في Manus

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

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

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

SKILL.md

readonly

name	commit
description	Read this skill before making commits
license	From mitsuhiko/agent-stuff

Create a commit for the current changes using Conventional Commits format with a polished, highly descriptive message.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of the log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

VCS Detection

Detect which VCS to use before doing anything else:

Check if .jj/ exists in the repo root → use jj (even if .git/ also exists — colocated repos have both)
Otherwise check if .git/ exists → use git

Prefer jj whenever available.

Steps (jj)

Use these steps when the repo has .jj/:

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review jj st and jj diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run jj log --no-graph -r 'ancestors(@, 50)' -T 'description.first_line() ++ "\n"' to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Commit. Choose the path based on the body:
- Trivial single-line subject, no body (e.g. fix: typo):
  - All changes: jj commit -m "<subject>"
  - Specific files: jj commit -m "<subject>" <filesets>
- Multi-paragraph body, OR any body containing backticks / $(...) / em-dashes / non-ASCII punctuation — go via a tempfile to avoid shell injection (see the jujutsu skill's "Safe message passing" section for the full rationale):
  1. Use the agent's write tool to put the full commit message (subject line, blank line, body paragraphs) into /tmp/jj-commit-msg.txt. Do not use cat <<EOF — heredocs still expand backticks and $().
  2. Apply it:
    - All changes:
```
jj describe --stdin < /tmp/jj-commit-msg.txt
jj new
```
    - Specific files only (jj commit does not support --stdin, so use a placeholder then rewrite):
```
jj commit <filesets> -m "placeholder"
jj describe @- --stdin < /tmp/jj-commit-msg.txt
```
Avoid jj commit -m "<subject>" -m "<body>" for anything non-trivial — each -m is a separate shell-evaluated argument, and prose bodies have repeatedly triggered backtick execution and Unicode mangling.

jj mental model: There is no staging area. The working copy (@) IS a commit. jj commit describes the current working copy and creates a new empty @ on top. When file paths are given, only those files stay in the committed change — everything else moves to the new @.

Steps (git)

Use these steps when the repo only has .git/:

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).

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

نفس المستودع

write-like-me

Attamusc/dotfiles

Write messages, comments, PR reviews, Slack posts, and other prose in Sean's voice. Use when drafting anything that will be sent under Sean's name — code review comments, postmortem feedback, Slack messages, GitHub comments, coaching notes, design feedback, strategic takes. Triggers: 'write like me', 'in my voice', 'draft a comment for me', 'sound like me', 'sharpen this', 'this still sounds like AI'.

2026-07-093

code-review

Attamusc/dotfiles

Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".

2026-07-093

implement

Attamusc/dotfiles

Implement a piece of work based on a spec or set of tickets.

2026-07-093

wayfinder

Attamusc/dotfiles

Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets, and resolve them one at a time until the way to the destination is clear.

2026-07-093

triage

Attamusc/dotfiles

Move todos through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs. Maps to pi's built-in todo tool; see ../todo-tracker.md for the full tracker → tool mapping.

2026-07-093

to-spec

Attamusc/dotfiles

Turn the current conversation into a spec and publish it as a todo — no interview, just synthesis of what you've already discussed.

2026-07-093

name	commit
description	Read this skill before making commits
license	From mitsuhiko/agent-stuff

Create a commit for the current changes using Conventional Commits format with a polished, highly descriptive message.

Format

<type>(<scope>): <summary>

type REQUIRED. Use feat for new features, fix for bug fixes. Other common types: docs, refactor, chore, test, perf.
scope OPTIONAL. Short noun in parentheses for the affected area (e.g., api, parser, ui).
summary REQUIRED. Short, imperative, <= 72 chars, no trailing period.

Notes

Body is strongly encouraged — always include one unless the change is trivially obvious (e.g., fixing a typo). The body should explain what changed, why it changed, the approach taken, and any notable decisions. A reader of the log should understand the change without looking at the diff.
Do NOT include breaking-change markers or footers.
Do NOT add sign-offs (no Signed-off-by).
Only commit; do NOT push.
If it is unclear whether a file should be included, ask the user which files to commit.
Treat any caller-provided arguments as additional commit guidance. Common patterns:
- Freeform instructions should influence scope, summary, and body.
- File paths or globs should limit which files to commit. If files are specified, only stage/commit those unless the user explicitly asks otherwise.
- If arguments combine files and instructions, honor both.

VCS Detection

Detect which VCS to use before doing anything else:

Check if .jj/ exists in the repo root → use jj (even if .git/ also exists — colocated repos have both)
Otherwise check if .git/ exists → use git

Prefer jj whenever available.

Steps (jj)

Use these steps when the repo has .jj/:

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review jj st and jj diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run jj log --no-graph -r 'ancestors(@, 50)' -T 'description.first_line() ++ "\n"' to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Commit. Choose the path based on the body:
- Trivial single-line subject, no body (e.g. fix: typo):
  - All changes: jj commit -m "<subject>"
  - Specific files: jj commit -m "<subject>" <filesets>
- Multi-paragraph body, OR any body containing backticks / $(...) / em-dashes / non-ASCII punctuation — go via a tempfile to avoid shell injection (see the jujutsu skill's "Safe message passing" section for the full rationale):
  1. Use the agent's write tool to put the full commit message (subject line, blank line, body paragraphs) into /tmp/jj-commit-msg.txt. Do not use cat <<EOF — heredocs still expand backticks and $().
  2. Apply it:
    - All changes:
```
jj describe --stdin < /tmp/jj-commit-msg.txt
jj new
```
    - Specific files only (jj commit does not support --stdin, so use a placeholder then rewrite):
```
jj commit <filesets> -m "placeholder"
jj describe @- --stdin < /tmp/jj-commit-msg.txt
```
Avoid jj commit -m "<subject>" -m "<body>" for anything non-trivial — each -m is a separate shell-evaluated argument, and prose bodies have repeatedly triggered backtick execution and Unicode mangling.

jj mental model: There is no staging area. The working copy (@) IS a commit. jj commit describes the current working copy and creates a new empty @ on top. When file paths are given, only those files stay in the committed change — everything else moves to the new @.

Steps (git)

Use these steps when the repo only has .git/:

Infer from the prompt if the user provided specific file paths/globs and/or additional instructions.
Review git status and git diff to understand the current changes (limit to argument-specified files if provided).
(Optional) Run git log -n 50 --pretty=format:%s to see commonly used scopes.
If there are ambiguous extra files, ask the user for clarification before committing.
Stage only the intended files (all changes if no files specified).
Run git commit -m "<subject>" (and -m "<body>" if needed).