mcpField
C
cleanup

cleanup

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

cleanup について

現在のブランチの変更を対象に、レビュー、テスト検証、カバレッジ、Lint、依存関係監査を進めるスキルです。修正案をまとめて開発者の承認を得てから、ステージングとコミットを行います。

主な機能

  1. 01現在のブランチの変更に対象を限定
  2. 02テストケース検証を実行
  3. 03カバレッジ確認と変更コードのテスト追加
  4. 04可能なLint修正を適用
  5. 05依存関係を監査して結果を集約

活用シーン

  1. 01ブランチ提出前にチェックをまとめて実施
  2. 02ブランチ変更コードのカバレッジを向上
  3. 03コミット前の整形と依存関係監査

インストール

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

$npx skills add https://github.com/morphet81/cheat-sheets --skill cleanup

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

詳細

現在の作業ディレクトリ全体のクリーンアップを実行します。変更をレビューし、テストを検証し、Lint と監査の問題を修正し、テストカバレッジを 100% にして、修正案を提示し、コミットします。

使用方法:

  • /cleanup - クリーンアップの全ワークフローを実行します

手順:

重要:これは自律的に実行するワークフローです。まず、すべてのチェックと修正を自分で実行し、最後に結果と修正案を開発者に提示してください。プロセス中に開発者へ質問してはいけません。質問できるのは、最後の承認ステップのみです。

範囲:現在のブランチで導入された変更のみを対象にします。 まずベースブランチを特定します(.agent ファイルで baseBranch=<value> を確認し、なければ main を使用します)。レビュー、カバレッジ分析、Lint 修正、テスト作成はすべて、ベースブランチから現在の状態までに変更されたファイルとコードのみを対象にしてください。変更されていないコードにある既存の問題を指摘したり修正したりしてはいけません。

  1. 未コミットの変更をレビューする:

    • git status を実行して、変更済み、ステージ済み、未追跡のファイルをすべて確認します
    • git diff を実行して未ステージの変更を確認し、git diff --cached を実行してステージ済みの変更を確認します
    • また、git diff <base-branch>...HEAD を実行して、このブランチの変更範囲全体を把握します
    • 変更された各ファイルを読み、変更内容の全体的な文脈を理解します
    • このブランチの変更を、新機能、バグ修正、リファクタリングなどのカテゴリ別に簡潔にまとめます
  2. 新しいテストケースを検証する:

    • /verify-test-cases スキルを呼び出し、前回のプッシュ以降に変更されたすべてのテストファイルを確認します
    • 見つかった問題(意味をなさないテスト、重複、カバレッジ不足)を記録します
  3. テストカバレッジを実行する(1 回のみ):

    • プロジェクトのカバレッジコマンドを正確に 1 回実行し、出力全体を保存します。後からカバレッジを再実行してはいけません。以降の分析にはこの出力を再利用してください。
      • Node.js: package.json のスクリプトを先に確認し、npm run test:coverage または npx jest --coverage または npx vitest run --coverage を実行します
      • Python: pytest --cov または coverage run -m pytest && coverage report
      • Rust: cargo tarpaulin または cargo llvm-cov
      • Go: go test -coverprofile=coverage.out ./... && go tool cover -func=coverage.out
    • 出力を解析して、以下を特定します。
      • 全体のカバレッジ率
      • カバーされていないファイルと行
    • カバレッジが**100%**の場合:合格として記録し、次へ進みます
    • カバレッジが100%未満の場合:ブランチで変更されたファイルにあるカバーされていないファイルや行ごとに、不足しているテストケースを自分で作成し、カバレッジを 100% にします。プロジェクトの規約に従って、既存のテストファイルにテストを追加するか、新しいテストファイルを作成します。変更していないファイルのカバーされていない行に対するテストは作成しないでください。
  4. Lint の問題を修正する:

    • 設定ファイルを確認して、プロジェクトの種類を自動的に判別します。

      • package.json(Node.js/JS/TS)
      • pyproject.toml、setup.py、requirements.txt(Python)
      • Cargo.toml(Rust)
      • go.mod(Go)
    • 自動修正コマンドがある場合は使用します:

      • Node.js/JS/TS:
        • package.json のスクリプトに lint:fix があるか確認します。あれば npm run lint:fix を実行します
        • なければ、ESLint があるか確認し、npx eslint . --fix を実行します
        • Prettier があるか確認し、npx prettier --write . を実行します
      • Python:
        • ruff があるか確認し、ruff check --fix . を実行してから ruff format . を実行します
        • または、black があるか確認し、black . を実行します
        • または、autopep8 があるか確認し、autopep8 --in-place --recursive . を実行します
      • Rust:
        • cargo fmt と cargo clippy --fix --allow-dirty を実行します
      • Go:
        • gofmt -w . と go vet ./... を実行します
    • 自動修正できなかった、未解決の Lint の問題を記録します

  5. 監査を実行し、問題を修正します:

    • Node.js: npm audit を実行します。脆弱性が見つかった場合は、npm audit fix を実行します。それでも解決しない場合は、残っている問題を記録します。ただし、自動的に npm audit fix --force を実行してはいけません
    • Python: 利用可能な場合は pip audit を実行します。見つかった脆弱性を記録します
    • Rust: 利用可能な場合は cargo audit を実行します。見つかった脆弱性を記録します
    • Go: 利用可能な場合は govulncheck ./... を実行します。見つかった脆弱性を記録します
    • 自動修正できなかった監査上の問題を記録します
  6. 修正案と改善案を提示します:

    実施した内容と判明したことをすべてまとめて表示します。その後、multiSelect: true を指定して AskUserQuestion ツールを使用し、適用する修正案と改善案を開発者が選べるようにします。開発者が選ぶのは、自身の変更をコミットするかどうかではありません。エージェントが提案する修正案や改善案を採用するかどうかです。

    項目をカテゴリーごとにまとめます:

    • 適用したリンター修正 — リンターによって自動フォーマットされたファイル
    • カバレッジ修正 — カバレッジ 100%を達成するために作成または更新したテストファイル
    • 適用した監査修正 — 監査修正による依存関係の変更
    • テスト品質の問題 — verify-test-cases で見つかった問題(修正案を含む)
    • 修正できない問題 — 自動修正できなかったすべての項目(情報提供のみ)

    質問の形式例:

    "Which fixes/improvements do you want to apply?"
    Options:
    - "Lint fixes: 5 files auto-formatted by ESLint"
    - "Coverage: added tests for 3 uncovered files (85% → 100%)"
    - "Audit fix: updated lodash 4.17.20 → 4.17.21"
    - "Test quality: fixed 2 incorrect test descriptions"
    

    項目数が 4 つの選択肢に収まらない場合は、論理的なまとまりごとにグループ化します(例:「すべてのリンター修正(8 ファイル)」を 1 つの選択肢にまとめます)。

  7. 選択された修正を適用します:

    • 開発者が承認した修正:変更を保持します
    • 開発者が却下した修正:git restore <file> を使うか、編集を元に戻して、該当する変更を取り消します
    • 承認された変更をすべて git add でステージングします
  8. 例外的なケースに対応します:

    • 未コミットの変更がない場合は、ユーザーに伝えて終了します
    • リンティングツールが見つからない場合は、リンティングの手順を省略し、サマリーにその旨を記載します
    • 監査ツールが見つからない場合は、監査の手順を省略し、サマリーにその旨を記載します
    • カバレッジツールが見つからない場合は、カバレッジの手順を省略し、サマリーにその旨を記載します
    • /verify-test-cases スキルで変更されたテストファイルがないと報告された場合は、サマリーからそのセクションを省略します
    • すべてのチェックに合格し、修正が不要な場合は、承認の手順を省略して、そのままコミット方法の選択に進みます
    • 開発者がすべての修正を却下した場合は、開発者自身の変更のみをコミットし、修正は含めません

出力形式の例:

## Cleanup Summary

### Changes Reviewed
- 3 files modified, 1 file added
- New feature: user profile endpoint
- Bug fix: corrected date parsing in utils

### Lint
✅ 5 files auto-fixed by ESLint
⚠️ 1 issue could not be auto-fixed:
  - src/api.ts:42 — Unexpected any. Specify a different type.

### Test Verification
✅ All test cases verified — no issues found

### Coverage (from single run)
⚠️ Coverage at 87% — missing coverage in:
  - src/services/auth.ts (lines 45-62)
  - src/utils/parser.ts (lines 12-18)
✅ Wrote 2 new test files to cover missing lines

### Audit
✅ npm audit fix applied — resolved 2 vulnerabilities
⚠️ 1 moderate vulnerability remains (no auto-fix available)

---

[Approval checklist: developer picks which fixes to keep]

---

✅ Committed: "Add user profile endpoint, fix date parsing, and improve test coverage"

コメント