メニュー
Generates standardized Git commit messages following conventional commit rules. Invoke when user asks to write a commit message, create a commit, or needs help formatting a git commit.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/tangcent/easy-yapi --skill git-commitコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Help author EasyYapi rule files (.easyapi/ folder). Invoke when the user is editing an EasyYapi rule file or asks to add/modify EasyYapi rules (annotations, field rename, custom headers, etc.).
Guide how to write test cases in this project by first analyzing the target class to decide which test pattern, base class, and test utilities to use. Activate when user asks to write tests, add test coverage, or create test cases for any class.
Identifies and fixes bugs systematically. Invoke when user reports an error, test failure, or unexpected behavior that needs debugging and fixing.
SOC 職業分類に基づく
SKILL.md を表示中
| name | git-commit |
| description | Generates standardized Git commit messages following conventional commit rules. Invoke when user asks to write a commit message, create a commit, or needs help formatting a git commit. |
This skill generates clear, standardized Git commit messages that prioritize human readability and debugging efficiency.
Core Principle: The subject line answers "What does the user get?" and is written from the end user's perspective. The body explains "How did we implement it?" (Solution X) for developers.
Why the subject must be user-facing:
script/release.shbuildsCHANGELOG.mdfrom commit subjects only (git log --pretty=format:"%s"); the body is never published. Users read those subjects to decide whether to upgrade, so the subject must describe a user-visible change, not internal architecture. See §0 below.
Invoke this skill when:
script/release.sh builds CHANGELOG.md from commit subjects only — it runs git log --pretty=format:"%s" since the last vX.Y.Z tag and groups results by type. The body is never shown to users. This makes the subject the single user-facing artifact of a commit, so it must be written for a plugin user, not for a contributor.
| Commit type | Changelog section | Prefix handling in release.sh |
|---|---|---|
feat: / feat(scope): | Added | feat: (no scope) is stripped; feat(scope): is kept verbatim |
fix: / fix(scope): | Fixed | same stripping rule |
refactor: / refactor(scope): | Changed | same stripping rule |
anything else (chore, docs, style, enhance, perf, test, build, amend) | Improved | kept verbatim |
Because scoped subjects appear with the type(scope): prefix intact, feat(settings): apply toggles live renders as the bullet - feat(settings): apply toggles live. Make sure the whole string reads naturally as a user-facing bullet.
Write the subject as what the user will observe or be able to do after this change — not the internal mechanism.
| Developer-facing (internal) | User-facing (what the user gets) |
|---|---|
Unify feature lifecycle controls | allow turning off most features |
Introduce project feature registry | toggle features without restarting the IDE |
Replace startup-only scan controller | API scanning responds to settings without restart |
Serialize lifecycle with generation-scoped sessions | discard stale API results, keep last good snapshot |
Reserve internal terms (registry, lifecycle controller, dependency resolution, generation-scoped, extension point, serialized lifecycle) for the body, where developers read the "how".
Before writing the commit message, understand what changed:
# View staged changes
git diff --cached --stat
git diff --cached
# View recent commit history for style reference
git log --oneline -10
Identify the type of change from the mandatory type list (see Section 3).
Follow the Subject Line Rules (see Section 1).
Follow the Body Rules (see Section 2). When fixing a bug, the body MUST answer the four questions:
If a ticket/issue exists, append Fixes: #<issue> or Refs: #<issue> at the bottom.
Use a HEREDOC to preserve formatting:
git commit -m "$(cat <<'EOF'
<type>(<scope>): <subject>
<body>
Fixes: #<ticket>
EOF
)"
<type>(<scope>): <subject> or <type>!: <subject> for breaking changes, or release v?x.y.z for releasesAdd, Fix, Update, Remove). Never use past tense (e.g., Added, Fixed, Updated).fix: (bug fix), the subject MUST describe the problem (Y) (e.g., Fix login redirect loop on Safari). DO NOT put the implementation (X) in the subject.feat: (new feature), the subject MUST describe the feature itself (X) (e.g., Add dark mode toggle).CHANGELOG.md by script/release.sh, so it must describe what the plugin user observes or can now do — never internal architecture (e.g., allow turning off most features, not Unify feature lifecycle controls).You MUST prefix the subject with one of these exact types:
| Type | When to use | Auto-label |
|---|---|---|
| feat | A new feature for the user (X) | type: new feature |
| fix | A bug fix for the user (Y) | type: bug |
| enhance | Enhancement to existing features | type: enhancement |
| refactor | Code restructuring - no feature change and no bug fix | type: enhancement |
| perf | Performance improvement | type: enhancement |
| docs | Documentation changes only | type: doc |
| test | Adding or fixing tests | type: test |
| style | Code style (formatting, semicolons, etc.) - no logic change | type: chore |
| build | Build system changes (dependencies, build config) | type: chore |
| chore | Maintenance tasks (configs, tooling) | type: chore |
| amend | Small amendments or corrections | type: amend |
| release | Release version (format: release x.y.z) | release |
If a ticket/issue exists, MUST append one of these to the very bottom of the body:
Fixes: #<issue-number> (if it completely closes the issue)Refs: #<issue-number> (if it partially addresses it)Fix stuff, Update code, or WIP.Error was fixed → use Fix error).Updated → use Update).registry, lifecycle controller, generation-scoped, dependency resolution, extension point). The subject is published to user-facing release notes; describe user-visible behavior and put internals in the body.fix(payment): resolve checkout timeout during 3D Secure redirects
The checkout process was failing for users with banks requiring
3D Secure authentication due to a strict 5-second timeout.
Root cause: The API client did not account for external redirects,
which take 7-10 seconds to return to our callback URL.
Solution: Increased the global timeout to 30 seconds and added
exponential backoff retry logic specifically for the payment endpoint.
We also added a loading state to prevent duplicate submissions.
This change does not affect the regular non-3DS flow.
Fixes: #4421
feat(settings): allow turning off most features
Most plugin features can now be turned off from the Features tab. API
scanning and editor integration are now toggleable alongside the export
channels, field formats, and frameworks, all in one place.
Turning a feature off takes effect immediately without restarting the
IDE, and a manual rescan stays available even when continuous scanning
is turned off.
The subject above is what script/release.sh publishes verbatim into
CHANGELOG.md under Added, so it is phrased as a user-visible
benefit. The body (developer detail) is not published.
When generating the commit, strictly follow this structural template:
<type>(<scope>): <Imperative summary of Y if fix, or X if feat>
<Problem summary>
Root cause: <Explanation>
Solution: <Implementation details X>
Impact: <Side effects>
Fixes: #<ticket>
If you want to enforce this automatically, install commitlint and use this commitlint.config.js:
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'subject-case': [2, 'always', 'sentence-case'],
'subject-max-length': [2, 'always', 50],
'body-max-line-length': [2, 'always', 72],
'type-enum': [2, 'always', [
'feat', 'fix', 'enhance', 'refactor', 'perf', 'docs', 'test',
'style', 'build', 'chore', 'amend', 'release'
]]
}
};