メニュー
Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Split one oversized Markdown reference document into a progressive-disclosure tree - a curated index page plus one file per top-level section - without altering a byte of prose. Use when a single doc has grown too large to read whole (a multi-hundred-line architecture spec, PRD, or reference), when asked to split, shard, or break up a doc into sections, when converting a monolith-plus-stale-digest pair into an index-plus-sections layout, or when a digest has drifted from the doc it summarizes. Covers header-tiling extraction, concat-vs-original byte verification, per-link relative-depth repair with a grep sweep, deriving the index fresh from each section's current content in the repo's index style, deleting a now-redundant digest, and reconciling context-file pointers. Do NOT use for authoring new documentation content (that is make-docs), for choosing a Diataxis type, for splitting source code, or for editing prose during the move.
Convert a technical specification, tracker reference, or feature request into a rigorous, atomic, dependency-ordered implementation plan the coder agent executes step-by-step. Use whenever the output is a Markdown plan file under `.plans/`, or when asked to plan, break down work, sequence implementation phases, turn a spec into actionable tasks, write a roadmap, decompose a feature into phases, or convert a `Spec-*.md` into a `Plan-*.md` artifact. Defines phase structure, output-style rules (WHAT not HOW, signatures only, no language-tagged code fences, symbol references over file paths), step anatomy (atomic, file-explicit, verify-gated), per-phase constraint checks, the philosophy-checklist self-gate, and a validation script. Do NOT use for writing the specification itself, writing implementation code, writing tests, code review, or evaluating an existing plan.
Write technical specifications from feature requests, prompts, or tracker references. Use when asked to specify, architect, design, write a spec, define requirements, create a technical specification, analyze a feature request, or produce a specification document. Also use when given a tracker reference (Jira, GitHub issue, Linear, Asana, etc.) and a specification is the expected output. Do NOT use for code review, implementation, implementation planning, or reviewing existing specs. Produces structured specification documents the implementer can build from without further clarification.
Use when writing Jira issue descriptions, comments, or work logs. Also use when converting Markdown to Jira wiki markup, when the user says 'format for Jira', 'Jira markup', 'wiki notation', or asks to create, update, or validate Jira ticket content. Handles bug report and feature request templates. Do NOT use for Jira API operations, JQL queries, or workflow transitions.
Create, edit, search, transition, close, and triage Jira tickets via the Atlassian MCP. Use when asked to file a bug, request a feature, create a task, log a defect, search the backlog, triage findings into the tracker, edit ticket fields, transition status, or manage Jira work items. Also use when the user says 'create a Jira issue', 'file a bug', 'open a ticket', 'add to backlog', 'search Jira', 'close ticket', 'move to Done', or names any Jira issue key (e.g. 'PROJ-123'). Handles type discovery, parent linking, label assignment, duplicate detection via JQL, status transitions, and issue-link creation. Defers all field-content formatting to the `jira-syntax` skill. Do NOT use for pull requests, changelog entries, non-Jira trackers (GitHub Issues, Linear, GitLab), or managing local TODO.md.
Explain technical concepts, mechanisms, and systems to a technically fluent reader who is unfamiliar with the specific topic. Use when asked to explain how something works, walk through an algorithm or protocol, write a deep-dive or onboarding article, answer 'what is X', 'why does X behave this way', 'how does X work', 'break down X', or when synthesising findings from research into a written explanation. Builds understanding progressively along the reader's 'aha path' - opens with the why, bridges to adjacent knowledge, introduces one concept at a time, traces mechanics through worked examples, closes with tradeoffs and a runnable experiment. Do NOT use for end-user documentation aimed at non-technical audiences, marketing copy, code review, reference-style API documentation, or commit messages.
| name | git-commit |
| description | Use when asked to commit, save, or persist changes to Git. Handles atomic commits, branch safety, Conventional Commits format, and project style matching. Do NOT use for pushing, creating PRs, or branch management beyond safety checks. |
| metadata | {"author":"Serghei Iakovlev","version":"1.1","category":"vcs"} |
git status --short
git diff
git diff --cached
Each commit = one logical change. Split unrelated changes into separate commits.
| Situation | Commits |
|---|---|
| New service + its tests | 1 commit |
| New feature + unrelated config fix | 2 commits |
| Multiple files for one feature | 1 commit |
git branch --show-current
Protected branches: main, master, develop, release/*, hotfix/*.
STOP if on a protected branch. Do not commit. Do not proceed to Step 3. Instead:
<branch> - it is a protected branch."git checkout -b <type>/<kebab-description>If on a feature branch: proceed.
Format: <type>/<kebab-case-description>
| Type | Use Case | Example |
|---|---|---|
feat | New feature | feat/bill-reminders |
fix | Bug fix | fix/null-amount-validation |
refactor | Code restructuring | refactor/extract-payment-service |
chore | Maintenance tasks | chore/update-dependencies |
docs | Documentation | docs/api-reference |
test | Test additions | test/payment-service-coverage |
git log --format="%s" -20
Identify vocabulary, detail level, scope patterns. Mimic the project's phrasing while following Conventional Commits format.
See references/commit-format.md for type table, rules, and anti-patterns.
git add <files>
git commit -m "<type>[scope]: <description>"
For multi-line messages:
git commit -m "<subject>" -m "<body>"
Subject line: imperative mood, under 72 chars, no period, English only. Body (if needed): wrap at 72 chars, explain what and why. The 72-char body wrap is a commit-message convention - git log and most CLI tooling render bodies as plain text in a narrow column. It does not generalize to PR descriptions (where GitHub renders soft line breaks as <br> and wrapping creates visible artificial breaks), CHANGELOG prose (which follows that file's own readability conventions, not this one), or other Markdown rendered as HTML.
Do not reference docs/architecture.md, docs/decisions/, section numbers, or ADR numbers in commit messages. Those belong in specs and plans, not in the git history.
git log --oneline -1
git show --stat HEAD
Report: commit hash, files changed, insertions/deletions.
| Error | Fix |
|---|---|
| "nothing to commit" | Check git status, verify files have changes |
| Pre-commit hook fails | Read the error, fix the issue, create a NEW commit (do not amend) |
| Wrong files committed | git reset --soft HEAD~1, re-stage correctly, commit again |
If the user also asked to create a PR, invoke the creating-pr skill after committing. Do not hand-roll gh pr create - the skill has a required template.