mcpField
N
no-comments

no-comments

github.com/remotion-dev開発71.5k52 回インストール1 日前に更新
リポジトリ

no-comments について

no-commentsは、指定ファイルまたは現在の差分を対象にコメントを確認するコーディングスキルです。外部制約、APIドキュメント、機械向け指示を区別し、動作を変えずに対象範囲のコメントだけを削除します。

主な機能

  1. 01指定ファイルまたは現在の差分を確認
  2. 02外部システムの説明を保持
  3. 03APIドキュメントと機械向け指示を保持
  4. 04説明的・古いコメントを削除
  5. 05変更したパッケージでlintを実行

活用シーン

  1. 01コード差分のコメント整理
  2. 02外部制約を記したコメントの判定
  3. 03古いTODOやコメントアウトコードの削除

インストール

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

$npx skills add https://github.com/remotion-dev/remotion --skill no-comments

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

詳細

コメント禁止

自分たちのコードを説明するコメントを削除してください。自分たちが所有するコードは、名前、型、構造で説明できるようにしてください。自分たちの管理外にある事柄について記述し、読者がコードから知ることができない場合に限り、コメントを残してください。

対象範囲

ユーザーが指定したファイルまたは差分を使用してください。指定がない場合は、ステージ済み、未ステージ、未追跡の変更を含む、main との差分を使用してください。

git diff main...HEAD
git diff HEAD
git ls-files --others --exclude-standard

対象範囲内で追加または変更された行のコメントのみを変更してください。同じファイル内の変更されていないコードには手を加えないでください。

残すコメント

コメントは、外部システムに関するもので、かつ現在も正確な場合に限り残します。

  • ブラウザーの動作：Chrome／Safari／Firefox の癖、WebCodecs、Canvas、CSS、レイアウト、イベントの順序、自動再生ポリシー、関連するバグトラッカー。
  • メディアおよびツール：FFmpeg、コーデック、コンテナ、Mediabunny、Chromium のフラグ、Lambda／Cloud Run の制限、Node.js、Bun、TypeScript コンパイラー、バンドラーの動作。
  • サードパーティのライブラリと API：通常とは異なる方法で呼び出す理由、上流の問題へのリンク。
  • OS、ハードウェア、仕様上の制約：ファイルシステム、GPU、Linux／macOS／Windows の違い、RFC、W3C 仕様。

次のコメントも残してください。

  • マシンが解釈する指示：eslint-disable*、@ts-expect-error、@ts-ignore、/// <reference>、'use client'、istanbul ignore、prettier-ignore、biome-ignore、@vitest-environment、シバン、ライセンスヘッダー。ただし、各抑制が必要かどうかは引き続き確認し、不要になったものは削除してください。
  • 公開されているエクスポート API の JSDoc（エディターのツールチップに表示されます）。
  • @deprecated タグ（deprecate-api スキルを参照してください）。
  • ドキュメント、MDX、ユーザーに表示されるコードスニペット内のコメント。

削除するコメント

  • 後続の行が何をするかを説明するコメント（// フレームを取得、// トラックをループ）。
  • 名前、型、パラメーターを言い換えただけのコメント。
  • 独自のアーキテクチャ、データフロー、設計上の選択を説明するコメント。
  • 自分たちのバグに対する回避策を正当化するコメント。対象範囲内で根本原因を修正するか、コメントを残さないでください。
  • 自分たちのコードに関する IMPORTANT、do not remove、keep in sync with X、talk to Y first という注意書き。制約が実際に存在する場合は、代わりに型、共有定数、テスト、リンターで表現することを提案してください。いずれの場合もコメントは削除してください。
  • コメントアウトされたコード、関連 issue へのリンクがない TODO／FIXME、変更履歴風の記述（// Added in v4.0.x）、セクションの区切り。

複数の内容が混在するコメントは、外部システムに関する文だけを残し、それ以外は削除してください。

自分たちのコードに本当に意外な点がある場合は、コメントを残すのではなく、より明確な名前、抽出した変数、または型を使うことを優先してください。コードの変更は、簡単で局所的なものに限ります。それ以外の場合はコメントを削除し、レポートでその意外な点に言及してください。

手順

  1. 対象範囲内のすべてのコメント（//、/* */、JSDoc、JSX {/* */}、シェル／YAML の #）を収集します。

  2. 上記のルールに基づき、それぞれを残すか削除するか分類します。コメントが外部システムに関するものか判断に迷った場合は、「コードを書き換えても、この内容は正しいままか」を確認してください。正しいままなら残し、自分たちの実装方法によってのみ意味を持つなら削除します。

  3. コメントを削除します。動作は変更しないでください。書式を崩す空行が残った場合は削除してください。

  4. 変更したパッケージでフォーマットと lint を実行します。

    bunx turbo run lint --filter='<package-name>'

  5. 報告する内容：削除したコメントの数、残したコメントとその理由（それぞれ一行）、エンコードするために提案した制約、追加対応が望ましい意外なコード上の点。

コメント

Markdown 対応