所有者が手作業で繰り返し行なっている作業を、名前を付けた再利用可能なスキル（機能）に変換します。実際の作業を一度見せてもらうか説明を聞いた上で、変わる部分と変わらない部分を判断し、適切な場所に承認チェックポイント（判断フロー）を設けてスキルを作成。その後、ルーター（処理振り分け機能）に登録してチームで共有します。こうして企業は、誰も提供してくれなかったワークフロー（一連の作業手順）を手に入れられます。 **次のような場合に使用:** 所有者が反復的で自動化したいと思っている作業について説明してくるとき。特に以下のような表現が出たら活用してください： - 「毎週この作業をやっている」 - 「このやり方を覚えておいてほしい」 - 「これを簡単に実行できるようにしたい」 - 「エージェント（自動処理プログラム）を作ってほしい」 - 「これを自動化してほしい」 - 「これをワークフロー化してほしい」 - 「毎週月曜日にこれを実行したい」 自動化を明確に要求されなくても、所有者が定型的な作業を説明したら活用を検討してください。
Turns a task the owner keeps doing by hand into a named, reusable skill they can trigger by name or put on a schedule. Watches them do it once or listens to them describe it, works out what varies and what stays fixed, writes the skill with approval checkpoints in the right places, registers it with the router, and shares it with the team. This is how a business gets a workflow nobody shipped for them. Use this whenever the owner describes something repetitive they wish were automatic — including phrasings like "I do this every week," "can you remember how to do this," "make this a thing I can just ask for," "build me an agent," "automate this for me," "turn this into a workflow," or "I want this to happen every Monday." Reach for it when they describe a routine, even without asking for automation.
毎週オーナーが行なっている作業を、名前を指定して頼める機能に変える。
これにより、プラグインがあらゆる業種のワークフローに対応する必要がなくなります。どのカタログも、浄化槽業者の許認可手続きや保険代理店の保険会社手数料の照合といった作業には対応できません。その場合は、オーナー自身がこうした機能を構築できます。
2つの始め方があり、最初の方がずっと効果的です。
ベスト: 今の会話の中で実際にやってもらう。 オーナーがあなたと一緒にタスクを実行してくれたなら――ファイルを引き出し、判断を下し、あなたを2度訂正した――そのやり取りが仕様書そのものです。もう一度聞き直すのではなく、そこから抽出してください。オーナーが加えた訂正が最も貴重な部分です。それはオーナー自身も明示的には述べないような判断基準を含んでいるからです。
そうでなければ: 説明してもらう。 前回その作業をした時の流れを、具体的に歩んでもらうよう頼んでください。抽象的な説明より実際の詳細の方がはるかに有用です――「先週火曜日に保険会社ファイルを引き出して、予約分と照合し、6つの不一致を追っかけた」という話は「手数料を照合している」という説明より、ずっと多くの情報を伝えます。
詳しくは reference/capture.md を参照してください。根掘り葉掘り聞かずに全体像を把握する方法が書かれています。
このステップの本質がここにあります。前回のタスクの具体例をそのまま組み込んだ機能は、前回にしか使えません。
タスクの各部分について、以下のいずれかに分類してください:
オーナーがタスク実行を歩んでくれる際に加えた訂正が、通常は判断ポイントを示しています。「いや、その1つじゃない――50米ドル未満は全部スキップする」という言い方はルールです。「うーん、それによる」という言い方は承認ゲートです。
データを送信する、支払う、公開する、削除するステップには、すべて承認ゲートが必要です。オーナーが躊躇したステップにも承認ゲートを付けてください。
ただしすべてのステップにゲートを付けてはいけません。9回も承認を求める機能は、手作業でやるより悪いです。影響が大きい部分と判断が必要な部分にゲートを付け、その他は自動実行させましょう。
詳しくは reference/skill_authoring.md を参照してください。承認ゲートの配置場所と表現方法が書かれています。
このプラグインの他の機能と同じ形で実際の機能を作ります。つまり、メタデータ（付属情報）付きの SKILL.md と、必要に応じて reference/ フォルダを用意します。
すべての公開機能と同じ要件を満たす必要があります:
オーナーの言葉で書く。ビジネス用語で言い換えない。 オーナーが「キャリアファイル」と呼んでいるなら、機能でもそう言ってください。なじみのない言葉ばかりの機能は、オーナーが無人実行を信頼しません。
新しい機能を、オーナーが答えを既に知っているケースに対して実行してください――できればオーナーが実際に歩んでくれたそのケースがいいです。その出力と、手作業で得た結果を並べて見せてください。
このステップが、その機能が実際に使われるかどうかを決めます。既知の良好結果を再現するのを見たオーナーは、それをスケジュール化します。見ていないオーナーは毎回手動で実行し、毎回チェックします。その場合、何も節約されません。
結果が一致しなければ、機能を修正してもう一度実行してください。ほぼ合っているからといってオーナーに受け入れさせてはいけません。
smb-router（機能のルーティングシステム）に追加し、オーナーが実際に使う指定フレーズを記録します。
繰り返し実行されるタスクなら、スケジュール化を勧めてください。スケジュール化こそが「実行できる機能」を「自動で起動する仕組み」に変え、オーナーが望んだ成果をもたらします。
チームとの共有を勧めてください。何が共有されるのかを明確にしてください。誰がアクセスできるか、どのデータにアクセスできるか、無人で何ができるかを説明してください。
機能が送信、支出、または書き込みを行う場合、リスクについて具体的に述べてください。 顧客にメール送信する機能が、それを構築していない、その仮定を知らないオーナーのために実行されるのは、本当の危険です。 何らかのデータを送信する共有機能については、下書き限定を勧めてください。
オーナーは名前を指定して実行またはスケジュール化できる機能を手に入れました。新しい機能が接続されていないツールに触れた場合、「ERP システムに接続する」（build-connector）が次の自然な手順です。これで不足していたシステムが使用可能な情報源になります。近いステップとしては、新しい出力を日々の報告に組み込む「日次報告」や、週次報告に組み込むべき場合の「月曜報告」があります。最大3つまで、かつこのセッション中にオーナーが既に断ったものは勧めないでください。
reference/capture.md ―― 根掘り葉掘り聞かずにタスク全体像を把握する方法reference/skill_authoring.md ―― 機能の構造、メタデータ、承認ゲートの配置reference/gotchas.md ―― 誰も使わない機能を生む失敗パターンTurn something the owner does every week into something they ask for by name.
This is what keeps the plugin from having to ship every industry's workflow. No catalog can cover a septic contractor's permit routine or an insurance agency's carrier commission reconciliation. Those owners can build them.
Two starting points, and the first is much better.
Best: they just did it in this conversation. If the owner has walked through the task with you — pulled the files, made the decisions, corrected you twice — that transcript is the specification. Extract it rather than re-interviewing them. The corrections they made are the most valuable part, because they encode judgment the owner would never have thought to state.
Otherwise: they describe it. Ask them to walk through the last time they did it, concretely. Real specifics beat an abstract description every time — "last Tuesday I pulled the carrier file, matched it against what we'd booked, and chased six discrepancies" tells you more than "I reconcile commissions."
Read reference/capture.md for how to get a complete picture without an interrogation.
This is the whole craft of the step. A skill that hardcodes last Tuesday's specifics only works on last Tuesday.
For each part of the task, decide:
The corrections the owner made while walking through it usually mark the judgment points. When someone says "no, not that one — we skip anything under USD 50," that is a rule. When they say "hmm, depends," that is an approval gate.
Every step that sends, spends, publishes, or deletes needs a gate. So does every step where the owner hesitated.
Do not gate everything — a skill that asks permission nine times is worse than doing it by hand. Gate the consequential and the ambiguous, and let the rest run.
Read reference/skill_authoring.md for where gates belong and how to phrase them.
Produce a real skill in the same shape as everything else in this plugin: a SKILL.md with frontmatter and numbered steps, plus a reference/ folder if the detail warrants it.
Requirements it must meet, same as every shipped skill:
Write it in the owner's terms, not in generic business language. If they call it "the carrier file," the skill says carrier file. A skill full of unfamiliar vocabulary is one they will not trust to run unattended.
Run the new skill against a case the owner already knows the answer to — ideally the exact one they walked through. Show the output next to what they got by hand.
This is the step that determines whether the skill gets used. An owner who has seen it reproduce a known-good result will schedule it. One who hasn't will run it manually and check it every time, which saves nothing.
If it doesn't match, fix the skill and run it again. Do not ask the owner to accept a near-miss.
Add it to smb-router so plain-English requests reach it, and record the trigger phrases the owner actually uses.
If it is a recurring task, offer to schedule it. Scheduling is what converts "a skill I could run" into "something that happens without me," which is the outcome they wanted.
Offer to share with the team. Say what sharing means: who gets it, what data it can reach, and what it can do unattended.
Be specific about the risk when a skill sends, spends, or writes. A skill that emails customers, running for someone who did not build it and does not know its assumptions, is a real hazard. Recommend draft-only for shared skills that send anything.
The owner now has a named skill they can trigger or schedule. If the new skill hit a tool that isn't connected, "connect to my ERP" (build-connector) is the natural next step — it turns the missing system into a working source. Also nearby: "brief me" to fold the new output into the daily picture, and "Monday brief" if the skill should feed the weekly one. Offer at most three, and skip any offer the owner already declined this session.
reference/capture.md — getting a complete picture of the task without an interrogationreference/skill_authoring.md — the structure, frontmatter, and where approval gates belongreference/gotchas.md — the failure modes that produce a skill nobody uses原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。