メニュー
Commit changes and open pull requests. Follow the project's conventions for scope, formatting, and writing style. Always load this skill before committing or opening a pull request.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/ethereum/consensus-specs --skill commitコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Run tests and generate reference tests. All testing goes through `make test`, never `pytest` directly. Always load this skill before running tests.
Write specifications. Always load this skill before writing to `specs`.
Review changes. Check that they are correct, consistent with the rest of the specifications, and compliant with the project's conventions. Always load this skill before reviewing changes.
SOC 職業分類に基づく
SKILL.md を表示中
| name | commit |
| description | Commit changes and open pull requests. Follow the project's conventions for scope, formatting, and writing style. Always load this skill before committing or opening a pull request. |
| compatibility | Requires make, uv, git |
A pull request should have a single, well-defined objective. If a change accomplishes multiple unrelated things, split it into separate pull requests. For a large change with one objective, break it into multiple commits when possible. Each commit should adhere to the preparation steps below.
Check that the branch is up to date with ethereum/consensus-specs@master;
rebase if it is not. Run the linter (make lint) and ensure it passes. If the
linter makes modifications, stage these fixes. Ensure relevant tests pass if the
specifications or testing framework changed.
The subject line (and PR title) must be written in the imperative mood. It must not have component prefixes like the "conventional commit" style. It must be less than or equal to 68 characters. Use sentence case, not title case. Code (functions, classes, etc) must be wrapped in backticks. There must be no terminal punctuation.
The body (and PR description) should describe what and why, not how. Wrap the
body at 72 characters. Do not use section headers. A single paragraph is ideal,
but multiple paragraphs are okay if necessary. Keep things simple and try to be
concise. Mention any relevant information, concerns, or related PRs/issues. Do
not mention running the linter or tests; CI will show this. Do not include a
Co-Authored-By trailer.
