القائمة
Create clean, repo-aware commits from real diffs with focused inspection, selective staging, and minimal tool calls.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Bootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate `.gitlab/issue-triage/config.json` and `.gitlab/CODEOWNERS`. Use when setting up triage automation on a new or existing repository for the first time.
Compare a merge request's implementation against spec context in spec_context.md and feed any material mismatches into review.json. Use during MR review when approved or repository spec context is available.
Create or update a GitLab merge request from a pushed branch after local review, base-branch sync, validation, and issue linking.
Create a product spec from a GitLab issue in this repository by applying the local shared `write-product-spec` workflow with issue context and output paths. Use when an issue should be turned into a product spec artifact stored under `specs/issue-<issue-number>/product.md` and the agent should prepare file changes only, without creating commits or merge requests itself.
Create a technical spec from a GitLab issue in this repository by applying the local shared `write-tech-spec` workflow with issue context and output paths. Use when an issue should be turned into a tech spec artifact stored under `specs/issue-<issue-number>/tech.md` and the agent should prepare file changes only, without creating commits or merge requests itself.
Repo-specific dedupe guidance . Only the categories declared overridable by the core dedupe-issue skill may be specialized here.
| name | git-commit |
| description | Create clean, repo-aware commits from real diffs with focused inspection, selective staging, and minimal tool calls. |
Commit current repo changes atomically, with accurate messages and no unrelated files.
Use one tool call for the common inspection:
git status --short
git diff --stat
git diff
git diff --cached --stat
git diff --cached
If staged output is empty, ignore it. Check repo message conventions only when unknown: prefer existing context, then obvious files such as .gitmessage, CONTRIBUTING.md, or commit config. Use recent history only when style is still unclear.
Split only for real separate concerns: behavior vs refactor, dependency churn vs code, generated output without source, formatting-only churn, or unrelated docs/tests. Keep directly related tests with the fix/feature.
Stage only intended paths:
git add <specific-files>
Use git add -p only when file-level staging would mix unrelated changes.
If the user asked to commit a clear current change, proceed after inspection. Ask first only when included files, boundaries, risky content, or issue semantics are ambiguous. Keep questions short: included files, excluded files, proposed message, and the ambiguity.
Default format unless repo conventions say otherwise:
type(scope): summary
Types: feat, fix, refactor, perf, docs, test, build, ci, chore. Use a scope when obvious. Avoid update, changes, misc, and wip.
Issue links:
<type>/<desc>-123, issue-123, gl-123, or #123.Fixes #123 only for explicit closing intent or a clearly complete narrow issue.Refs #123 for partial, preparatory, docs-only, cleanup-only, or ambiguous work.Use normal Git so hooks run:
git commit -m "<subject>"
If hooks fail, stop and report. Do not use --no-verify, push, rewrite history, or force anything unless explicitly asked.
Report the final commit hash and whether hooks/checks ran.