mcpField
A
automate-me

automate-me

github.com/potetoエージェントワークフロー13388 回インストール21 週間前に更新
リポジトリ

automate-me について

ユーザーの繰り返し現れる仕事上の慣習を、エージェント向けの個別「-mode」スキルにまとめる Cursor スキルです。作業領域内の会話履歴を調べ、好みを質問したうえでスキルを作成・改訂します。

主な機能

  1. 01作業領域内のエージェント履歴を分析
  2. 02好みについて構造化された質問
  3. 03傾向をスキルのセクションに整理
  4. 04個別の mode スキルを作成・改訂
  5. 05既存スキルの更新に対応

活用シーン

  1. 01繰り返し現れるコーディングや応答の好みを記録
  2. 02仕事の習慣からエージェントスキルを作成
  3. 03既存の個人用 mode スキルを更新

インストール

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

$npx skills add https://github.com/poteto/plugins --skill automate-me

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

詳細

自分仕様に自動化

ユーザーの作業上の慣習を、エージェントが従うスキルに変えるためのガイド付きフローです。出力されるのは、そのユーザー向けに調整された -mode スキルです(例:jay-mode、priya-mode)。

このスキルは、ほかの3つのスキルを連携させます。インラインのパターン抽出(ステップ1を参照)、Cursor 組み込みの create-skill(作成)、そして unslop スキル(文章の規律)です。これらを順番に実行しますが、置き換えるものではありません。

フロー

0. 既存のスキルを確認する

プロジェクトの .cursor/skills/ または ~/.cursor/skills/ の下で、ユーザーのハンドルに一致する *-mode/SKILL.md を探します。見つかった場合は、すでに「スキルを更新して」などと伝えられている場合を除き、AskQuestion で意図を確認します。

  • 既存のスキルを更新する(繰り返し実行する場合のデフォルト)
  • 新しく作成する(まれなケース。実行する前に理由を尋ねる)

更新モードでは、以降のフローが次のように変わります。

  • ステップ1では、スキルが最後に編集されて以降の履歴だけを抽出します(git log -1 --format=%cI <path>)。
  • ステップ2では、ゼロから何を取り込むかではなく、何が変わったか、または何が不足しているかを尋ねます。
  • ステップ4では、既存ファイルをその場で編集します。ユーザーが否定していないセクションは保持し、新たな証拠があるものは修正し、本当に新しいルールに限って新しいセクションを追加します。
1. 履歴からパターンを抽出する

並列で作業を始める前に、アクティブなワークスペースのトランスクリプトを特定します。システムプロンプトに、ワークスペースの agent-transcripts/ ディレクトリが記載されています。そのパスだけを使用してください。~/.cursor/projects/*/ を横断して検索してはいけません。ワークスペースの境界を越え、関係のないプロジェクトのプライベートな会話まで読み込むことになります。

その範囲内で、最近のエージェントとの会話を調べ、繰り返し見られるパターンを探します。履歴を複数の範囲に分け、複数のサブエージェントを並行して実行します(例:直近2~4週間を、各範囲に十分な量が含まれるよう3つに分割します)。各範囲を担当するパターン抽出サブエージェントは、親から渡されたワークスペース内のパスにあるトランスクリプトを読み、以下の手がかりを探して、証拠の参照先とともに見つかったパターンを短く構造化して返します。デフォルトで探す手がかりは次のとおりです。

  • 応答の好み(長さ、口調、形式、「もっと簡単に」という修正)
  • 委任の習慣(サブエージェント、モデル、専門的なワークフロー、並列処理)
  • 検証の姿勢(何をもって「完了」とするか、ユニットテストか実際の再現か、レビュアー)
  • コードと文章の規律(スタイル、引用される原則、リンター/フォーマッターツール)
  • プロセス上の慣習(ワークツリー、コミット、PR、レビュー/マージのツール)
  • メタ的な好み(作業中にスキルを修正する、新しいスキルを提案する)

シグナルを採用する前に、範囲をまたいで照合します。2つ以上の範囲で見られたパターンは信頼度が高く、1つの範囲だけで見られたものは弱いため、通常は採用しません。

2. ユーザーに直接尋ねる

履歴からは、まだ話題に上がっていない意向を把握できません。ユーザーに一から入力してもらうのではなく、構造化された複数選択形式の AskQuestion ツールを使います。認知的な負荷を減らし、回答率を高められます。

質問は、各4~6個の選択肢を持つ1~2問にまとめます。カテゴリに関する質問では allow_multiple: true を設定します。まず「どの領域が最も重要ですか?」のように幅広く尋ね、選ばれた領域について具体的な選択肢で追加質問します。構造化された質問の後に、選択肢では拾えなかったことを確認する自由形式の質問を1つ行います。

質問を20個も並べないでください。通常は、構造化された質問を2回行い、最後に自由形式の質問を1つ行えば十分です。

3. 調査結果を分類する

集めたシグナルをセクションごとにまとめます。よく使われる項目は次のとおりですが、該当するものだけを使ってください。

  • 応答スタイル:長さ、口調、形式。
  • 自律性:確認せずにどこまで進めるか、MCP ツールの使用。
  • まず理解する:変更の範囲決定や調査でどのスキルを使うか。
  • サブエージェント:デフォルト設定、並列処理、タスクごとのモデル、専門的なワークフロー。
  • 文章/コードの規律:原則、リンターツール、スタイルガイド。
  • レビューと検証:再現の方針、検証スキル、ライブテストツール。
  • プロセス:Git ワークツリー、コミット、PR、レビュー/マージのツール。
  • スキル:スキル作成の習慣、まずスキルを修正すること、新しいスキルの提案。

poteto-mode スキルを参照して、構成の粒度を確認してください。内容をコピーしてはいけません。ユーザーのルールは、poteto-mode のルールとは異なります。

4. スキルの下書きを作成する

Cursor 組み込みの create-skill スキルを使って、スキルを作成します。配置場所:

  • パス:プロジェクト内の .cursor/skills/<handle>-mode/SKILL.md(または、ユーザーが個人用スキルを希望する場合は ~/.cursor/skills/<handle>-mode/)。
  • ハンドル:ユーザーの名、またはユーザーが選んだ識別子。
  • フロントマターの description:ユーザーの名前と /<handle>-mode、「その人のスタイルで作業する」をトリガーにします。「コードを書く」「PR をレビューする」などの一般的なキーワードではトリガーしません。
  • フロントマターの書式:create-skill の YAML ルールに従います。句読点や折り返しの都合がある場合は、description を単一の YAML スカラーとして引用符で囲むか、インデントした継続行を使う description: >- を使用してください。
  • フロントマターの disable-model-invocation: true をデフォルトにします。モードスキルは内容が多く、明確な方針を持つため、説明文との一致で自動的に適用するのではなく、ユーザーが名前またはスラッシュコマンドで明示的に呼び出した場合にのみ適用します。ユーザーが毎ターン自分のモードを適用することを明示的に希望した場合に限り、この設定を解除します。
5. 文章を反復して改善する

すべての行に unslop スキルと create-skill のライティングガイドラインを適用します。どちらもスキルだけでなく、エージェントが読むあらゆる文章に適用されます。

下書きをユーザーに見せ、フィードバックを受けます。複数回の反復を想定してください。無駄を徹底的に削ります。モードスキルはマニュアルではありません。

6. 仕上げる

main から切ったワークツリーで作業します。コミットして PR を作成し、ユーザーがレビューできるようにします。main に直接プッシュしてはいけません。

ガードレール

  • 1 回の会話に過剰適合しない。 あるときに示された好みが、別のときに示された好みと矛盾する場合はノイズです。ルールとして定めるには、複数回確認されている必要があります。
  • 奇をてらわない。 他のスキルの内容を言い換えたり、比喩を作り出したり、エージェント向けに「詩的な」文章を書いたりするのは、効果よりコストが上回ります。実務に役立つ内容に絞ります。
  • 埋め込まず、参照する。 ユーザーが利用している他のスキルは、内容を貼り付けずにパスで参照します。別途管理されている原則のドキュメントも同様です。
  • セクションは最小限にする。 ユーザー固有のルールがある場合にのみ、セクションを追加します。「明確に伝える」はセクションにしません。「段落は短くする。選択肢の比較には表を使う。項目が実際に並列している場合にのみ箇条書きを使う。」はセクションにできます。
  • 名前の規則は一般化する。 命令文では、作者の名前ではなく「ユーザー」または「人間」を使います。他の人もスキルを読んだり、利用したりする可能性があります。
  • 対称性にこだわらない。 書き留める価値のあるプロセスルールがない場合は、「プロセス」セクションを追加しません。簡潔で構いません。冗長にしないでください。

評価

-mode スキルは主観的な出力です。create-skill 形式のテスト/反復ベンチマークループは役に立ちません。ユーザーに雰囲気を確認します。本人らしい文章になっていますか? 見落としている点はありますか? それから完成させます。

説明文のトリガー精度に実際の問題が生じた場合に限り、説明文を最適化するループを実施します。

使用しない場合

  • ユーザーが作業規約ではなく、特定のタスクに特化したスキルを求めている場合:マイニングは行わず、create-skill だけを使います。
  • ユーザーが狭い範囲のワークフロー(例:「コミットメッセージの書き方」)を記録したい場合:モードスキルではなく、通常のスキルです。

参照ファイル

  • poteto-mode スキル:出力の形式例。
  • unslop スキル:すべての行に適用する文章作成の規律。
  • Cursor 組み込みの create-skill スキル:スキルの作成プロセスとライティングガイドライン。

コメント