automate-me

自動化する

太字またはバッククォートで示されたスキル名、あるいは /<name> として実行するスキルは、このスキルのディレクトリの隣にある ../<name>/SKILL.md ファイルです。接頭辞なしで示された原則名は ../principle-<name>/SKILL.md です。ファイルを読み、その指示に従ってください。pstack スキルの多くはユーザー専用のため、スキルツールでは読み込めません。すべての delegate_task 呼び出しには、../poteto-mode/SKILL.md の Subagents セクションにあるデフォルト設定が適用されます。

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

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

フロー

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

ユーザーのハンドルに一致する .agents/skills/**/*-mode/SKILL.md、.claude/skills/**/*-mode/SKILL.md、~/.agents/skills/*-mode/SKILL.md、~/.claude/skills/*-mode/SKILL.md を再帰的に検索します。同じ実体パスを指すエントリは、1 つのスキルとして扱います。Mode スキルはトップレベルだけでなく、個人用カテゴリディレクトリ（.agents/skills/<handle>/ または .claude/skills/<handle>/）にも配置できます。見つかった場合は、スレッド内で意向を確認してください（すでに「スキルを更新して」などと伝えている場合を除く）。

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

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

• ステップ 1 では、スキルが最後に編集されて以降の履歴だけをマイニングします（git log -1 --format=%cI <path>）。
• ステップ 2 では、ゼロから何を取り込むかではなく、何が変わったか、何が不足しているかを尋ねます。
• ステップ 4 では、まずスキルの実体ディレクトリが .agents/skills/ の下にあり、対応する相対パスの .claude/skills/ シンボリックリンクがあることを確認します（.claude/skills/ のみにあった場合は移動します）。そのうえで既存ファイルを直接編集します。ユーザーの新しい発言と矛盾しないセクションは維持します。新たな証拠があるセクションは修正します。本当に新しいルールに限り、セクションを追加します。

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

並行して調査を始める前に、現在のプロジェクトのスレッドを特定します。projectId を省略した t3_thread_list と t3_thread_search は、呼び出し元スレッドのプロジェクトを対象にします。そのスコープだけを使用してください。別の projectId を渡してはいけません。プロジェクトの境界を越え、無関係なプロジェクトの非公開チャットを読み込むことになります。

そのスコープ内の最近のエージェントとの会話を調べ、繰り返し見られる傾向を探します。履歴を複数の範囲に分け、それぞれに対して複数の delegate_task 子エージェントを並行して実行します（例：直近 2〜4 週間を 3 つに分割し、各範囲に十分な資料を確保します）。mode: "async" を指定し、範囲を示す title、再試行時も同じ値を使うその範囲固有の clientRequestId（新しいラウンドでは別の値）、そして target は指定せず、親モデルで実行します。各サブエージェントの推論レベルと速度（fast または standard）は、poteto-mode スキルの Subagents セクションに従って選びます。子エージェントにはブリーフだけが渡されるため、各範囲のブリーフには、親がその範囲について特定したスレッド ID を列挙し、「読み取り専用：調査のみ。書き込みや git コマンドは禁止」と記載します。また、「委任しないでください」と伝えます。各範囲を担当する子エージェントは、t3_thread_read でスレッドを読み、以下の兆候を探し、証拠の参照先を添えた傾向の短い構造化リストを返します。優先して探す兆候は次のとおりです。

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

ターンを終了し、完了通知が届くまで待ちます。すべての範囲から報告が届いたら、範囲をまたいで照合します。2 つ以上の範囲で見られた傾向は信頼度が高いと判断します。一度しか見られない兆候は根拠が弱いため、通常は採用しません。

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

まだ話題に上がっていない意図は、情報を集めても見落としてしまいます。ユーザーに一から入力してもらうのではなく、スレッドで構造化された選択式の質問を使い、率直に尋ねてください。

形式：選択肢を4〜6個用意した質問を1つか2つにします。カテゴリに関する質問では複数選択を可能にしてください。まずは「どの分野が特に重要ですか？」のように広く尋ね、その後、選ばれた分野について具体的な選択肢で掘り下げます。構造化された質問の後に、選択肢では拾いきれなかったことを聞く自由記述の質問を1つ加えます。

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

3. 見つかった情報を分類する

集まった情報をセクションにまとめます。よく使われる分類は次のとおりです（当てはまるものだけを使ってください）。

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

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

4. スキルを草案する

skill-creator スキルがインストールされている場合はそれを使ってスキルを作成し、ない場合は Authoring-a-skill プレイブック（../poteto-mode/playbooks/authoring-a-skill.md）を使ってください。配置場所：

• パス：既存のモードスキルがある場合は、そのカテゴリを維持してください。新しいモードを作る場合、ハンドル名に対応する既定の個人用カテゴリがリポジトリにあれば .agents/skills/<handle>/<handle>-mode/SKILL.md を使います。そうでなければ、プロジェクト内の .agents/skills/<handle>-mode/SKILL.md を既定の場所とします（ユーザーが個人用スキルを希望する場合は ~/.agents/skills/<handle>-mode/ を使います）。まず実際のディレクトリをその場所に作成し、その後、対応する .claude/skills/ 配下に相対シンボリックリンクを作成します（.claude/skills/<handle>-mode -> ../../.agents/skills/<handle>-mode。~/ 配下でも同様です）。
• ハンドル：ユーザーの名、またはユーザーが選んだ識別子を使います。
• フロントマターの description：ユーザーの名前、/<handle>-mode、および「その人らしいスタイルで作業する」をトリガーにします。「コードを書く」「PRをレビューする」のような一般的なキーワードは使わないでください。
• フロントマターの形式：skill-creator の YAML ルールに従います。句読点や改行の都合がある場合は、description を1つの YAML スカラーとして保ち、引用符で囲むか、インデントした継続行を使う description: >- 形式にします。
• デフォルトでフロントマターに disable-model-invocation: true を設定し、Codex でも非表示になるように agents/openai.yaml に policy.allow_implicit_invocation: false を追加します。ユーザーが自分のモードをすべてのターンに適用することを明示的に希望した場合に限り、どちらも無効にしてください。

5. 文章を推敲する

すべての行に unslop スキルと skill-creator のライティングガイドラインを適用します。草案をユーザーに見せ、フィードバックを受けてください。複数回の修正を想定します。徹底して削ぎ落としてください。モードスキルはマニュアルではありません。

6. 仕上げる

main から worktree を作業用に切り、変更をコミットして、gh pr create でPRを開き、すぐにそのURLを link_pull_request で紐づけます。main に直接プッシュしてはいけません。

ガードレール

• 1つの会話に過度に適合させないでください。 一度示された好みが別の機会に否定された場合は、ノイズです。ルールとして明文化する前に、複数の事例を確認してください。
• 気の利いたことをしようとしないでください。 他のスキルの内容を言い換えたり、比喩を作ったり、エージェント向けに「詩的な」文章を書いたりしても、コストに見合う効果はありません。実務的な内容にしてください。
• 引用して、本文に埋め込まないでください。 ユーザーが利用する他のスキルは、抜粋を貼り付けず、パスで参照してください。ほかで管理している原則のドキュメントについても同様です。
• セクションは最小限にしてください。 ユーザー固有の、既定ではないルールがある場合にのみ、セクションを追加してください。「明確に伝える」はセクションにする内容ではありません。「短い段落。選択肢の比較には表を使う。箇条書きは項目が実際に並列である場合のみ使う。」ならセクションにする価値があります。
• 名前の慣例は汎用的にしてください。 命令文では、作者の名前ではなく「ユーザー」または「人間」を使ってください。
• 対称性を無理に保たないでください。 書き留める価値のあるプロセスルールがない場合は、「プロセス」セクション自体を省略してください。

評価

-mode スキルは、出力が主観的なものです。skill-creator式のテストと反復によるベンチマークループは、ここでは役に立ちません。ユーザーに印象を確認してください。本人らしい文章になっていますか？ 見落としはありませんか？ それを確認したら仕上げます。

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

使用しない場合

• ユーザーが特定のタスク向けスキル（作業上の慣例ではない）を求めている場合：skill-creator のみを使い、情報の掘り起こしは不要です。
• ユーザーが「コミットメッセージの書き方」のような、限定的なワークフローを1つだけ記録したい場合。それは mode スキルではなく、通常のスキルです。