メニュー
Project conventions for branch names and commit messages. Use when creating a branch for a new task or committing staged changes.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/werf/trdl --skill git-conventionsコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Code review of a pull request, branch, or diff. Covers technical, product, and risk perspectives in one pass and produces a consolidated report. Use when asked to review a PR, branch, or code changes.
Verify a test actually falsifies the behavior it claims to cover, via real mutation. Use right after writing or changing a test, when auditing an existing suite's real coverage, or as a step inside a code review.
Adversarial verification layer for reviewing agent-generated or otherwise untrusted implementations. Use when the author of a diff, patch, commit, or test suite is an agent, when a change touches tests or verification infrastructure, or when invoked as /agent-code-review. Adds test falsifiability checks and check-gaming detection on top of ordinary review; does not replace it.
SOC 職業分類に基づく
SKILL.md を表示中
| name | git-conventions |
| description | Project conventions for branch names and commit messages. Use when creating a branch for a new task or committing staged changes. |
Types and scopes are defined in CONTRIBUTING.md#conventions — that file is the source of truth, read it before composing either.
<type>/<scope>/<short-description>
<short-description>: kebab-case, concise.<type>(<scope>): <subject>
<body>
git diff --cached.fix(server, release): ….feat/fix: the observed outcome, never the mechanism. CHANGELOG.md is generated from these subjects verbatim, so the reader is an end user who has never seen the code: name the symptom that goes away or what becomes possible, and leave function names, internal identifiers and the how to the body. make service script executable regardless of umask describes the patch; stop builds failing under a custom umask describes what the user hit. For refactor/test/chore the reader is a developer and the mechanism is the right subject.main is the trunk and release-v* branches are managed by release-please: a commit landed on one has to be moved by hand afterwards and its message amended along with it, and until someone asks for a PR nothing reveals it is on the wrong branch.git fetch and compare your base against origin/<base> BEFORE writing code, not at push time. A moved base can have refactored the very file you are about to edit, and the whole diff then has to be re-ported by hand during the rebase.git status for unrelated untracked files before staging. This worktree carries local working files (.dev/, scratch notes, orchestrator state), so prefer explicit paths over git add -A — a blanket add sweeps them in, and untracking later costs an extra commit. An orchestrator or helper commit command stages broadly — inspect git status BEFORE invoking it, not after.git branch --show-current) — a stale local main or someone else's WIP branch is easy to miss.main or a release-please release-v* branch directly — branch from the current origin/main and open a PR.--force-with-lease is also rejected as stale info when there is no remote-tracking ref for the branch (e.g. after pushing by URL) — that is a missing lease baseline, not a diverged history, and the fix is --force-with-lease=<ref>:<sha>.Output ONLY the branch name or the commit message, with no additional text, quotes, or formatting.