mcpField
F
finish-work

finish-work

github.com/fixmyberlin開発055 回インストール2 日前に更新
リポジトリ

finish-work について

リポジトリやモノレポ内のパッケージで作業する開発者向けの仕上げスキルです。変更の検証、関連ファイルのステージング、コミットメッセージ作成を案内し、コミットしない依頼やプッシュの扱いにも配慮します。

主な機能

  1. 01プロジェクトチェックと失敗の修正
  2. 02関連する変更のみをステージ
  3. 03構造化されたコミットメッセージ
  4. 04明示的なコミット不要の依頼に対応
  5. 05許可なくプッシュしない

活用シーン

  1. 01実装した変更の仕上げ
  2. 02修正の検証とコミット
  3. 03コミットせずにメッセージ案を作成

インストール

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

$npx skills add https://github.com/fixmyberlin/fixmyskills --skill finish-work

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

詳細

作業の完了

プロジェクトのルート、または変更したモノレポの各パッケージ（app/、processing/ など）で実行します。

ワークフロー

  1. 検証します：package.json の scripts.check を読み、bun run check を実行します。根本原因を修正し、すべて成功するまで再実行します。lint／format によってファイルが書き換えられることがあります。
  2. 修正をまとめます：lint／formatによる変更は機能変更と一緒にステージングします。lint または format のコミットを別途作成しないでください。
  3. 以下の形式でコミットメッセージを作成します。
  4. デフォルトではコミットします。 ユーザーが明確にコミットを望んでいない場合を除き、以下のコミット手順を実行します。
  5. コミットしない意図が明確な場合にのみ、メッセージ案を作成します。 メッセージを提示して終了し、git commit は実行しません。

コミットしない意図には、明示的な保留（「コミットしないで」「メッセージ案のみ」「メッセージだけ」「コミットメッセージはどうなる？」）、確認や修正のみの依頼（後続作業なしの「checkを実行」「lintを修正」「CIを修正」）、レビューや質問のみのやり取り、ユーザー自身がコミットすると伝えている場合が含まれます。

意図が曖昧な場合は、特に変更を実装した後や、仕上げのためにfinish-workを呼び出した場合は、コミットを優先します。別のスキルから、より厳格なコミットルール（例：user-changelogでは依頼があった場合にのみコミット）に従ってfinish-workが呼び出された場合は、そのルールが優先されます。

コミット手順：git status、git diff、git log -5 を並行して実行し、関連するファイルのみステージングして、HEREDOCを使って git commit を実行し、最後に git status で確認します。

安全上の注意：依頼がない限りpushしないでください。--no-verify は使用しないでください。以下のlint／format修正の場合を除き、push済みのコミットを amend しないでください。秘密情報や無関係な未コミットファイルをステージングしないでください。

コミット済みで、検証によってlint／formatのみ修正された場合：変更が純粋にlint／formatのみで、HEADに明らかに属する場合は、git commit --amend --no-edit を実行します（HEADがすでにpush済みの場合は、pushには --force-with-lease が必要になることを伝えます。pushはしません）。それ以外の場合は、ユーザーに確認します。

E2Eは check に含まれていません。UI／ルート／認証の変更では、bun run e2e も実行します（check-full が定義されている場合はそちらを実行します）。スキル playwright-skill を参照してください。

スクリプト名：スキル tech-stack → references/package-json-scripts.md。

コミットメッセージ

<Topic>: <Desc>

- <user-facing outcome bullet>
Ping https://github.com/org/repo/pull/123
  • Topic： スコープ（Map、Auth、Processing、Dev など）。FMCの内部のみの変更（依存関係、CI、ツール類）には Dev を使用します。
  • Desc： ファイル名ではなく、実現する内容を命令形で記述します。
  • Body： この変更が反映されると、ユーザーや運用担当者が目にすること、実行できること、利用できるものを箇条書きで記述します。会話で理由が明らかになっている場合は、その理由も含めます。成果のレベルで記述し、ファイル、シンボル、リファクタリング、差分の手順は列挙しません。本文はスキル user-changelog で使用されるため、パッチがなくても理解できる内容にしてください。
  • Ping： ユーザーがPR／issueに言及した場合は、それぞれに Ping <full-url> の行を1行追加します。

例：

Region map: clamp initial viewport to bounds

- Users: map fits selected region on load instead of generic Germany view (confusing deep links)
- Preserve explicit zoom in URL so shared links do not jump
Ping https://github.com/FixMyBerlin/tilda-geo/issues/5678

内部のみの変更（ユーザー向けの変更なし）：メンテナー向けの箇条書きは可。該当するユーザー向けの項目がない場合は省略します。

関連項目

スキル close-worktree（worktreeをdevelopに反映 → 作業ツリーが汚れている場合はこのスキルを呼び出す） | スキル unslop-code（LLMによる生成後のクリーンアップ → フェーズごとのコミットでこのスキルを呼び出す） | スキル playwright-skill | スキル tech-stack | スキル review-dependabot | スキル user-changelog

コメント

Markdown 対応