本文へ移動
cccskills
無料GitHub で公開日本語紹介

cw-land

検証済みのCodewhaleの変更をmainへ反映する作業を支援します。担当ファイルだけのコミット、プッシュ前の確認、貢献者の記録、PRのマージ条件を扱います。

原文原文の説明を見る

Use when turning verified Codewhale work into commits on main and pushing them, or merging a contributor PR: staging only your paths, the pre-push drift checks, preserving contributor credit, and honoring the gate artifact before merging.

インストール方法を見る

こんなときに便利

  • 共有環境で検証済み変更を反映したいとき
  • 貢献者のPRの競合解消と作者情報の記録
  • PRのマージ前に承認条件を確認したいとき

日本語での紹介

できること

検証済みのCodewhaleの変更をmainへコミット・プッシュし、貢献者のPR(変更の取り込み依頼)を反映する手順を支援します。担当ファイルだけをコミット対象にし、変更内容に応じたプッシュ前チェックを実施します。貢献者の作者情報やCo-authored-by:を残し、実行した確認とコミットの識別子を報告します。

こんなときに便利

複数のエージェントが同じ作業場所を共有する開発や、mainの更新で競合したPRの取り込みに向いています。取り込み条件がある場合は、判定資料のPASSとレビューの指摘状況を確認します。

使い方の例

  • 「検証済みの変更を担当ファイルだけコミットして、確認後にプッシュして」
  • 「貢献者のPRの競合を解消し、作者情報を残して取り込んで」

注意点

Codewhale固有のAGENTS.md、チェック用スクリプト、貢献者管理ファイルを前提とします。正規の作業場所のmainで進める運用です。取り込み条件が曖昧な場合はマージしません。タグ作成・リリース・公開・デプロイには明示的な許可が必要です。

この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。

含まれるファイル(1)

  • SKILL.md6.9 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

cw-land

Verified work still has to land without stepping on other writers, losing contributor credit, or merging past a gate that has not actually passed. This stage is about the boundary between "it works" and "it is in main" — and about which of those steps you are allowed to take.

Stage 5 of the loop: cw-orient → cw-slice → cw-gates → cw-dogfood → land → cw-handoff.

When to use

  • The change is verified and needs to become a commit on main.
  • You are landing someone else's PR, harvesting a contributor's work, or resolving a conflict caused by main moving.
  • You are about to merge something behind a required gate.

Workflow

  1. Land on the canonical checkout's main. AGENTS.md owns this: no maintainer PR branches, worktrees, nested clones or integration lanes. Several agents share the checkout, so partition by file, check git status before staging, stage only your paths (never git add -A), and retry a commit that fails on index.lock. Push verified main directly; hosted CI runs there. PRs are for contributors.

  2. Commit narrow and build-green. One coherent change per commit; the tree builds at every commit. Put the real verification in the message — actual pass/fail counts, not "tests pass".

    Before every push, run the cheap drift checks that have turned a green main red most often. They take seconds:

    cargo fmt --all -- --check
    sh scripts/sync-changelog.sh --check        # after any CHANGELOG.md edit
    bash scripts/release/check-versions.sh
    python3 scripts/check-runtime-contract-budget.py
    

    Add the one that matches what you touched: check-tui-locale-parity.py and check-tui-product-vocabulary.sh (locale strings), check-dead-code-budget.py (#[allow(dead_code)]), check-blocking-calls-budget.py (async code), check-readme-translations.py and check-readme-locales.sh (READMEs), node web/scripts/derive-facts.mjs && node web/scripts/check-facts.mjs (public facts). Put a new CHANGELOG entry at the top of [Unreleased]. Open contributor PRs append at its end, and an entry of ours there conflicts with every one of them.

  3. Preserve credit mechanically, not just politely. Commit authorship and Co-authored-by: trailers must use the contributor's own GitHub-linked address — GitHub reads neither .github/AUTHOR_MAP nor .mailmap for the contribution graph; those are project conventions on top. When a contributor's work lands as our commit, it carries both:

    Harvested from PR #N by @handle
    
    Co-authored-by: Name <github-linked-email>
    

    That trailer is what lets auto-close-harvested.yml close their PR with credit. Canonical human identities live in .github/AUTHOR_MAP.

    Whether a bot or agent also appears in a trailer no longer matters — the CI check that policed trailer identities was removed because it rejected ordinary agent commits. Give humans their credit; don't spend time scrubbing tool trailers.

  4. Landing someone else's work: their time is more expensive than ours.

    • Never make a contributor rebase around our churn. If their PR conflicts only because main moved, a maintainer resolves it.
    • Read their diff against the merge base first, so you know exactly what they added, then re-apply that — rather than hand-merging two large sides and hoping:
      git diff $(git merge-base main <pr-head>)..<pr-head>
      
    • Conflicts that split mid-function do not resolve by keeping both sides. Git's markers can land inside a body, so a both-sides resolution produces unbalanced braces that look plausible and do not compile. Default: take one side whole, then re-insert the other side's additions at their original anchor; when the conflict doesn't fit that pattern, resolve it however is correct and let the compiler judge.
    • Resolve on their branch without creating a local branch. Build the merge commit with git merge-tree --write-tree origin/main <pr-head> and git commit-tree <tree> -p <pr-head> -p origin/main, then push it with git push <fork-url> "${sha}:refs/heads/<their-branch>". In zsh, write ${sha}, not $sha:refs, because :r is a history modifier. maintainerCanModify does not guarantee that the push is accepted. When the fork refuses it, ask on the PR. Harvesting is the last resort.
    • Check the contribution gate before assuming a PR is stalled. An unlisted author's workflow runs sit at action_required and never start, so the PR looks abandoned when nobody has actually looked at it. Approve the runs, then fix the cause: add them to .github/APPROVED_CONTRIBUTORS (all:username), or comment /lgtm (PR scope) or /lgtmi (issue scope).
  5. Verify mergeability against the real head. A PR that is clean against main can still conflict with a release branch:

    git merge-tree $(git merge-base <base> <pr-head>) <base> <pr-head>
    
  6. Merging under a gate. AGENTS.md ("Merging under a gate") owns this: the artifact must literally say PASS, the review thread outranks the check rollup, and ambiguity blocks the merge — never the reverse. Before you merge, list the open PRs whose base is the PR's source branch (gh pr list --base <branch>) and retarget them first. Otherwise they close when that branch goes away.

Red flags / don't

  • Don't tag, create a release, publish, or deploy without explicit authorization. Pushing verified main is allowed; it is none of those.
  • Don't rewrite published history, retag a release, or force-push a shared ref.
  • Don't commit AGENTS.md / CLAUDE.md operator controls that live outside the product repository into a public repo.
  • Don't stage another writer's dirty files to get a clean commit.
  • Don't merge on a green rollup alone when a review thread has open findings.
  • Don't harvest or close from a PR title or label — review the code, tests, comments, and checks.
  • Don't add another legacy call site for convenience once a replacement architecture is adopted. Declared migrations are one-way.
  • Don't leave new enforcement live: keep it dry-run/advisory unless approved.

Output

  • Commit SHAs, the paths committed, the drift checks run, and the resulting origin/main SHA.
  • The credit trailers applied and to whom.
  • The gate artifact's literal verdict at merge time, if a gate applies.
  • Exactly which public actions you took, and which you deliberately did not.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

batch

無料日本語概要

並行して進められる大きな目標を、範囲の明確な作業に分割するスキル。既存のエージェントや作業ツリーの仕組みで実行し、結果の統合と検証まで進めます。

  • 大きな目標を並行作業に分けたいとき
  • 複数エージェントの作業調整
  • 作業ツリーを分けて進めたいとき
codewhale-hq/Codewhale4.1万2026年10月19日 更新

best-of-n

無料日本語概要

設計や実装、説明、デバッグの複数案を独立に作り、共通の評価基準で比較します。コード案は作業場所を分けて検証し、採用候補と判断の根拠を提示するスキルです。

  • 複数の設計方針を比較したいとき
  • 同じ課題の実装案を評価したいとき
  • 説明やデバッグの方針を比較したいとき
codewhale-hq/Codewhale4.1万2026年10月19日 更新

codew-release-qa-sweep

無料日本語概要

Codewhaleのリリース前に、テスト・ビルド・バージョン整合性を順に点検し、端末画面の手動確認項目と実施結果を整理して、完了判断の根拠を残します。

  • 実際のリリースブランチで自動検査
  • リリース先へのPR取り込み可否の確認
  • 端末の応答性と入力操作の手動確認
codewhale-hq/Codewhale4.1万2026年10月19日 更新

computer-use

無料日本語概要

登録済みのコンピューターで、デスクトップアプリや独立したブラウザーを操作します。画面の状態を読み取り、入力やクリックの結果を確認しながら作業を進めるスキルです。

  • デスクトップアプリの画面で入力
  • 独立したブラウザーで作業したいとき
  • 作業に必要な画面撮影や録画
codewhale-hq/Codewhale4.1万2026年10月19日 更新

contributor-onboarding

無料日本語概要

Codewhaleの開発参加時に、手元のブランチと同期状況、ビルド、CIと同じ検証を確認するスキル。ローカルの履歴と変更履歴から更新内容も提示します。

  • 初めて開発に参加するとき
  • 作業中の変更と同期状況の確認
  • ビルドとCIの検証を実行したいとき
codewhale-hq/Codewhale4.1万2026年10月19日 更新

cw-dogfood

無料日本語概要

Codewhaleの変更を実製品で確かめるため、ビルド元の識別情報を付けた実行ファイルの作成・インストールから、実際の端末での動作確認と記録まで進めるスキル。

  • 端末UIの変更を実製品で確認したいとき
  • ローカルビルドを導入・確認したいとき
  • モデルの接続先や承認動作の確認
codewhale-hq/Codewhale4.1万2026年10月19日 更新

codewhale-hq のスキルをすべて見る

このスキルの問題を報告する