automate-me

Automate me

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

このスキルは、ほかの 3 つのスキルを連携させます。インラインでのマイニング処理（ステップ 1 を参照）、使用するハーネスのスキル作成スキル（作成）、そして unslop スキル（文章の規律）です。それらの実行順序を調整します。置き換えるものではありません。

スキル作成スキルは、Cursor では create-skill（組み込み）、Anthropic では skill-creator です。どちらもない場合は、agentskills.io の Agent Skills 形式に従ってください。以下の「create-skill」は、使用するいずれかのスキルを指します。

フロー

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

ハーネスのスキルフォルダー内を再帰的に検索し、ユーザーのハンドルに一致する *-mode/SKILL.md を探します。プロジェクト内では、.cursor/skills/（Cursor）、.claude/skills/（Claude Code）、.pi/skills/（Pi）、.agents/skills/（Codex、OpenCode など）を確認します。ユーザー側では、~/.cursor/skills/、~/.claude/skills/、~/.pi/agent/skills/、~/.codex/skills/、~/.config/opencode/skills/、または ~/.agents/skills/ を確認します。モードスキルは最上位だけでなく、個人用カテゴリーディレクトリー（<skills>/<handle>/）に置かれている場合もあります。既存のスキルが見つかった場合は、構造化質問ツール（Cursor では AskQuestion、Claude Code では AskUserQuestion、OpenCode では question）を使って、ユーザーがすでに「スキルを更新して」などと伝えていない限り、意図を確認します。

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

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

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

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

並列処理を開始する前に、現在のワークスペースのトランスクリプトを特定します。そのワークスペースのディレクトリーのみを使ってください。すべてのプロジェクトのディレクトリーを横断して glob 検索しないでください。ワークスペースの境界を越え、無関係なプロジェクトのプライベートなチャットを読むことになります。トランスクリプトの保存場所はハーネスによって異なります。

• Cursor： システムプロンプトに、~/.cursor/projects/ 以下のワークスペースの agent-transcripts/ ディレクトリーが記載されています。
• Claude Code： ~/.claude/projects/<slug>/*.jsonl。<slug> は、ワークスペースのパスに含まれる英数字以外のすべての文字を - に置き換えたものです。
• Pi： ~/.pi/agent/sessions/--<slug>--/*.jsonl。<slug> は、ワークスペースのパスから先頭のスラッシュを取り除き、各 / を - に置き換えたものです。
• Codex： ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl。最初の行の payload.cwd がワークスペースのパスと一致するファイルのみを使用します。
• その他のハーネス： このワークスペース用のハーネスのセッションディレクトリー。

この範囲内にある最近のエージェントとの会話を調査し、繰り返し見られるパターンを探します。履歴を複数の期間に分けて、複数のサブエージェントを並列で実行します（例：直近 2〜4 週間を 3 つの期間に分け、各期間に十分な資料を割り当てます）。作業内容に応じて、poteto-mode スキルの Subagents セクションを参照し、各サブエージェントの推論レベルと速度（高速または標準）を選びます。各期間を担当するマイニング用サブエージェントは、親エージェントから指定されたワークスペース限定パスにあるトランスクリプトを読み、以下のシグナルを探し、根拠を示す参照先とともに、見つかったパターンを簡潔な構造化リストで返します。デフォルトで調べる価値のあるシグナルは次のとおりです。

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

シグナルを採用する前に、期間ごとの結果を照合します。2 つ以上の期間で見られるパターンは信頼度が高いと判断します。1 つの期間だけで見られるシグナルは根拠が弱いため、通常は採用しません。

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

まだ話題に上がっていない意図は、掘り下げても見つけられません。ゼロから入力してもらうのではなく、構造化された質問ツール（複数選択式の構造化質問。Cursor では AskQuestion、Claude Code では AskUserQuestion、OpenCode では question）を使います。利用中のハーネスに質問ツールがない場合は、番号付きの選択肢をチャットで提示します。

質問は1～2問とし、それぞれ選択肢を4～6個用意します。カテゴリについて尋ねる場合は複数選択を有効にします（Cursor では allow_multiple: true）。まず「どの領域が最も重要ですか？」のように広く尋ね、その後、選ばれた領域について具体的な選択肢で掘り下げます。構造化された質問を終えたら、選択肢でカバーできなかった点を拾うため、自由回答形式の質問をチャットで1つ尋ねます。

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

3. 調査結果を整理する

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

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

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

4. スキルを作成する

スキル作成スキル（create-skill）を使って、スキルを作成します。配置先：

• パス：既存のモードスキルがある場合は、そのカテゴリを維持します。新しいモードの場合、リポジトリにそのユーザー識別子用の既存カテゴリがあれば、<skills>/<handle>/<handle>-mode/SKILL.md を使います。そうでなければ、プロジェクト内の <skills>/<handle>-mode/SKILL.md をデフォルトとします。ユーザーが個人用スキルを希望する場合は、ユーザーレベルのスキルフォルダーを使います。<skills> は手順0で確認したハーネスのスキルフォルダーです。
• 識別子：ユーザーの名、またはユーザーが選んだ識別子を使います。
• フロントマターの description：ユーザーの名前、/<handle>-mode、および「その人のスタイルで作業する」をトリガーにします。「コードを書く」「PR をレビューする」のような汎用的なキーワードは使いません。
• フロントマターの形式：create-skill の YAML ルールに従います。句読点や折り返しの都合がある場合は、引用符で囲むか、インデントした続きの行を使う description: >- を指定し、description を1つの YAML スカラーにします。
• フロントマターの disable-model-invocation: true はデフォルトで有効にします。ユーザーが自分のモードをすべてのターンに適用するよう明示的に希望した場合のみ、無効にします。

5. 文章を反復的に磨く

すべての行に unslop スキルと create-skill の文章作成ガイドラインを適用します。

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

6. 仕上げる

main から worktree を作業用に作成します。コミットして PR を作成します。main に直接プッシュしてはいけません。

ガードレール

• 1回の会話に過度に適合させないでください。 一度だけ述べられ、その後の発言と矛盾する好みはノイズです。ルールとして記録する前に、複数回確認してください。
• 気の利いた表現を狙わないでください。 他のスキルの内容を言い換えて繰り返したり、比喩を作ったり、エージェント向けに「詩的な」文章を書いたりしても、コストに見合う効果はありません。実務的な内容にします。
• 内容を埋め込まず、参照してください。 ユーザーが使う他のスキルは、本文を貼り付けずパスを参照します。ユーザーが別途管理する原則文書も同様です。
• セクションは最小限にします。 ユーザーに固有の、デフォルトとは異なるルールがある場合にのみセクションを追加します。「明確に伝える」はセクションにしません。「短い段落にする。選択肢の比較には表を使う。箇条書きは項目が実際に並列の場合に限る。」はセクションにできます。
• 名前の表記は汎用的にします。 指示文では執筆者の名ではなく、「ユーザー」または「人間」を使います。
• 対称性を無理に求めないでください。 記載する価値のあるプロセスルールがユーザーにない場合は、プロセスのセクションを省略します。

評価

-mode スキルの出力は主観的です。create-skill のようなテストと反復のベンチマークループは役に立ちません。ユーザーに確認しましょう。自分らしい文章になっていますか？何か抜けていますか？問題なければ公開しましょう。

スキルのトリガー精度に実際に問題があるとわかった場合に限り、説明の最適化ループを実行してください。

使用しない場合

• ユーザーがタスク固有のスキル（作業上の慣習ではない）を求めている場合：マイニングは不要で、create-skill のみを使用します。
• ユーザーが特定のワークフローを1つだけ記録したい場合（例：「コミットメッセージの書き方」）：これは通常のスキルであり、モードスキルではありません。