automate-me

自分向けに自動化する

Codex では、このスキルに従う前に、スキルごとの注記を含めてプラットフォームマッピングを読んでください。

GitHub Copilot では、このスキルに従う前に、スキルごとの注記を含めてプラットフォームマッピングを読んでください。

Muse では、このスキルに従う前に、スキルごとの注記を含めてプラットフォームマッピングを読んでください。

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

このスキルは、3 つのスキルを組み合わせて進行します。インラインでの情報抽出（ステップ 1 を参照）、plugin-dev:skill-development スキル（作成）、そしてunslopスキル（文章の規律）です。これらを順番に実行します。置き換えるものではありません。

フロー

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

ユーザーのハンドルに一致する .claude/skills/**/*-mode/SKILL.md と ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/*-mode/SKILL.md を再帰的に検索します。モードスキルはトップレベルだけでなく、個人用のカテゴリディレクトリ（.claude/skills/<handle>/）にも置かれることがあります。見つかった場合は、ユーザーがすでに「スキルを更新して」などと伝えていない限り、AskUserQuestion で意向を確認します。

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

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

• ステップ 1 では、スキルの最終編集以降の履歴のみを調べます（git log -1 --format=%cI <path>）。
• ステップ 2 では、何を新たに記録するかではなく、何が変わったか、何が不足しているかを尋ねます。
• ステップ 4 では、既存のファイルを直接編集します。ユーザーの発言と矛盾しないセクションは保持します。新しい証拠があるセクションは修正します。新しいセクションを追加するのは、本当に新しいルールがある場合に限ります。

1. 履歴を調べる

並列調査を始める前に、アクティブなワークスペースのトランスクリプトを特定します。Claude Code は ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/<encoded-cwd>/*.jsonl に保存しています。<encoded-cwd> を手作業で組み立てるのではなく、node <plugin>/skills/reflect/scripts/claude-project-dir.mjs を実行して、このセッションのディレクトリを出力します。そのパスのみを使用してください。${CLAUDE_CONFIG_DIR:-$HOME/.claude}/projects/ をまたいで glob 検索しないでください。これをするとワークスペースの境界を越え、無関係なプロジェクトのプライベートな会話を読み込んでしまいます。

この範囲内にある最近のエージェントとの会話を調査し、繰り返し現れるパターンを探します。履歴を複数の区間に分け、複数のサブエージェントを並列実行します（例：直近 2～4 週間を 3 区間に分け、各区間に十分な資料を割り当てます）。poteto-mode スキルの「サブエージェント」セクションに従って、作業に適した推論レベルを各サブエージェントに設定します。各区間を担当するサブエージェントは、親エージェントから指定されたワークスペース限定のパスにあるトランスクリプトを読み、以下の兆候を探します。見つけたパターンを、証拠への参照を添えて短い構造化リストにまとめます。既定で探す兆候は次のとおりです。

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

シグナルを採用する前に、区間をまたいで照合します。2 つ以上の区間で見られたパターンは、信頼度が高いものとして扱います。一度しか見られないシグナルは弱いため、通常は採用しません。

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

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

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

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

3. 調査結果を整理する

組み合わせたシグナルをセクションにまとめます。一般的な項目は次のとおりです（該当するものだけを使います）。

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

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

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

plugin-dev:skill-development スキルを使って、スキルを作成します。配置場所：

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

5. 文章を推敲する

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

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

6. 仕上げる

main からワークツリーを作成して作業します。コミットして PR を開きます。main に直接プッシュしてはいけません。

ガードレール

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

評価

-mode スキルは主観的な出力です。plugin-dev:skill-development 流のテスト／反復ベンチマークループは役に立ちません。ユーザーに印象を尋ねます。自分らしい文章になっていますか。見落としはありませんか。それから仕上げます。

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

使用しない場合

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