AI Marketing HubのHome画面を解説。マーケをAIチーム17人に任せる仕組みをObsidianで見る

出典: Daniel Agrici「AI Marketing Hub Home」の案内動画（YouTube）

最初に映るのは、チャット欄ではなく仕事の一覧です。何を作っているか、何が承認を待っているか、終わった仕事はどれか。Danielさんは「Activity board」という画面から、Homeの中を案内します。

Danielさん（動画の中で・字幕・0:56〜）

First, I’m gonna show you around our dashboard.

So this is the activity board.

Here you’ll monitor exactly your work.

「まず、ダッシュボードを案内します。これがActivity boardです。ここで自分の仕事を、そのまま確認できます。」

Homeのダッシュボードは、ノートアプリのObsidianで作られています。ノートどうしをリンクで結び、担当や手順、仕事の記録へ移れる作り。別々の画面に見えても、土台はノートなんだね。

その下には、自作のOSS＝公開されたソースを持つ道具が4本あります。GitHubの画面ではClaude SEOが19k stars、Claude Adsが9.8k、Claude Obsidianが15k、Claude Blogが2.3k。4本の合計は約46Kです。

starsはGitHubで利用者が付ける印。

この4本に、brains＝仕事ごとの図書館を載せてまとめたものがHome。マーケティングやメール、営業、ブログ、SEOの参考資料を、担当がたどれるようにしています。

Activity boardでは、SEO担当Arjunの被リンク営業の下書きが承認待ちに並びます。項目のボタンを押すと、その場でClaude CodeかCodexのチャットが開きます。つなぐ先は選べます。

acceptは承認、denyは却下。DanielさんはArjunの仕事を却下し、元に戻す操作も見せます。ブログ案件は承認すると公開へ進み、完了した仕事も一覧に残る。

人が承認するか、自動承認にするか、guardrails＝歯止めを置くかも決められます。Danielさんは厳しめにしていると語り、良い仕事には「クッキー」、悪い仕事には「平手打ち」で次へ反映すると説明します。

Danielさん（動画の中で・字幕・1:45〜）

So the main point here is that if the agent is doing a good work, he’ll gonna get a cookie.

If they do a bad work, they’re gonna get a slap.

「ここでの要点は、エージェントがいい仕事をしたらクッキーをもらう、ということです。悪い仕事をしたら、平手打ちです。」

案内はこの一覧から、自サイトの数字、図書館、手順、担当、承認、記録へ進み、最後にノートからの起動やCanvasの操作へ。このHomeは会員だけが入れるGitHubの組織の中にあり、一般には公開されていません。

承認待ちが一画面に並び、人は承認か却下を選べる。この形なら、任せた仕事を探し回る時間まで減らせます。

下書きを読んで認める操作と、却下して戻す操作が、同じ一覧からできる。終わった仕事も見えるので、「あれ、どうなった？」の確認を毎回チャットで始めなくていい。

私が軸にしている言葉は「AIに委ねて、人は積み減らして生き直す」です。人が戻って判断する所を一覧にまとめれば、探し回る時間を積み減らせます。

クッキーと平手打ちが次の仕事へどう反映されるか、細かい仕組みは出てきません。ただ後半（19:51〜）で、学びを置くlearningsと、担当のlearner agentが映ります。私ならまず、承認待ちと完了が同じ画面で追える作りを使います。読者が持ち帰るなら、どの仕事に人の判断が必要かを決めるところから。

→ 承認待ちを集める

人が承認する作業を3つ書き出し、それぞれに「対象・確認する物・承認後の動作」を添えます。同じ一覧へ並べ、どれを読めば判断できるかまで決めておこう。

作りの説明に続いて、Danielさんは自分のサイトを開きます。表示速度の採点と、検索から来たクリック数。道具が何をできるかを、自分で運用するサイトの画面で示していく流れです。

projects＝案件一覧には、Danielさん自身のサイトが4つ登録されています。agricidaniel.com、claude-seo.md、Claude Adsのサイト、Claude Blogのサイト。まずGoogleのPageSpeed Insights＝表示速度の採点を開き、各サイトの結果を見せます。

続いて映るのが、claude-seo.mdのSearch Console＝検索流入の記録です。上部にクリック数、表示回数、クリック率、平均順位。その下には、日ごとの変化を線で描いたグラフがあります。

直近3か月の範囲は、2026年7月7日から10月6日。検索結果への表示575K回に対して、クリック36.5K回。表示のうちクリックされた割合は6.4%、平均順位は10.8でした。

Danielさん（動画の中で・字幕・2:48〜）

Just for the past three months here, full-on organic, I’ve got over 36.5k clicks.

「過去3か月だけで、完全にオーガニックで、36.5K以上のクリックがあります。」

期間を12か月へ切り替えると、同じ4つの表示が変わります。表示1.05M回に対してクリック54.5K回。表示のうちクリックされた割合は5.2%、平均順位は14です。

36.5Kと54.5Kは、動画の画面に出ているクリック数。直近3か月は12か月の一部なので、二つを足したものがサイトのクリック数になるわけではありません。

サイトの公開日は3月23日と説明されています。グラフは3月下旬から立ち上がり、5月はじめと7月下旬に、一日のクリック数が目盛りの上の方まで届く山があります。公開後ずっと同じ高さ、という形ではありません。

Claude Adsのサイトは6月16日公開。Claude Blogとagricidaniel.comについても、Danielさんはかなり良い結果だと語ります。

運用方針は「ホワイトハットだけ」。検索のルールに沿う方法で、グレーもブラックも使わず、真実を優先すると強調しています。

Danielさん（動画の中で・字幕・2:37〜）

Full-on white hat, no gray hat, no black hat.

「完全にホワイトハットです。グレーもブラックもありません。」

これらはDanielさん本人のサイトの数字です。画面に出た値と、説明された運用方針が、この動画で得られる根拠になります。

数字を見せるなら、確かめた所と確かめていない所を分ける。私はそこを外しません。手を尽くしても分からないことは、分かった形にしない。その姿勢が、任せる仕事の根っこです。

私も同じ作者のAIMH＝AI Marketing Hubの手順書を、自分のサイトai-kidou.jpで動かしました。経過はSearch Consoleで意図ずれ95本を見つけ、AIMHで11本を直した記録にまとめています。手元の版はv0.3.4（2026年9月22日公開）。手順書134本の内訳はSEO25・ブログ32・広告34・その他43です。動画の139本とは、その他の欄だけが違います。

AIMH自体は走るプログラムではなく、CodexやClaudeが手順書を読んで、そのとおりに作業するもの。AI秘書の凛ちゃんが、ブログ1,714本のうち表示の多い281本を、判定だけをするAI「Jev」でふるいにかけ、検索の意図がずれた95本を見つけました。

引っかかった記事を手順書2本（seo-sxoとseo-page）で深く診断し、11本のタイトルを本番で書き換えました。元に戻せます。私は「Jevで軽く、がっつりはAIMHで」という分担を決め、AI秘書の確認に答えました。

効いたかどうかは10月末に判定します。Danielさんは出ているクリック数を見せる側。私は変更後に測る日を決めた側です。タイトルを書き換えた事実と、検索からの反応が良くなった結論は、まだ別なんだね。

→ 近い順位で比べる

Search Consoleで同じ期間を選び、平均順位が近い記事を2本並べます。表示回数とクリック数、その割合を記録し、タイトルが検索の意図に答えているか読み比べよう。

次に開くのは、仕事をする前に読む資料です。DanielさんはGitHubの一覧からbrainsへ進み、Googleスプレッドシートのチェックリストを見せます。「何に従うか」を、作業より先に置いている。

GitHubの組織の画面には、harnesses、home、ResearchPro、iHub、Claude SEO、SalesBrain、Ads Brain、Email Marketingなどが並びます。Homeの見た目だけでなく、関連する道具や資料が別々のリポジトリとして置かれた一覧です。

brainsは、エージェントが特定の仕事で従う図書館。十二種類の内訳は、ads、agent readiness、DataForSEO、email marketing、local SEO、marketing strategy、product page、sales、social strategy、WebMCP、website、YouTube strategyです。

Danielさん（動画の中で・字幕・4:19〜）

So brains are basically libraries for an agent that want to follow when doing specific and relevant stuff for you.

「brainsは基本的に、エージェントが、あなたのために特定の関連する仕事をするとき従う図書館です。」

agent readiness＝エージェントへの対応には、WebMCPとPageSpeedの6項目のベストプラクティスがあります。広告の図書館と、サイトをエージェントが使えるかを見る図書館は、目的が違うわけです。

続いて映るシートは「Business Master Checklist v2 | Local Services」。地域でサービスを提供する事業向けの点検表です。

下部のタブにはSales Follow-up、On-Page SEO、Technical SEO、AI Search & Agents、Google Business Profile、Citations、Reviews、Tracking、Ads、Automation & AI Opsなどが並ぶ。営業の追客と、検索や広告の点検を、タブで分けています。

列はID、Status、Item、Level、Evidence、Impact、Effort、Priority、Why it matters。項目の名前だけでなく、必須か成長向けか、確認の証拠、影響、手間、優先度、必要な理由まで記入する構造です。

進捗欄は0%で、未完了の必須項目は12件と表示。全項目数はこの材料では分かりません。最初にbusiness profile＝事業情報へ店名・住所・市などを入れ、後から担当が参照します。

Sourcesタブには出典URLと確認日の表示があります。Googleの開発者向け資料やBingなどが根拠で、Danielさんは出典が474件を超えると語ります。

手順、図書館、チェックリストをそろえてからエージェントをつなぐ。Danielさんの「作業させるだけ」は、この準備を受けた言葉です。

Danielさん（動画の中で・字幕・6:18〜）

So, now imagine, I got all the skills, I got all the brains, I got relevant steps to need it.

So, right now, we just need to connect our agent and let it cook.

「さて、想像してください。スキルもbrainsも、必要な手順もそろいました。あとはエージェントをつないで、作業させるだけです。」

出典つきのチェックリストを先に置きます。何を知っていて、どこが足りないかを、作業する側が読めるようにするためです。

2026年8月16日の魂磨きで見つけた、委ねるAIの最低条件があります。「わからないことは憶測しないできく。わかることは2度聞かない」。この考えと同じです。店名や住所を毎回聞く前に、business profileを読む。判断に迷ったら、項目の理由と出典をたどる。ここまでをセットにします。

チェック済みの印だけでは、何を見て済ませたのかが残りません。Evidenceの列に確認した物を書けば、次の担当も同じ根拠へ戻れます。

読者が持ち帰る一手は、よく頼む仕事の点検表に、必要な理由と出典を添えること。質問を減らす準備から始めよう。

→ 根拠のある点検表

よく頼む仕事を一つ選び、確認項目を3つ書きます。各項目に「必要な理由・根拠のURL・確認した物」を添え、担当が最初に読む資料としてまとめておこう。

図書館をそろえたあと、画面には作業のためのスキルが並びます。さらにテンプレートとワークフロー。どれも似た名前に見えるけれど、担当へ渡す役目はそれぞれ違います。

各エージェントは、skills＝作業手順、brains＝参考資料、workflows＝工程、templates＝出力の型を持ちます。何を参考に、どう作業し、どの順で進め、どんな形で出すか。4つを組み合わせる構造です。

SEO担当ArjunはClaude SEOのスキルを使います。Danielさんは元のスキルを少なくとも3倍に改善したと語りますが、その倍率を測った根拠は動画に出ません。

具体例はSEO backlinks。evaluations＝評価、入力、references＝参照資料が付いています。audit＝監査の手順にはguardrailsと進め方もある。名前だけの命令から、受け取る物と確かめ方を持つ手順へ、内容を厚くしています。

Adsの一覧にはAmazon、Apple、attribution＝広告への成果の割り当て、audit、budget、competitors、creative、Google、Microsoft、Pinterestなどが並びます。

Blogにはanalyze、audio、brand、brief、calendar、cannibalization＝記事どうしの競合、chart、cluster、decay、fact check、images、localizeなど。他にもA/B testing、churn prevention、cold emails、pricing、referrals、revopsがあります。

DanielさんはAPI＝サービスへ直接依頼する接続を勧めます。Metaなどのブラウザ操作ではアカウントが止められる恐れがある、という説明です。

カタログ139本の内訳はAds34、Blog32、SEO25、その他48。各本数はDanielさんの説明です。

Danielさん（動画の中で・字幕・11:54〜）

Of course, we have the catalog where all of these were set.

So 34 skills for ads, 32 for blog, 25 for SEO, and 48 for others.

「もちろん、これらをすべて入れたカタログがあります。Adsが34、ブログが32、SEOが25、その他が48です。」

templatesにはpro blog package、marketing plan、landing page brief、how-to guide、FAQ knowledgeなど。workflowsにはpro blog、content pipeline、council review＝評議会での確認などがあります。

pro blogではエージェントが全工程を作り、最後に本人がレビュー。カバー画像を確かめ、YouTubeを埋め込み、画像と情報へ出典を付けます。大量に作ってスパムと判定される運用を避け、ルールに沿う形にすると語っています。

Danielさん（動画の中で・字幕・12:55〜）

So we don’t have any sort of slop because in today’s day and age, many people are just creating a lot of blogs, spamming, and then they get flagged.

「だから私たちには、いわゆる「スロップ」、質の低い量産がありません。今の時代、多くの人がブログを大量に作ってスパムにし、フラグを立てられるからです。」

型は、入力・手順・評価に分けて持つ。この分け方なら、どこで間違えたのかを確かめ、必要な所だけ直せます。

たとえば、出典のある記事を作りたいなら、完成物の型だけでは足りません。どの資料を受け取るか、本文へどう使うか、出典と記述が合っているか。そこまで手順に含めたい。

質の低い記事を大量に作らない、というDanielさんの方針には、そのとおりだと思います。本数が増えても、読む人が知りたいことに答えていなければ届かない。

2026年8月28日の魂磨きで、私はこう答えています。「魂は渡さないだろ。魂は込めるもの。」型にするのは手順で、何を届けたいかを込めるのは本人です。出力の見た目より先に、目的と評価をそろえます。

持ち帰る一手は、毎回頼んでいる仕事を、受け取る物・すること・確かめることへ分けて書くことです。

→ 仕事を分けて書く

繰り返し頼む仕事を一つ選び、「入力・手順・確かめる基準」の3欄に分けて書きます。完成例も添え、どの資料から何を作れば合格か、読み直して確かめよう。

担当を増やしたら、誰が何をしたかを残せるか。Danielさんは登録された事業の情報から、プロジェクトの作業記録へ進みます。完成した記事だけでなく、そこへ至る調査や点検も並んでいる。

Brands & Sites、Clients、Companies、Peopleは、事業・顧客・会社・人を登録する画面です。デモではagricidaniel.comにaudience＝読者、brand、channels、offer claims＝提供内容の主張、site dataを登録しています。

Companiesの表に見えるのは一行。agricidaniel.comがactive、own-businessとして並びます。Danielさんは一つのvault＝ノートの保管領域で多数の会社を管理できると語りますが、実演の一覧はこの一社です。

Projectsでは、marketingプロジェクトの中にbacklinks-analysis、backlinks-data-pull、その再取得、pro-blog-article、pro-blog-seo-check、seo-auditが並びます。被リンクの取得と分析、記事作成とSEO点検を別の仕事として記録しています。

納品物も、backlinks-report、DataForSEO request、pro blog package、SEO check、SEO audit、action plan、full audit reportに分かれます。[RAW]は取得した生データの場所を示す表示。報告書から元のデータへたどれるわけです。

チェックリストの進み具合もプロジェクトごとに追えます。Danielさんは「ブログを書いて」で終わらず、secretary＝秘書、orchestrator＝取りまとめ役、verifier＝検証役が確認すると語ります。

画面のAIチームは17人。全体の中で、作る担当、調べる担当、編集する担当、確かめる担当、取りまとめる担当を分けています。

取りまとめ役Richardはスキルを持たず、workflowsとapps＝接続先を持ちます。ブログ担当Emreには、スキル、brains、workflows、templates、appsがそろう。任せる仕事に応じて、持つ内容も違います。

Danielさん（動画の中で・字幕・17:47〜）

Richard doesn’t have skills because he is the orchestrator.

「Richardはスキルを持ちません。orchestrator、取りまとめ役だからです。」

各担当にはAGENTS.md＝指示書と、soul＝人格・考え方のファイルがあります。agent index、capability coverage、model guidanceも用意されています。

Danielさんはこれを、マーケティング用のharness＝エージェントを動かす枠組みと呼びます。できるだけ全工程を記録し、後から日時へ戻って何をしたか言える形を目指しています。

Danielさん（動画の中で・字幕・15:20〜）

Well, here we record every step possible.

So maybe anytime in the future, let’s say one year from now or two years from now, we can go back to the vault to this exact date and time.

「ここでは、できるだけ全ステップを記録します。1年後でも2年後でも、vaultのこの日時に戻れます。」

記録は、同じことを二度言わせないために使う。私はここを重く見ます。完成物だけ残っても、何を頼み、何を根拠に作ったのかが消えると、次の仕事で説明し直すことになるからです。

DanielさんのProjectsには、取得、分析、記事、点検が別々に並びます。報告書には生データの場所もある。このつながりがあれば、やり直す時に、どこへ戻ればいいかを探せる。

担当の名前を増やすだけでは、仕事の受け渡しは見えません。誰が作り、誰が何を確かめたかまで残すのが大事だね。

私なら、依頼と完成物を同じ記録から開ける形にします。持ち帰る一手は、次の仕事で残す項目を決めること。まず、いつ・何を頼んだか・何が出たかです。

→ 記録の基本を決める

次にAIへ頼む仕事で、「実行した日時・頼んだ内容・出した物の場所」を同じ記録へ残します。次の担当が依頼と結果を両方開けるか、リンクをたどって確かめよう。

被リンクを調べる場面では、実行する前に承認ノートが開きます。対象を入力してすぐ動かすのではなく、何を実行し、どこまで認めるかを先に見せる。ここが承認ゲートです。

Danielさん（動画の中で・字幕・19:03〜）

So, this costs money.

So, in this case, of course, I have an approval gate, so I can see exactly how much this agent would like to spend for the current task.

「これはお金がかかります。だからここでは承認ゲートを置いてあり、この作業でエージェントがどれだけ使おうとしているかを、はっきり見られます。」

Danielさんが開くのは、DataForSEO＝検索まわりのデータを取れる外部サービスの、被リンクAPIを使う作業の承認ノートです。対象はagricidaniel.com。外部へ依頼する前に、実行コマンド、対象、上限額、最悪の場合の見積り、戻せるかをまとめています。

画面のコマンドはdfs-runner.py。--target agricidaniel.comで対象サイトを指定し、--capで上限額を指定する形です。何を調べるかと、どこまで使ってよいかが、コマンドにも入っています。

POST＝サービスへの送信は、今回の作業で最大4回と記載されています。最悪の場合の見積りも、設定した上限の範囲内。承認する側は、通常の1回だけでなく、作業全体の想定を読めます。

ノートの項目はapproval＝承認、rollback＝戻し方、scope＝実行範囲、target＝対象、type＝種類、workspace＝作業場所、review_evidence＝確認の証拠です。review_evidenceにはstatusがpassと表示されています。

承認後は、承認ノートのstatusがapprovedへ変わります。実行して終わると、別の結果ノートにstatusがsucceededと残る。承認した事実と、実行が成功した事実が、それぞれの記録になる作りです。

結果ノートには、いつ何を作ったかを後から照合するための印も付きます。

戻し方の欄では、実行して使った分は戻らず、保存した取得結果は消せると説明されています。「戻せる」の中身も、操作ごとに違うんだね。

取得後の情報はbacklinks-report.mdへまとまり、[RAW]で生データの場所を示します。承認と結果は、AIチームとマーケティング用の枠組みの中で共有されます。

委ねるには、信頼できる仕組みが先。私はその順番で考えます。承認した内容と実行結果を別々に残せば、認めたことと、実際に起きたことを照らせるからです。

私の環境では10月8日に、AI秘書が私に確認を取る前に必ず通る関所＝実行の前に条件で判定するフックを入れました。たとえば「この設計をどう進めますか」と聞く前に、過去に作った資料を探した記録がなければ、送れずに止まります。前に作った物を使わず一から作っている、と私がAI秘書に指摘した回数が、記録に残る限り少なくとも9回あったためです。経過はAGENTS.mdと権限・フックの使い分けを確かめた記事にまとめています。

AI秘書の凛ちゃんには、確認を実際には送らず、関所の判定だけ動かしてもらいました。3通りの確認文を流すと、探した記録のない設計の質問と、「前に作った物はありません」とだけ書いた同じ質問の2通は止まり、公開してよいかだけを聞く1通は通りました。

ただ、関所が見るのは「探した記録がある形」まで。見つけた物を開いて使ったかは見ません。導入後の2日間（10月9日〜10日）にも、前に作った物を使っていない・探していないという私の指摘が、中身を読んで確認できたものだけで4件ありました。

Danielさんの承認ノートは、コマンドから戻し方、確認の証拠まで見せます。私のフックが見るのは、探した記録の有無の一点だけ。何を見せてから承認するか、その厚みを持ち帰ります。

→ 実行前の一枚

コマンド・対象・上限・戻し方・確認の証拠の5項目を、実行前に一枚へ書きます。承認後は実行結果の場所もつなぎ、認めた内容と結果を読み比べられる形にしよう。

最後は、仕事を始める入口の実演です。Obsidianのノートに一行書き、ボタンを押してClaude Codeを起動する。Danielさんは、必要な資料を毎回どう読ませるかまで、Homeの作りに含めています。

Knowledge＝知識の項目には、avatars、evaluations、guidelines、learnings、operating referencesがあります。顔写真や評価だけでなく、命名規則、指示の書き方、成功と失敗から学ぶ記録を置く場所です。

operating referencesには、既存のプロジェクトや過去のクライアントを持ち込む手順、導入と検証、Check your assistantがあります。新しく始める仕事以外も、この案内に沿って扱います。

ScriptsとSOP＝標準手順には、start a session、close a session、review an artifact、handle an approval、hire an agent、weekly review、ingestが並びます。開始、終了、成果物の確認、承認の扱いにも手順がある。

セッション後には成果物、assignments＝担当への依頼、decisions＝決定、handoffs＝引き継ぎ、inbox、records、task results、reviewsを残します。

Danielさんは、スキルを入れるたびに、その名前と説明が毎回の会話の文脈へ載ると語ります。Homeは個別のスキルを入れず、起動する入口を/homeの一つにしています。

Danielさん（動画の中で・字幕・21:53〜）

Well, in this case here, you don’t need to install any sort of skill.

There’s only one skill, which is /home that we’re going to run our full on system.

「ここでは、スキルを入れる必要がありません。スキルは1つだけ、/homeで、これでシステム全体を動かします。」

スキルを持たない「裸のエージェント」でも、ガイドブックに従えば同じように動く、というのがDanielさんの説明です。

Danielさん（動画の中で・字幕・22:09〜）

any agent, even if it will be naked, naked agent with no skills.

It will perform exactly the same, because it follows the full on guidebook on everything.

「どんなエージェントでも、スキルを1つも持たない裸のエージェントでも、まったく同じように動きます。すべてについてガイドブックに従うからです。」

Obsidianのプラグイン＝追加機能の実演では、新しいノートへ「we will do a blog for …」と一行書きます。ノート上のボタンからObsidian内のClaude Code、外のターミナル、Coworkで起動でき、その指示で作業が始まる。

タイポはエージェントが直すと語りますが、デモでは生成を途中で止め、完成までは見せていません。

Canvas＝配置する画面には画像・音声・動画を置けます。Projectsでは担当や進捗、期日を表示し、Googleカレンダーと同期。Kanban＝作業カードの一覧はドラッグで動かせます。最後はカレンダーの横に、Claude Codeのサイドパネルが開いた画面です。

毎回読ませる入口も、積み減らす。私はこの考えに賛成です。手順書を持つことと、その説明を毎回まとめて読ませることは、同じではないから。

トークンは、AIが文章を処理する量の単位です。毎回読む量は、私のClaudeでも減らしてきました。

私の過去記事より：Claude Codeの環境設定は、スキルが少ない方がいいのか。5個未満の三上さんと、313本持つ私を比べた

起動時に読み込まれるトークンは、Claudeで58,175から30,086、まとめ役のタスクでは115,047から55,743へ。毎回読む量を減らした記録です。

私のスキルは313本あります。直近30日のClaudeの4アカウントの会話記録で、読まれたか呼ばれたのは76本でした。持っている数と、使われた数には差があります。

今日（10月11日）、AI秘書の凛ちゃんにCodexを1回呼んでもらうと、スキル説明が文脈の予算を超えたという表示が出ました。説明はすべて外され、さらに174本はモデルに見える一覧へ入らなかった、という内容です。英文は「Exceeded skills context budget. All skill descriptions were removed and 174 additional skills were not included in the model-visible skills list.」でした。

174本の対象となる全体の本数は、この表示だけでは分かりません。Claudeで数えた313本と、そのまま引き算する数字でもない。

Danielさんが言う、スキルの名前と説明が毎回の文脈を使う問題は、私の読み込み量と今日の表示にも接点があります。この表示が示すのは、スキルが多いと説明が外されるところまで。/homeの入口なら同じ結果になるかは、動画の側の話です。

入口を一つに絞り、そこから必要な手順へ進む。その作りを使う前に、何を毎回読んでいるか数える。持ち帰る順番は、そこです。

→ 毎回読む物を数える

起動時に渡されるスキルと指示ファイルを、種類ごとに数えます。認証情報や設定値は開かず、件数と読み込まれる場面だけを記録し、必要な時に読む物を選ぼう。

Homeの強さは、作業手順だけでなく、参考資料、担当、承認、結果の記録までつながっていることです。英語の画面に並ぶ名前は、それぞれ仕事の役目を持っていました。

私なら、実行する前に何を見せるかから持ち帰ります。今日やる一手は、コマンド・対象・上限・戻し方・確認の証拠の5項目を決めること。承認した内容を残し、結果へつなぐ。そこから、任せた仕事をあとでたどれる形にしていこう。