automate-me

Automate me

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

このスキルは、ほかの 3 つのスキルを連携させます。インラインでの抽出作業（ステップ 1 を参照）、../poteto-mode/playbooks/authoring-a-skill.md の作成ガイダンス、および unslop スキル（文章作成の規律）です。これらを順序立てて実行します。それぞれのスキルに取って代わるものではありません。

フロー

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

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

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

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

• ステップ 1 では、スキルが最後に編集されてからの履歴のみを抽出します（git log -1 --format=%cI <path>）。
• ステップ 2 では、ゼロから何を記録するかではなく、何が変わったか、何が不足しているかを尋ねます。
• ステップ 4 では、既存のファイルを直接編集します。ユーザーの新たな発言と矛盾しないセクションは保持します。新たな根拠があるセクションは修正します。本当に新しいルールがある場合に限り、新しいセクションを追加します。フロントマター内の disable-model-invocation 行は、ステップ 4 で説明するゲートに置き換えます。

1. 履歴を調べる

pstack-harness スキルを使い、並行して調査を始める前に、アクティブなワークスペースのトランスクリプトを特定します。このワークスペースのストアのみを使用してください。他のワークスペースのセッションは読まないでください。これはワークスペースの境界を越え、無関係なプロジェクトのプライベートなチャットを読むことになります。

その範囲内で、最近のエージェントとの会話を調査し、繰り返し見られるパターンを探します。routine ロールで複数のサブエージェントを並列に実行し、履歴を複数の期間に分けます（例：直近 2～4 週間を 3 つに分け、各期間に十分な資料を確保します）。ロールの解決には、pstack-harness スキルの Spawn a role セクションを使います。各期間を担当する抽出用サブエージェントは、親エージェントから指定されたワークスペース限定のパスにあるトランスクリプトを読み、以下のシグナルを探し、根拠への参照とともに、見つけたパターンを簡潔な構造化リストで返します。通常、調査する価値のあるシグナルは次のとおりです。

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

シグナルを採用する前に、複数の期間にわたって照合します。2 つ以上の期間で見られたパターンは、信頼度が高いと判断します。単独で見られたシグナルは根拠が弱いため、通常は採用しません。

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

履歴の調査だけでは、まだ話題に上がっていない意向を把握できません。ユーザーに一から入力してもらうのではなく、AskQuestion ツールを使って、選択肢形式の質問をします。

形式：各質問に 4～6 個の選択肢を設け、質問は 1 つか 2 つにします。カテゴリに関する質問では allow_multiple: true を設定します。まず「どの領域が最も重要ですか？」のような幅広い質問をし、選ばれた領域について具体的な選択肢で追加質問します。選択肢形式の質問を終えた後、選択肢で拾えなかった内容を確認するため、自由形式の質問をチャットで 1 つします。

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

3. 調査結果を分類する

統合したシグナルをセクションにまとめます。一般的な項目は次のとおりです（該当するものだけを使ってください）。

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

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

4. スキルを作成する

../poteto-mode/playbooks/authoring-a-skill.md に従ってスキルを作成します。配置先：

• パス：既存のモードスキルがある場合は、そのカテゴリーを維持します。新しいモードの場合、リポジトリにそのハンドル用の個人カテゴリーが確立されていれば .agents/skills/<handle>/<handle>-mode/SKILL.md を使います。そうでなければ、プロジェクト内の .agents/skills/<handle>-mode/SKILL.md をデフォルトとします（ユーザーが個人用スキルを希望する場合は ~/.agents/skills/<handle>-mode/ を使います）。
• ハンドル：ユーザーの名、またはユーザーが選んだ識別子。
• Frontmatter の description：一般的なキーワード（「コードを書く」「PR をレビューする」など）ではなく、ユーザーの名前、/<handle>-mode、「その人のスタイルで作業する」をトリガーにします。
• Frontmatter の形式：有効な YAML を維持します。句読点や折り返しが必要な場合は、description を単一の YAML スカラーとして保ち、引用符で囲むか、インデントした継続行を使う description: >- 形式にします。
• デフォルトではスキルの読み込みを制限し、ユーザーがスキル名を入力するか、別のスキルがそのスキルを指定した場合にのみ読み込まれるようにします。Codex で読み込みを制限するため、SKILL.md と同じ場所に agents/openai.yaml を作成し、policy: の下に allow_implicit_invocation: false を記述します。Claude Code では、setup-pstack のステップ 0c が pstack のスキルに対して行うように、ユーザーの ~/.claude/settings.json の skillOverrides に "<handle>-mode": "name-only" を追加するか確認します。ユーザーが同意した後にのみ項目を書き込み、その他のキーはすべて維持します。disable-model-invocation は決して書き込まないでください。Claude Code の Skill ツールが、別のスキルから指定されたときにこのスキルを使えなくなります。ユーザーが自分のモードを毎ターン適用することを明示的に希望した場合に限り、この制限を外します。

5. 文章を推敲する

作成用プレイブックの執筆ガイドラインに従い、すべての行に unslop スキルを使います。

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

6. 仕上げる

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

ガードレール

• 一度の会話に過剰適合しない。 一度だけ述べられ、別の機会に矛盾した好みはノイズです。明文化する前に複数回確認してください。
• 気の利いた表現を狙わない。 他のスキルの内容を言い換えたり、比喩を作ったり、エージェント向けに「詩的な」文章を書いたりするのは、効果に見合わないコストです。運用に役立つ内容にします。
• 埋め込まずに参照する。 ユーザーが利用する別のスキルには、「 スキルを使ってください。」のように、そのスキルの名前だけを使って言及します。例：「unslop スキルを使ってください。」作成用プレイブックに従い、内容を抜粋して貼り付けてはいけません。ユーザーが別の場所で管理する原則のドキュメントは、パスで参照します。
• セクションは最小限にする。 ユーザー固有の、デフォルトではないルールがある場合にのみセクションを追加します。「明確に伝える」はセクションにしません。「短い段落を使う。選択肢を比較するときは表を使う。箇条書きは項目が実際に並列関係にある場合に限る。」はセクションにできます。
• 命名規則は汎用的にする。 命令文では作成者の名前ではなく、「ユーザー」または「人間」を使います。
• 対称性を無理に整えない。 書き留める価値のあるプロセス上のルールがなければ、「プロセス」セクションは省略します。

評価

-mode スキルは主観的な出力です。テストと反復によるベンチマークループは役に立ちません。ユーザーに雰囲気を確認してもらいましょう。ユーザーらしい文章になっていますか？何か見落としていませんか？それからリリースします。

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

使用しない場合

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