Communitygithub.com

heyeuca/less

文章、コード、UIコード(HTML/CSS、JSX、Tailwind)から存在理由の明確でない要素を削除し、正確性、必要なコンテキスト、安全性、アクセシビリティ、ユーザーが要求した内容は保持します。ユーザーが「削除」「トリミング」「除去」「簡略化」「短くする」などを依頼した場合や、AIが生成した出力を整理したい場合に使用します。UI機能の追加やアクセシビリティ監査、パフォーマンス改善には使用しません。

less とは?

`heyeuca/less` は、AIエージェント(Claude Code、Cursor、Codexなど)向けのスキルで、文章やコード、UIコードから「存在理由の明確でない要素」を削除するためのルールセットです。ユーザーが「削除」「トリミング」「整理」「短くする」といった指示を出した場合、または出力が「長すぎる」「散らかっている」と感じた場合にのみ適用されます。このスキルは、正確性、必要なコンテキスト、安全性、アクセシビリティ、ユーザーが明示的に要求した内容を絶対に削除しないという厳格なルールに基づいています。削除の優先順位が定義されており、文章では前置きや挨拶、重複、不要な但し書きが対象となり、コードではコメントや不要な抽象化、防御的コードが対象です。重要なのは、削除後も文法的に正しく、実行可能な状態を維持するために必要な最小限の編集のみを行うことです。設計(UIコード)の場合は、参照デザインファイルを確認した上で要素とスタイルにのみ適用され、新しい美学を追加することはありません。このスキルは、ユーザーからの明確な要求または明確な合図がある場合にのみ機能し、独立したスタイルの書き換えや翻訳、決められた長さの要約、ファクトチェックなどは行いません。

対応~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/heyeuca/less/tree/HEAD/skills/less

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

less は何をしますか?

より少なく、しかしより良く。存在理由のあるものだけを残します。

テスト

各要素(文、注釈、見出し、箇条書き、コメント、関数、パラメータ、オプション)について、次の問いを立ててください: これには明確な存在理由がありますか? 存在理由がなければ削除します。明瞭さは簡潔さに優先します。判断に迷った場合は保持してください。ある一節が文脈の中で何を行っているかを判断し、それが定型句に合致するかどうかではありません。周囲のテキストを読んでください: 修飾語が後続の文を支配している可能性があります。確定した削除対象の外にある文やコード領域は変更せず、削除によって必要な局所的な修正のみを許可します。

適用タイミング

ユーザーからの要求または明確な合図がある場合のみ、単なる草案作成や新規コード作成時ではありません。不必要な要素を削除し、削除によって結果が文法的に正しく、または実行可能な状態を維持するために必要な局所的な編集(冗長なヘルパーのインライン化など)のみを許可します。独立したスタイルや文体の書き換え、翻訳、決められた長さの要約、ファクトチェック、アルゴリズムの置き換え、パフォーマンス改善は行いません。

適用しない場合

次の場合は入力をそのまま返し、理由を一行で示してください:

  • 法的、契約上のテキスト、その他の逐語的なテキスト、引用文および書き起こし。
  • ユーザーが指定していないコード、設定、コマンド。

ユーザーが指定したコードのみを変更します。ユーザーが設定した長さや形式は除外理由にはなりません。その枠内で作業してください。

削除順序

すべての候補について、まず「絶対に削除しない」を確認してください。特にユーザー自身の挨拶と結びの言葉は守ってください。

文章:

  1. 前置き、質問の言い換え、あなたが追加した挨拶(「素晴らしい質問ですね!」)。
  2. あなたが追加した結びの要約や提案、あるいはPR説明、コミット、ドキュメントの末尾にあるもの(「お役に立てれば幸いです」「いかがでしょうか...」)。
  3. 何も変えない婉曲表現や冗長表現。
  4. 重複するポイント(最も明確なものを残す)。
  5. 要求されていない注釈や代替案で、読者の行動を変えないもの。
  6. 約5文以下の回答における装飾: 見出し、太字、箇条書き。
  7. 残りをマージして短縮し、完全な文を維持する。ユーザーのテキストを編集する場合、文のマージや言い換えは行わず、削除によって直接影響を受ける文法のみを修復する。

コード:

  1. コードを言い換えるだけのコメント。
  2. 不要な抽象化: ヘルパー、ラッパー、インターフェース、ファクトリ。単一使用だけでは抽象化が不要である証拠にはなりません。
  3. 要求されていないオプション、フラグ、設定。
  4. 可視コードからは決して発生し得ないケースに対する防御的コード。それ以外は保持する。

コードやオプションを削除する前に、利用可能な呼び出し元、エクスポート、関連テストを確認してください。外部から使用されているシグネチャと動作は、ユーザーが明示的に変更を要求しない限り保持します。コード編集後は、関連する既存のチェックを実行してください。使用法や動作を確認できない場合は、候補を保持します。

ドキュメント: セクションごとにテストを適用します。読者がナビゲーションに使う構造を見出し、目次とアンカー、他の場所で参照されている番号付きステップ、データを保持するテーブルはそのまま残します。セクション全体がテストに合格しない場合のみ削除します。セクション全体を削除しない限り、すべての見出しとその目次エントリを保持します。セクションをイントロにマージしないでください。

設計: ユーザーが指定したUIコードについて、要素とスタイルにテストを適用します。 references/design.md(削除順序と絶対に削除しないリスト)を確認した後にのみ削除してください。そこにある「要求されていないコンテンツ」とはエージェントが追加したものであり、ユーザーが書いたものではありません。マークアップとスタイルのみを変更します。新しい美学は追加しません。新しいUIの構築、スクリーンショット、Figmaファイルには使用しません。

絶対に削除しない

  • 正確性: 数値、単位、日付、条件、例外、否定。
  • 主張の強さ: 不確実性、近似、範囲、因果関係、義務。「約」「いくつかの」「最大でも」「かもしれない」「しなければならない」など、意味を持つ修飾語を保持します。短縮によって主張が強まったり弱まったりしてはいけません。
  • 必要なコンテキスト: 読者が行動するために必要なもの(前提条件、手順、バージョン)。
  • 安全性: データ損失、セキュリティ、金銭、法的、取り返しのつかないアクションに関する警告。
  • ユーザーの要求: 要求された内容、形式、長さ、制約。
  • 帰属と引用。
  • ユーザーのテキストを編集する場合のユーザーの文体。 スタイルを書き換えないでください。
  • ユーザーが書いた人へのメッセージ(メール、チャット、手紙)における: 挨拶、署名、返信や質問を促す行(「ご不明な点がございましたら、お知らせください...」)。例: 「何かまだ不明な点がございましたら、いつでもお気軽にお問い合わせください。」はそのまま残します。「いつでも」「まだ」はトリミングしても構いません。保護されるのは挨拶と結びの言葉のみです。ユーザーのテキスト内の他の冗長表現(「基本的に」「文字通り」「ただ」)はユーザーの文体を保ちながら削除されます。
  • 丁寧さのレベル: 존댓말/敬語 形式、様、挨拶、署名。その中に積み重ねられた軟化表現や強調表現(정말、혹시、大変、誠に、何卒)は削除候補となります: 不確実性や社会的意図を伝える場合のみ保持します。
  • コード: 動作(出力、副作用、エラー)。実際の境界(I/O、ネットワーク、ユーザー入力)におけるエラーハンドリング。「理由」のコメント、制約、安全性に関する注釈。要求がない限りパブリックAPIとシグネチャ。チェックやランタイムに影響を与える型アノテーション。テスト専用のフックとシーム。
  • 目的が特定できないもの。

停止

すべての要素がテストに合格した時点、または次の削除が意味を損なうか推測を必要とする時点で停止します。結果をソースと比較し、主張の強さが変わっていないか、良好な周辺素材に意図しない編集がないか確認します。長さを満たすために決して削除しないでください。ユーザーがテキストの短縮を要求した場合、テストに合格しない冗長表現は削除されますが、変更されない部分には理由が必要です。

出力

削除後のテキストまたはコードのみを、同じ形式と言語で出力します。例外は「適用しない場合」の下にある一行の理由です。削除された内容についてユーザーが尋ねない限りコメントを付けず、尋ねた場合のみリストアップします。何も変更すべきでない場合は、そのまま返します。

関連スキル