automate-me

Automate me

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

このスキルは、ほかの3つのスキルをオーケストレーションします。インラインでの抽出処理（ステップ1を参照）、plugin-dev:skill-developmentスキル（作成）、そしてunslopスキル（文章の規律）です。これらを順序立てて実行します。置き換えるものではありません。

プラットフォームに関する注意。 CodexやClaude以外のランタイムでは、以下に記載されているClaudeのツール名、claude-*スラッグ、Claude組み込みスキル（plugin-dev:skill-developmentを含む）はClaudeの既定値です。codex-tools.mdで対応するものを確認してください。

フロー

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

ユーザーのハンドルに一致する.claude/skills/**/*-mode/SKILL.mdと~/.claude/skills/*-mode/SKILL.mdを再帰的に検索します。Modeスキルは最上位だけでなく、個人用カテゴリディレクトリ（.claude/skills/<handle>/）に置かれている場合もあります。既存のスキルが見つかった場合は、すでに「スキルを更新して」などと伝えている場合を除き、AskUserQuestionで意図を確認します。

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

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

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

1. 履歴を抽出する

並列処理を始める前に、アクティブなワークスペースのトランスクリプトを特定します。Claude Codeはトランスクリプトを~/.claude/projects/<encoded-cwd>/*.jsonlに保存します。ここで<encoded-cwd>は、ワークスペースの作業ディレクトリ内の/を-に置き換えたものです。このパスだけを使用してください。~/.claude/projects/全体を対象にグロブ検索してはいけません。ワークスペースの境界を越え、無関係なプロジェクトのプライベートなチャットを読み込んでしまいます。

この範囲内の最近のエージェントとの会話を調べ、繰り返し現れるパターンを探します。履歴を分割して複数のサブエージェントを並列で実行します（例：直近2〜4週間を、各スライスに十分な量のデータが含まれるよう3つに分割します）。サブエージェントの作業量は、poteto-modeスキルの「Subagents」セクションに従って調整します。各スライスを担当する抽出サブエージェントは、親エージェントから渡されたワークスペース内のパスからトランスクリプトを読み込み、以下のシグナルを探します。見つけたパターンを、根拠への参照とともに、短く構造化されたリストで返します。通常、次のようなシグナルを探します。

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

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

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

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

形式：各選択肢が4〜6個の質問を1〜2問します。カテゴリに関する質問ではallow_multiple: trueにします。まず「どの領域を最も重視しますか？」のような大まかな質問をし、選択された領域について具体的な選択肢で追加質問をします。構造化された質問の後に、選択肢で拾えなかった内容を確認する自由記述の質問を1つします。

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

3. クラスターの所見

統合されたシグナルをセクションにグループ化します。一般的なもの（該当するものだけを使用してください）:

• 応答スタイル: 長さ、トーン、フォーマット。
• 自律性: 尋ねずにどこまで行うか、MCP ツールの使用。
• まず理解する: 変更のスコープ設定や調査の際にどのスキルを活用するか。
• サブエージェント: デフォルト、並列性、モデルとタスクの対応、専門化されたワークフロー。
• 散文 / コードの規律: 原則、lint ツール、スタイルガイド。
• レビューと検証: 再現への姿勢、検証スキル、ライブテストツール。
• プロセス: git worktree、コミット、PR、レビュー/マージのツール。
• スキル: スキル作成の習慣、スキルを先に修正する、新しいスキルの提案。

poteto-mode スキルがその形を示しています。粒度についてはそれを読んでください。その内容をコピーしないでください。ユーザーのルールは poteto-mode のものと同じではありません。

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

plugin-dev:skill-development スキルを使用してスキルを作成します。配置:

• パス: 既存のモードスキルのカテゴリを維持します。新しいモードの場合、リポジトリにそのハンドル用の確立された個人カテゴリがあれば .claude/skills/<handle>/<handle>-mode/SKILL.md を使用します。そうでなければ、プロジェクト内の .claude/skills/<handle>-mode/SKILL.md（またはユーザーが個人スキルを希望する場合は ~/.claude/skills/<handle>-mode/）をデフォルトとします。
• ハンドル: ユーザーの名または選択した識別子。
• Frontmatter の description: 一般的なキーワード（「write code」や「review PR」など）ではなく、ユーザーの名前 + /<handle>-mode + 「work in their style」でトリガーするようにします。
• Frontmatter のフォーマット: plugin-dev:skill-development の YAML ルールに従ってください。description は 1 つの YAML スカラーとして保ちます。句読点や折り返しが必要な場合は、引用符で囲むか、description: >- とインデントされた継続行を使用してください。
• Frontmatter の disable-model-invocation: true をデフォルトとします。ユーザーが自分のモードを毎ターン適用することを明示的に希望する場合にのみオプトアウトしてください。

5. 散文を反復する

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

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

6. 仕上げる

main から分岐した worktree で作業します。コミットして PR を開きます。main に直接プッシュしないでください。

ガードレール

• 1 つの会話に過剰適合しないこと。 一度述べられ、別の時に矛盾された好みはノイズです。それを成文化する前に複数の事例を要求してください。
• 賢ぶらないこと。 他のスキルの内容を言い換えたり、比喩を発明したり、エージェントの読み手のために「詩的な」散文を書いたりすることは、利益のないコストです。操作的に保ってください。
• インライン化せず、参照すること。 ユーザーが依存する他のスキルは、貼り付けた抜粋ではなくパス参照として示すべきです。ユーザーが他所で管理している原則ドキュメントについても同様です。
• セクションを最小限に保つこと。 ユーザーがそこに特定の、デフォルトではないルールを持っている場合にのみセクションを追加してください。「Communicate clearly」はセクションではありません。「Short paragraphs. Tables when comparing options. Bullets only when items are genuinely parallel.」はセクションです。
• 命名規則を汎用的にすること。 命令形では作者の名ではなく「the user」または「the human」を使用してください。
• 対称性を強制しないこと。 ユーザーに書き留める価値のあるプロセスルールがなければ、Process セクションを完全にスキップしてください。

評価

-mode スキルは主観的な成果物です。plugin-dev:skill-development スタイルのテスト/反復ベンチマークループはここでは有用ではありません。ユーザーと雰囲気を確認してください: それは彼らのように読めますか？何か見落としていませんか？その後、出荷します。

スキルのトリガー精度が実際に問題になる場合にのみ、description 最適化ループを実行してください。

使用すべきでない場合

• ユーザーがタスク固有のスキル（作業の取り決めではない）を希望する場合: plugin-dev:skill-development のみで、マイニングは不要です。
• ユーザーが 1 つの狭いワークフロー（例:「コミットメッセージをどう書くか」）を記録したい場合。それは通常のスキルであり、モードスキルではありません。