automate-me

自分仕様に自動化

ユーザーの作業上の慣習を、エージェントが従うスキルに変えるためのガイド付きフローです。出力されるのは、ユーザーに合わせて調整された 1 つの -mode スキル（例：jay-mode、priya-mode）です。

このスキルは、他の 3 つのスキルを連携させます。インラインでのマイニング（ステップ 1 を参照）、Cursor 組み込みの create-skill（作成）、そして unslop スキル（文章作成の規律）です。それらを順序立てて実行します。置き換えるものではありません。

フロー

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

ユーザーのハンドルに一致する .cursor/skills/**/*-mode/SKILL.md と ~/.cursor/skills/*-mode/SKILL.md を再帰的に検索します。モードスキルはトップレベルだけでなく、個人用のカテゴリディレクトリ（.cursor/skills/<handle>/）に置かれている場合もあります。見つかった場合は、AskQuestion を使って意図を確認します（すでに「自分のスキルを更新して」などと言っている場合を除く）。

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

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

• ステップ 1 では、スキルが最後に編集されてからの履歴のみをマイニングします（git log -1 --format=%cI <path>）。
• ステップ 2 では、ゼロから何を取り込むかではなく、何が変わったか、または何が不足しているかを尋ねます。
• ステップ 4 では、既存のファイルをその場で編集します。ユーザーが異議を唱えていないセクションは維持します。新たな根拠があるものは修正します。本当に新しいルールに限り、新しいセクションを追加します。

1. 履歴をマイニングする

範囲を分割して作業する前に、アクティブなワークスペースのトランスクリプトを特定します。システムプロンプトに、ワークスペースの agent-transcripts/ ディレクトリが記載されています。そのパスのみを使用します。~/.cursor/projects/*/ を横断的に検索しないでください。ワークスペースの境界を越えて、無関係なプロジェクトのプライベートなチャットを読むことになります。

その範囲内の最近のエージェントとの会話を調査し、繰り返し見られるパターンを探します。履歴を複数の範囲に分け、それぞれを並列のサブエージェントに割り当てます（例：直近 2～4 週間を、各範囲に十分な資料が含まれるよう 3 つに分割します）。各範囲を担当するマイニングサブエージェントは、親から渡されたワークスペース限定のパスにあるトランスクリプトを読み、以下の兆候を探します。見つけたパターンを、根拠を示すポインターとともに短く構造化して返します。デフォルトで調査する価値のある兆候：

• 応答の好み（長さ、トーン、形式、「もっと簡単に」という修正）
• 委任の習慣（サブエージェント、モデル、専門的なワークフロー、並列処理）
• 検証の方針（何をもって「完了」とするか、単体テストか実環境での再現か、レビュー担当者）
• コードと文章の規律（スタイル、引用される原則、リンター／フォーマッターツール）
• プロセス上の慣習（worktree、コミット、PR、レビュー／マージ用ツール）
• メタ的な好み（タスク中のスキル修正、新しいスキルの提案）

シグナルを採用する前に、各範囲の結果を照合します。2 つ以上の範囲で見られたパターンは信頼度が高いと判断します。1 つの範囲だけで見られたものは根拠が弱く、通常は除外します。

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

マイニングでは、まだ話題に上がっていない意図を把握できません。ユーザーに最初から自由記述させるのではなく、構造化された複数選択式の AskQuestion ツールを使います。

質問の組み立て：各選択肢を 4～6 個にした質問を 1～2 個用意し、カテゴリに関する質問では allow_multiple: true にします。まず「どの領域を最も重視しますか？」のように広く尋ね、選択された領域について具体的な選択肢で追加質問します。構造化された質問を終えたら、選択肢に含まれなかった内容を拾うため、最後に自由記述の質問を 1 つします。

質問を 20 個も並べないでください。

3. 調査結果を分類する

見つかったシグナルをセクションに分類します。よくある分類は次のとおりです（該当するもののみ使用します）。

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

poteto-mode スキルを読み、構成の粒度を参考にします。内容はコピーしないでください。ユーザーのルールは poteto-mode のルールとは異なります。

4. スキルの草案を作成する

Cursor に組み込まれている create-skill スキルを使って、スキルを作成します。配置場所：

• パス：既存のモードスキルがある場合は、そのカテゴリを維持します。新しいモードの場合、そのハンドル用の個人カテゴリがリポジトリに確立されていれば、.cursor/skills/<handle>/<handle>-mode/SKILL.md を使います。そうでなければ、プロジェクト内の .cursor/skills/<handle>-mode/SKILL.md をデフォルトとします（ユーザーが個人スキルを希望する場合は ~/.cursor/skills/<handle>-mode/）。
• ハンドル：ユーザーの名、または選択した識別子を使います。
• フロントマターの description：一般的なキーワード（「コードを書く」や「PR をレビューする」など）ではなく、ユーザーの名前と /<handle>-mode、および「その人のスタイルで作業する」をトリガーにします。
• フロントマターの書式：create-skill の YAML ルールに従います。句読点や折り返しの都合がある場合は、description を単一の YAML スカラーに保ち、引用符で囲むか、description: >- としてインデントした継続行を使います。
• フロントマターでは、デフォルトで disable-model-invocation: true にします。ユーザーが自分のモードを毎ターン適用するよう明示的に希望した場合に限り、これを無効にします。

5. 文章を推敲する

unslop スキルと create-skill のライティングガイドラインをすべての行に適用します。

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

6. 仕上げる

main から作業用ツリーを作成します。コミットして PR を作成します。main に直接プッシュしないでください。

ガードレール

• 一度の会話に過剰適合しないでください。 一度だけ示された好みが別の機会に否定された場合は、ノイズとして扱います。明文化するには複数回の確認が必要です。
• 気の利いた表現を狙わないでください。 他のスキルの内容を言い換えたり、比喩を作ったり、エージェント向けに「詩的な」文章を書いたりしても、手間に見合う効果はありません。実務的に記述します。
• 本文に転載せず、参照してください。 ユーザーが利用する他のスキルは、内容を貼り付けずにパスで参照します。ユーザーが別の場所で管理している原則文書も同様です。
• セクションは最小限にします。 ユーザー固有のデフォルト以外のルールがある場合に限り、セクションを追加します。「明確に伝える」はセクションにしません。「短い段落を使う。選択肢の比較には表を使う。本当に並列の項目に限って箇条書きを使う。」はセクションにできます。
• 名前の付け方は汎用的にします。 命令文では、作者の名前ではなく「ユーザー」または「人間」を使います。
• 対称性を無理に作らないでください。 書き留める価値のあるプロセス上のルールがユーザーにない場合は、「プロセス」セクション自体を省略します。

評価

-mode スキルは主観的な成果物です。create-skill 形式のテスト／反復ベンチマークループはここでは役に立ちません。ユーザーに感想を尋ね、本人らしい文章か、抜けている点がないかを確認してから仕上げます。

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

使用しない場合

• ユーザーが作業規約ではなく、特定のタスク用スキルを求めている場合：情報の抽出は行わず、create-skill のみを使います。
• ユーザーが「コミットメッセージの書き方」など、特定の狭いワークフローを記録したい場合：モードスキルではなく、通常のスキルを作成します。