automate-me

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 つの範囲に分け、各範囲に十分な資料を確保します）。poteto-modeスキルの Subagents セクションに従い、タスクに応じて各サブエージェントの推論レベルと fast または standard の速度を選びます。各範囲を担当するサブエージェントは、親から渡されたワークスペース限定パスのトランスクリプトを読み、以下のシグナルを探し、確認できたパターンと根拠への参照を簡潔な構造化リストで返します。まず確認すべき一般的なシグナルは次のとおりです。

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

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

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

履歴の抽出だけでは、これまで話題に上がっていない意向はわかりません。ユーザーに一から入力してもらうのではなく、AskQuestion ツール（構造化された複数選択式）を使います。

形式：各 4～6 個の選択肢を用意し、質問は 1～2 個にします。カテゴリに関する質問では allow_multiple: true を使います。まず大まかに（「どの領域を最も重視しますか？」）尋ね、選ばれた領域について具体的な選択肢を提示して掘り下げます。構造化された質問を終えた後、選択肢で取りこぼした内容を拾うために、自由記述式の質問をチャットで 1 つ尋ねます。

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

3. 調査結果を整理する

複数のシグナルをセクションごとにまとめます。よくある項目は次のとおりです（該当するものだけを使用してください）。

• 応答スタイル：長さ、トーン、形式。
• 自律性：確認せずにどこまで進めるか、MCP ツールの使用。
• まず理解する：変更の範囲を定めたり調査したりするときに、どのスキルを使うか。
• サブエージェント：デフォルト、並列処理、タスクに応じたモデルの選択、専門的なワークフロー。
• 文章／コードの作法：原則、lint ツール、スタイルガイド。
• レビューと検証：再現に対する姿勢、検証スキル、実環境テスト用ツール。
• プロセス：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 から worktree を作成して作業します。コミットして PR を開いてください。main に直接プッシュしないでください。

ガードレール

• 1 回の会話に過剰適合しないでください。 一度述べられた好みが別の機会に否定されている場合、それはノイズです。ルールとして明文化するには、複数回確認してください。
• 奇をてらわないでください。 他のスキルの内容を言い換えたり、比喩を作り出したり、エージェント向けに「詩的な」文章を書いたりするのは、利益のないコストです。実務に役立つ内容にしてください。
• 埋め込まず、参照してください。 ユーザーが頼りにしている他のスキルは、内容を貼り付けず、パスで参照してください。別の場所で管理している原則文書も同様です。
• セクションは最小限にしてください。 ユーザーに固有の、デフォルトではないルールがある場合のみセクションを追加します。「明確に伝える」はセクションにしません。「段落は短く。選択肢の比較には表を使う。本当に並列な項目に限って箇条書きにする。」はセクションになります。
• 対称性を無理に保たないでください。 明記する価値のあるプロセス上のルールがユーザーにない場合は、Process セクション自体を省略してください。

評価

-mode スキルは主観的な成果物です。create-skill 形式のテスト／反復ベンチマークループはここでは役に立ちません。ユーザーと一緒に感触を確かめてください。本人らしい内容になっていますか？見落としていることはありますか？その後、公開してください。

説明文の最適化ループは、実際に使ってトリガーの精度に問題があると分かった場合に限って実施します。

使用しない場合

• ユーザーがタスク固有のスキルを求めている場合（作業規約ではない場合）：情報の抽出は不要で、create-skill のみを使用します。
• ユーザーが「コミットメッセージの書き方」など、範囲の狭いワークフローを記録したい場合：これは通常のスキルであり、モードスキルではありません。