mcpField
S
ship-check

ship-check

github.com/tahajemmaliテスト・品質085 回インストール29 週間前に更新
リポジトリ

ship-check について

コードやドキュメントの変更後に、エージェントの最終確認を案内するオーケストレーションスキルです。リポジトリ内のレビューとドキュメント保守スキルを順に実行し、指摘と未実施の検証をまとめます。

主な機能

  1. 012つのリポジトリ確認スキルを順次実行
  2. 02リポジトリ規約に照らした変更確認
  3. 03ドキュメント保守の要否判定
  4. 04検証状況と指摘の報告
  5. 05承認・要確認の判定基準

活用シーン

  1. 01引き渡し前のコード変更レビュー
  2. 02リポジトリ文書の更新要否確認
  3. 03レビュー結果と未実施テストの要約
  4. 04追加編集後の確認フロー再実行

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/tahajemmali/skills --skill ship-check

インストール後、Claude Code で/ship-checkを入力して読み込まれたか確認します。

詳細

リリース前チェック

概要

コードまたはドキュメントを変更した後に、リポジトリの作業終了時の検証フローを実行します。

これはオーケストレーションスキルです。専門的なレビュー用スキルの代わりにはなりません。どのチェックをどの順序で実行し、最終引き継ぎの前に結果をどう要約するかをエージェントに伝えます。

標準フロー

修正、リファクタリング、または機能の実装を終えた後に、次のフローを使用します。

  1. $review-changes で最新の変更をレビューします。
  2. $repo-doc-maintainer でプロジェクトドキュメントのメンテナンスが必要か確認します。
  3. 両方の結果を明確に報告します。
  4. コードを変更した場合は、まだ実行していない検証コマンドをユーザーに伝えます。

呼び出しパターン

このスキルが呼び出されたら、リポジトリ内の他のスキルを明示的に順番に使用します。

最初に、次を実行します。

Use $review-changes to review the latest changes against the project's guidelines and report findings first.

続いて、次を実行します。

Use $repo-doc-maintainer to review the latest changes and decide whether project documentation should be updated.

ユーザーが明示的に範囲を限定しない限り、どちらのステップも省略しないでください。

結果の解釈方法

review-changes で問題が見つかった場合
  • まず問題点を提示します
  • 作業が検証済みだと主張しないでください
  • 対応可能で、変更範囲が限定されている問題は、適切であれば最終引き継ぎの前に修正します
  • その後に再びコードを変更した場合は、修正後に検証を再実行します
review-changes で問題が見つからなかった場合
  • 変更が現在のリポジトリのガイダンスに準拠していると伝えます
  • それでも $repo-doc-maintainer は実行します
repo-doc-maintainer がドキュメントの変更が必要と判断した場合
  • 現在のタスクにメンテナンスの編集が含まれていれば、ドキュメントを更新します
  • 含まれていなければ、ドキュメントのメンテナンスが推奨されることを報告します
repo-doc-maintainer がドキュメントの更新は不要と判断した場合
  • 最終報告で、その旨を明示します

出力要件

最終報告には、両方のチェックの結果をまとめます。

  • 実装がリポジトリのルールに準拠しているか
  • ドキュメントのメンテナンスが必要だったか
  • プロジェクトの検証コマンドが実行済みか、未実行のものが残っているか

出力は簡潔にしてください。実際に指摘事項がある場合を除き、長いチェックリストではなく、短い状況報告を優先します。

制約事項

  • リポジトリのルールへの準拠レビューでは、$review-changes を信頼できる情報源として扱います。
  • ドキュメントのメンテナンスに関する判断では、$repo-doc-maintainer を信頼できる情報源として扱います。
  • 独自の第3のレビュー基準をここで作らないでください。
  • このスキルは作業開始前ではなく、作業の最後に使用します。

検証フロー

実装を終えた後に、このチェックリストを使用します。

必須のレビュー用スキル

  1. $review-changes
  2. $repo-doc-maintainer

既定の順序

  1. 最新の作業ツリーまたはコミット範囲を確認します。
  2. $review-changes を使って、リポジトリのルールへの準拠をレビューします。
  3. $repo-doc-maintainer を使って、ドキュメントのメンテナンスについてレビューします。
  4. 両方の結果を要約します。

最終報告に含める内容

  • 変更がプロジェクトで文書化されているガイドラインに準拠しているか
  • プロジェクトドキュメントの更新が必要だったか
  • 検証コマンド（lint、test、analyze）が実行済みか
  • 未実行のテストや手動検証のみの不足など、残っているリスク

再実行するタイミング

最初の検証後にコードまたはドキュメントを追加で編集した場合は、このフローを再実行します。

クローズ時のシグナル

最終的なクローズ報告の後は、必ず単独の行に判定を出力してください。

  • VERDICT: APPROVED — review-changes と repo-doc-maintainer の両方が、未解決のコード上またはドキュメント上の問題なしで合格した場合
  • VERDICT: REMARKS — review-changes が実際のコード上の問題を見つけた場合、または repo-doc-maintainer がこの実行中に解決されなかったドキュメントの不足を見つけた場合

次の場合は VERDICT: APPROVED を使用してください。

  • review-changes が合格した（コード上の指摘事項がない）
  • repo-doc-maintainer が変更不要と判断した、または必要な変更をこの実行中に適用した
  • 外部インフラ（Docker デーモン、クラウドサービス、デバイスエミュレーターなど）が必要な検証コマンドを実行できなかった — これは想定内であり、REMARKS に判定を下げる理由にはなりません
  • この実行中にプランのチェックボックスやその他の管理項目を更新した — 通常の保守作業は指摘事項ではありません

実際に未解決の問題（実際のコード上の問題、未修正のドキュメント不足、またはテストの失敗）がある場合に限り、VERDICT: REMARKS を使用してください。記録が情報提供のみ（例：「Docker ビルドには手動での確認が必要」）の場合は、クローズ報告の概要に含めますが、承認を妨げるものではありません。

REMARKS を出力する場合は、指摘事項を含めてください。

VERDICT: REMARKS

FINDINGS_START
- review-changes: <summary of actual code issues>
- repo-doc-maintainer: <summary of unresolved doc gaps>
FINDINGS_END

VERDICT: の行は、実質的な出力の最後に置いてください。FINDINGS_START／FINDINGS_END の区切りを使用する場合は、それぞれ単独の行に置いてください。

コメント

Markdown 対応