Communityライティング&編集github.com

Ponytail(ポニーテール)

オプトインのミニマリズムモードをコーディングに適用します。怠惰は非効率ではなく、まず実際の流れを理解し、その後でソリューションを最小化します。

Ponytail(ポニーテール) とは?

Ponytailは、ソフトウェアエンジニアリングのワークフローにおいて、オプトイン式のミニマリズムを強制するエージェントスキルです。コードの削減、標準ライブラリやプラットフォーム機能の優先的活用、そして新しいコードの最小限の記述を促進します。このスキルは、Claude Code、Cursor、CodexなどのAIエージェント向けに設計されており、開発者が「lite」「full」「ultra」の3段階の強度レベルから選択できます。最も注目すべき点は、コードを書く前に「本当に必要なのか?」から始まる7段階の優先順位ラダーを提供し、変更の最小化と根本原因の修正を促すことです。また、変更が本当に小さいことを保証するために、テストの比例的な検証を求め、不要な依存関係や先回りした抽象化を避けます。レポートは簡潔に、結果とスキップした内容、追加すべき条件を3行以内で示すことが求められます。

対応~Claude Code~Codex CLI~Cursor
npx skills add S3n0001/agent-skills

Installed? Explore more ライティング&編集 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

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

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

ドキュメント

Ponytail(ポニーテール) は何をしますか?

オプトインのミニマリズムモードをコーディングに適用します。怠惰は非効率ではなく、まず実際の流れを理解し、その後でソリューションを最小化します。デフォルトは現在のタスクに対してのみフル強度とします。lite、full、ultra が指定された場合はそれに従い、ユーザーが通常モードを要求した時は停止します。

ラダーを登る

リクエストを完全に満たす最初の段階で停止します。

  1. それは存在する必要がありますか? 推測による作業をスキップします。
  2. コードベースにすでに存在しますか? 検索して、所有するヘルパー、型、パターン、シームを再利用します。
  3. 標準ライブラリで解決できますか? それを使用します。
  4. ネイティブのプラットフォーム機能で解決できますか? カスタムコードよりもHTML、CSS、データベース、フレームワーク、オペレーティングシステムの動作を優先します。
  5. インストール済みの依存関係ですでに解決されていますか? 再利用します。数行の明確なコードのためにパッケージを追加しないでください。
  6. 1つの読みやすいローカル式で解決できますか? ローカルに留めます。
  7. それ以外の場合のみ: 正確な最小限の新しいコードを記述します。

ラダーは理解に従い、決してそれを置き換えるものではありません。タスクとリポジトリの指示を読み、実際の呼び出し元と消費者をトレースし、段階を選ぶ前に真実の源泉を特定します。

変更を真に小さく保つ

  • 共有された所有するシームで根本原因を修正します。共通パスの1行のガードは、すべての呼び出し元でのパッチよりも小さいです。
  • すべての明示的な要件と、到達可能なセキュリティ、プライバシー、アクセシビリティ、データ整合性、エラーハンドリング、互換性の不変条件を保持します。
  • 追加よりも削除を、巧妙なコードよりも退屈なコードを優先します。
  • 単一実装インターフェース、単一製品ファクトリ、推測による設定、並列フレームワーク、「後で使う」ための足場、測定された必要性のない新しい依存関係を避けます。
  • 1つの首尾一貫した読みやすい成果を生み出す最小限のファイルを使用します。動作を隠したり複雑さを他の場所に移したりするようなワンライナーを強制しないでください。
  • 2つの小さな解決策が同等である場合、エッジ動作がより安全で、所有コストが低い方を優先します。
  • 実質的な天井を ponytail: コメントでマークし、その天井とアップグレードトリガーを明示します。

複雑なリクエストには、より単純な同等のパスが存在する場合があります。それを使用し、置き換えを1行で説明しますが、差分を減らすためだけに要件を決して落とさないでください。

比例して検証する

証明のない怠惰な変更は未完了です。既存のリポジトリのテスト規則に従います。

  • 分岐、ループ、パーサー、または金銭/セキュリティパスなどの非自明なロジックには、少なくとも1つの焦点を絞った実行可能なチェックが必要です。
  • 実質的に異なるリスクや受け入れ条件に対してのみ、さらにチェックを追加します。
  • 1つの変更のためにテストフレームワークを導入しないでください。
  • 自明なワンライナーは、既存のカバレッジですでに証明されている場合、新しいテストは不要です。

強度を設定する

レベル動作
lite要求されたものを構築し、より怠惰な同等物を1行で名前付けします。
fullラダーを強制します。再利用、標準ライブラリ、ネイティブ動作、および最短の読み取り可能な正しい差分を優先します。
ultra推測による要件に挑戦し、まず削除を試み、実証された最小のニーズだけを出荷します。

ユーザーの要件と安全性の不変条件は常に強度よりも優先されます。

簡潔に報告する

提供されたコードまたは成果から始めます。次に、ユーザーが明示的にレポートやウォークスルーを要求していない限り、スキップした内容とそれを追加する正当な条件について、最大3行の短い行を使用します。

パターン: [結果] -> スキップ: [X]; [Y]のときに追加します。

Ponytailは何を構築するかを管理します。タスクが理解されているかどうか、必要な証拠が報告されているかどうかは管理しません。完了への最短の正しい読み取り可能なパスが正しいパスです。

関連スキル