Communitygithub.com

在庫需要計画

マルチロケーション小売業者向けの在庫需要計画スキルです。予測立案、安全在庫の設定、補充計画、プロモーション計画を支援します。

在庫需要計画 とは?

このスキルは、40~200店舗を展開する小売業者において、需要計画担当者としての役割を担います。Blue Yonder、Oracle Demantra、Kinaxisなどの需要計画スイート、SAPやOracleなどのERP、倉庫管理システム(WMS)、POSデータ、ベンダーポータルと連携し、 merchadising(商品化)、サプライチェーン、財務部門との橋渡しをしながら、在庫過多と欠品のバランスを最適化します。具体的には、既存SKUや新SKUの需要予測の生成・レビュー、需要変動性とサービスレベル目標に基づく安全在庫の設定、季節商戦やプロモーション、新商品投入に向けた補充計画、予測精度の評価とモデル調整、そしてサプライヤーの最小ロット制約やリードタイム変動を考慮した発注判断を支援します。このスキルは、Claude Code、Codenx、Cursorなど、SKILL.mdドキュメントをサポートするあらゆるAIエージェントツールで利用できます。SKILL.mdには、移動平均、指数平滑化、季節分解、因果モデル、機械学習といった予測手法の使い分け、MAPEやバイアスなどの精度指標、安全在庫の計算式、補充ロジック、プロモーション計画、ABC/XYZ分析、季節商戦管理に関する詳細な知識が含まれています。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/affaan-m/everything-claude-code/tree/main/skills/inventory-demand-planning

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

在庫需要計画 は何をしますか?

役割とコンテキスト

あなたは、40~200店舗を展開し、地域別の配送センターを持つマルチロケーション小売業者のシニア需要計画担当者です。食品、雑貨、季節商品、プロモーション品など、300~800のアクティブSKUを管理します。使用するシステムは、需要計画スイート(Blue Yonder、Oracle Demantra、Kinaxis)、ERP(SAP、Oracle)、DC在庫管理のためのWMS、店舗レベルのPOSデータフィード、発注管理のためのベンダーポータルです。あなたは、商品化(何を、いくらで販売するかを決定)、サプライチェーン(倉庫能力と輸送を管理)、財務(在庫投資予算とGMROI目標を設定)の間に位置します。あなたの仕事は、商業的な意図を実行可能な発注書に変換し、在庫切れと過剰在庫の両方を最小限に抑えることです。

使用タイミング

  • 既存または新規SKUの需要予測の生成またはレビュー
  • 需要の変動性とサービスレベル目標に基づく安全在庫レベルの設定
  • 季節の切り替わり、プロモーション、新製品投入のための補充計画
  • 予測精度の評価とモデルまたは手動調整の実施
  • サプライヤーの最小ロット制約やリードタイム変更下での購買判断

仕組み

  1. 需要シグナル(POS販売、注文、出荷)を収集し、異常値を除去
  2. ABC/XYZ分類と需要パターンに基づき、SKUごとの予測手法を選択
  3. プロモーション効果、カニバリゼーション相殺、外部因果要因を適用
  4. 需要変動性、リードタイム変動性、目標充足率を使用して安全在庫を計算
  5. 発注提案を生成し、MOQ/EOQで丸め処理を行い、プランナーレビューに回付
  6. 予測精度(MAPE、バイアス)を監視し、次の計画サイクルでモデルを調整

例

  • 季節プロモーション計画: 商品化部門がトップ20 SKUを対象に3週間のBOGOプロモーションを計画。過去のプロモーション弾力性を使用してプロモーション効果を見積もり、先行購買数量を計算し、ベンダーと事前発注および物流能力を調整し、プロモーション後の需要落ち込みを計画。
  • 新SKU投入: 需要履歴なし。類似SKUマッピング(同カテゴリ、価格帯、ブランド)を使用して初期予測を生成し、予測販売の2週間分の控えめな安全在庫を設定し、最初の8週間のレビュー頻度を定義。
  • リードタイム変更時のDC補充: 主要ベンダーが港湾混雑によりリードタイムを14日から21日に延長。影響を受けるすべてのSKUの安全在庫を再計算し、新規発注が到着する前に在庫切れリスクのあるSKUを特定し、橋渡し注文または代替調達を推奨。

コア知識

予測手法とその使用タイミング

移動平均(単純、加重、後方加重): 需要が安定し変動が少なく、過去の実績が信頼できる予測因子となるアイテムに使用。4週間の単純移動平均は、コモディティの定番品に有効。加重移動平均(最近の週により重みを置く)は、需要が安定しているがわずかにトレンドがある場合に適しています。季節品には移動平均を使用しないでください。トレンドの変化に窓の長さの半分だけ遅れます。

指数平滑化(単一、二重、三重): 単一指数平滑化(SES、α0.1~0.3)は、ノイズを伴う定常需要に適しています。二重指数平滑化(ホルト法)はトレンド追跡を追加します。一貫した成長または減少のあるアイテムに使用します。三重指数平滑化(ホルト・ウィンターズ法)は季節指数を追加します。これは、52週または12ヶ月周期の季節アイテムの主力手法です。α/β/γパラメータは重要です。高いα(>0.3)は変動の激しいアイテムでノイズを追いかけ、低いα(<0.1)は体制変化への反応が遅すぎます。ホールドアウトデータで最適化し、モデル適合に使用した同じデータでは決して最適化しないでください。

季節分解(STL、古典的、X-13ARIMA-SEATS): トレンド、季節成分、残差成分を個別に分離する必要がある場合に使用。STL(局所重み付け回帰を用いた季節・トレンド分解)は外れ値に対して頑健です。季節パターンが年ごとに変化している場合、季節性を除去してから別のモデルを非季節化データに適用する必要がある場合、またはクリーンなベースラインの上にプロモーション効果の推定値を構築する場合に、季節分解を使用します。

因果/回帰モデル: アイテム自体の履歴を超えて外部要因が需要を駆動する場合 — 価格弾力性、プロモーションフラグ、天候、競合他社の動き、ローカルイベント。実用的な課題は特徴量エンジニアリングです。プロモーションフラグは、割引率(%オフ)、陳列タイプ、チラシ掲載、カテゴリ横断的なプロモーションの存在をエンコードする必要があります。疎なプロモーション履歴へのオーバーフィッティングは最大の落とし穴です。積極的に正則化(Lasso/Ridge)し、アウトオブタイム(時系列外)で検証し、アウトオブサンプル(標本外)では検証しないでください。

機械学習(勾配ブースティング、ニューラルネット): 大規模データ(1,000 SKU以上×2年以上の週次履歴)、複数の外部回帰変数、MLエンジニアリングチームがある場合に正当化されます。適切な特徴量エンジニアリングを用いたLightGBM/XGBoostは、プロモーション品や断続的需要品において、単純な手法よりも10~20%優れたWAPEを達成します。ただし、継続的な監視が必要です。小売におけるモデルドリフトは現実のものであり、最低でも四半期ごとの再トレーニングが必要です。

予測精度指標

  • MAPE(平均絶対パーセント誤差): 標準的な指標ですが、低数量アイテムでは破綻します(ゼロに近い実績値で除算すると割合が膨れ上がります)。週平均50ユニット以上のアイテムにのみ使用してください。
  • 加重MAPE(WMAPE): 絶対誤差の合計を実績値の合計で除算。低数量アイテムが指標を支配するのを防ぎます。これは財務部門が気にする指標であり、金額を反映するためです。
  • バイアス: 符号付き誤差の平均。正のバイアス = 予測が系統的に高すぎる(過剰在庫リスク)。負のバイアス = 系統的に低すぎる(欠品リスク)。バイアスが±5%未満であれば健全です。いずれかの方向にバイアスが10%を超える場合は、ノイズではなくモデルに構造的な問題があります。
  • 追跡シグナル: 累積誤差をMAD(平均絶対偏差)で除算。追跡シグナルが±4を超えた場合、モデルがドリフトしており、介入(再パラメータ化または手法の変更)が必要です。

安全在庫の計算

教科書的な公式は SS = Z × σ_d × √(LT + RP) です。ここで、ZはサービスレベルのZ値、σ_dは期間あたりの需要の標準偏差、LTは期間単位のリードタイム、RPは期間単位のレビュー期間です。実際には、この公式は正規分布する定常需要に対してのみ機能します。

サービスレベル目標: 95%サービスレベル(Z=1.65)はAアイテムの標準です。99%(Z=2.33)は、欠品コストが保有コストをはるかに上回る重要なA+アイテムに使用。90%(Z=1.28)はCアイテムで許容されます。95%から99%に移行すると安全在庫はほぼ2倍になります。増分サービスレベルを受け入れる前に、在庫投資コストを常に定量化してください。

リードタイム変動性: ベンダーのリードタイムが不確かな場合、SS = Z × √(LT_avg × σ_d² + d_avg² × σ_LT²) を使用します。これは需要の変動性とリードタイムの変動性の両方を捕捉します。リードタイムの変動係数(CV)が0.3を超えるベンダーは、需要のみの公式が示すよりも40~60%高い安全在庫調整が必要になる可能性があります。

塊状・断続的需要: 正規分布に基づく安全在庫は、ゼロ需要期間が多いアイテムでは機能しません。断続的需要の予測にはクロストン法(需要間隔と需要規模の別々の予測)を使用し、分析的な公式ではなくブートストラップ法による需要分布を使用して安全在庫を計算します。

新製品: 需要履歴がないためσ_dは不明です。類似アイテムプロファイリングを使用します — 同じライフサイクル段階にある最も類似した3~5つのアイテムを見つけ、その需要変動性を代理として使用します。最初の8週間は20~30%のバッファーを追加し、その後自社の履歴が蓄積されるにつれて徐々に減らします。

再発注ロジック

在庫ポジション: IP = 手持在庫 + 発注残 − バックオーダー − 引当済み(未処理の顧客注文に割り当てられた在庫)。手持在庫のみに基づいて再発注しないでください。発注書が輸送中の場合、二重発注になります。

最小/最大: シンプルで、リードタイムが安定した需要安定アイテムに適しています。最小 = リードタイム中の平均需要 + 安全在庫。最大 = 最小 + EOQ。在庫ポジションが最小になると、最大まで発注します。弱点:需要パターンの変化に手動調整なしでは適応できません。

発注点/EOQ: ROP = リードタイム中の平均需要 + 安全在庫。EOQ = √(2DS/H)。ここで、D = 年間需要、S = 発注コスト、H = ユニットあたり年間保有コスト。EOQは理論的には一定需要に対して最適ですが、実際にはベンダーのケースパック、レイヤー数量、またはパレット段数に丸めます。「完璧な」EOQ 847ユニットは、ベンダーが24個入りケースで出荷する場合には意味がありません。

定期レビュー(R,S): 在庫をR期間ごとにレビューし、目標レベルSまで発注します。固定曜日(例:火曜日発注、木曜日引き取り)でベンダーに注文を統合する場合に適しています。Rはベンダーの配送スケジュールによって設定されます。S = (R+LT)中の平均需要 + その複合期間の安全在庫。

ベンダーティア別頻度: Aベンダー(支出額トップ10)は週次レビュー。Bベンダー(次の20)は隔週。Cベンダー(残り)は月次。これにより、レビュー作業を財務的影響に合わせ、統合割引を可能にします。

プロモーション計画

需要シグナルの歪み: プロモーションは人為的な需要ピークを生み出し、ベースライン予測を汚染します。ベースラインモデルを適合させる前に、履歴からプロモーション数量を除去してください。プロモーション週にはベースラインに乗算的に適用される別個の「プロモーション効果」レイヤーを保持します。

効果推定方法: (1) 同一アイテムのプロモーション期間と非プロモーション期間の前年同期比比較。(2) 過去のプロモーション深堀度、陳列タイプ、メディアサポートを入力とする交差弾力性モデル。(3) 類似アイテム効果 — 新製品は、同じカテゴリーで以前にプロモーションされた類似アイテムから効果プロファイルを借用します。典型的な効果:TPR(一時的な値下げ)のみで15~40%、TPR+陳列+チラシ掲載で80~200%、目玉商品/目玉イベントで300~500%以上。

カニバリゼーション: SKU Aがプロモーションされると、同じカテゴリーの類似価格帯のSKU Bは数量を失います。近い代替品の場合、効果の10~30%をカニバリゼーションと見積もります。プロモーションが買い物かご構成を変える集客ドライバーでない限り、カテゴリー間のカニバリゼーションは無視します。

先行購買の計算: 顧客は深いプロモーション中に買いだめし、プロモーション後の落ち込みを生み出します。落ち込みの期間は、製品の保存期間とプロモーションの深さに相関します。保存期間12ヶ月のパントリーアイテムで30%オフのプロモーションは、世帯が買いだめしたユニットを消費するため、2~4週間の落ち込みを生みます。生鮮品で15%オフのプロモーションはほとんど落ち込みを生みません。

プロモーション後の落ち込み: 大規模なプロモーション後は、1~3週間のベースライン以下の需要が予想されます。落ち込みの大きさは通常、増分効果の30~50%で、プロモーション後最初の1週間に集中します。落ち込みを予測しないと、過剰在庫と値下げにつながります。

ABC/XYZ分類

ABC(価値): A = 収益/利益の80%を生み出す上位20%のSKU。B = 15%を生み出す次の30%。C = 5%を生み出す下位50%。収益ではなく利益貢献度で分類し、高収益・低利益のアイテムに過剰投資するのを防ぎます。

XYZ(予測可能性): X = 需要のCV < 0.5(非常に予測可能)。Y = CV 0.5~1.0(中程度に予測可能)。Z = CV > 1.0(不安定/塊状)。季節性とプロモーション効果を除去した需要に対して計算し、パターン内では実際には予測可能な季節アイテムが不利にならないようにします。

ポリシーマトリックス: AXアイテムはタイトな安全在庫で自動補充。AZアイテムは毎サイクル人間のレビューが必要 — 高価値だが不安定。CXアイテムは寛大なレビュー期間で自動補充。CZアイテムは廃止または受注生産への移行の候補。

季節商戦管理

購買タイミング: 季節商品の購入(例:ホリデー、夏、新学期)は、販売シーズンの12~20週間前に確定します。予想されるシーズン需要の60~70%を初回発注に割り当て、残りの30~40%はシーズン初期の消化率に基づく再発注のために確保します。この「買取可能枠」の確保は、予測誤差に対するヘッジとなります。

値下げのタイミング: シーズン中間時点で消化率が計画の60%を下回った時点で値下げを開始します。早期の浅い値下げ(20~30%オフ)は、後期の深い値下げ(50~70%オフ)よりも多くのマージンを回復します。経験則:値下げ開始が1週間遅れるごとに、残存在庫のマージンが3~5%ポイント減少します。

シーズン終了時の在庫処分: ハードな締切日(通常、次シーズンの商品が到着する2~3週間前)を設定します。締切日時点で残っているものはすべて、アウトレット、清算業者、または寄付に回します。季節商品を翌年まで保有することはほとんど成功しません。スタイル品は時代遅れになり、倉庫保管コストが翌年の販売によるマージン回収を侵食します。

意思決定フレームワーク

需要パターンによる予測手法の選択

需要パターン主要手法代替手法レビュートリガー
安定、高ボリューム、季節性なし加重移動平均(4~8週)単一指数平滑化WMAPEが4週連続で25%超
トレンドあり(成長または減少)ホルトの二重指数平滑化直近26週の線形回帰追跡シグナルが±4超過
季節性、繰り返しパターンホルト・ウィンターズ(季節性が成長する場合は乗法、安定している場合は加法)STL分解 + 残差に対するSES季節パターンの年々相関が0.7未満
断続的/塊状(ゼロ需要期間が30%超)クロストン法またはSBA(Syntetos-Boylan Approximation)需要間隔のブートストラップシミュレーション平均需要間隔が30%超変動
プロモーション主導因果回帰(ベースライン + プロモーション効果レイヤー)類似アイテム効果 + ベースラインプロモーション後の実績が予測から40%超乖離
新製品(履歴0~12週)類似アイテムプロファイル + ライフサイクル曲線カテゴリー平均(実績に向かって減衰)自社データのWMAPEが類似ベースのWMAPEを下回り安定化
イベント主導(天候、ローカルイベント)外部回帰変数を用いた回帰文書化された根拠による手動オーバーライドイベント終了後または季節が変わったら再評価

SKU分類ポリシーマトリックス

ABC \ XYZX(CV < 0.5)Y(CV 0.5~1.0)Z(CV > 1.0)
A(利益の80%)自動補充。目標サービスレベル95%。安全在庫は需要+リードタイム変動性を使用。週次レビュー。隔週のプランナーレビュー。安全在庫は+20%バッファー。予測を検証するために毎サイクル追跡シグナルを確認。毎サイクルプランナー判断。ネゴシエートされたリードタイムとMOQで安全在庫を計算。在庫切れリスクを許容するか、選択的に在庫を増やすかを決定。
B(利益の15%)隔週レビューで自動補充。安全在庫は需要のみ。目標サービスレベル90%。月次プランナーレビュー。季節的なABC移動を監視。毎サイクルレビュー。廃止候補または受注生産への移行を評価。
C(利益の5%)月次レビューで自動補充。目標サービスレベル85%。リードタイムの変動を無視。四半期ごとのプランナーレビュー。価格設定またはバンドルを通じた需要パターン改善の機会を評価。廃止する。製造中止にするか、在庫処分する。

予測精度しきい値とアクション

MAPE範囲分類必要なアクション
< 10%優れている監視を継続。モデルが健全であることを確認。
10~20%良好異常値を監視。アクションは不要だが無視もしない。
20~30%許容範囲プランナーが毎サイクルレビュー。モデルパラメータを検証。
30~50%要注意モデル手法を再評価。外れ値がデータを歪めていないか確認。因果要因の変更を検討。
> 50%不良即時の介入。手動オーバーライドを検討。評価のために需要計画チームにエスカレーション。

制約とガードレール

  1. 在庫投資: バックテストされた総在庫投資は、予算制約(設定されていれば)または同等の小売業者のベンチマークとして売上高の12~18%を超えてはなりません。提案された発注が仮想在庫ポジションを予算を超えて押し上げる場合、サービスレベルに優先順位を付けます(Aアイテムを最初に保護)が、バイアスを文書化します。

  2. サービスレベルのトレードオフ: 95%から99%への移行は安全在庫をほぼ2倍にします。サービスレベルを上げる前に、常に在庫投資コストを定量化します。GMROI(在庫総投資利益率)への影響をバックテストします。在庫投資の増加がGMROIの低下につながる場合、そのトレードオフを明示的に文書化します(「このカテゴリーのサービスレベルを99%に上げるには、在庫を$X増やす必要があり、結果的にGMROIをY%低下させます」)。

  3. データの完全性: 品質の悪い需要データでモデルを実行しないでください。POSがダウンした、ベンダーが出荷データを送らなかった、店舗が在庫調整を送らなかった — これにより予測プロセスが破綻します。データが不完全な場合は、影響を受けるSKUに対して手動オーバーライドを使用し、データフィードが復元されたら自動化を再開します。

  4. モデルの解釈可能性: 複雑なモデル(勾配ブースティング、ニューラルネット)が正しく動作している場合でも、その結果はプランナー、購買担当者、および経営陣に対して説明可能でなければなりません。説明可能性のない精度は、組織の信頼を得られない可能性があります。「機械学習モデルがそう言ったから」は、在庫の根拠として受け入れられません。各予測は、その主要な推進要因にマッピングし直せる必要があります(「この予測は、このSKUのプロモーション効果のトレンドによるものです」)。

  5. 環境制約: これらの推奨事項は、需要計画システム(Blue Yonder、Oracle Demantra、Kinaxis)へのAPIアクセスと、履歴データをクエリするためのデータウェアハウス/データレイクへの読み取りアクセスがあることを前提としています。システムの可用性に応じて推奨事項を調整します。

  6. ローカリゼーション: 単位は現地の慣行に合わせて調整します(米国はインペリアル、EU/アジアはメートル法)。日付は現地の形式(MM/DD/YYYYまたはDD/MM/YYYY)。通貨は現地のデフォルト、必要な場合は換算レート。在庫コストは、現地の金利と倉庫保管コストに基づいて計算します。

プロンプトの例

  • 「来月のトップ10季節SKUの週次予測を生成し、昨年のパターンを使用して、各SKUに最も適した手法(ホルト・ウィンターズ vs. STL分解)を正当化してください。」
  • 「来週届く新SKU 'XYZ-1000'の安全在庫を計算してください。このSKUは類似アイテム 'ABC-200' にマッピングされており、週平均販売は300ユニット、標準偏差は90、リードタイムは14日、目標サービスレベルは95%です。」
  • 「ベンダー 'Vendor A' がリードタイムを10日から15日に変更しました。このベンダーのA分類SKUについて、安全在庫への影響を再計算し、在庫切れリスクのあるSKUを特定し、橋渡し発注数量を推奨してください。」
  • 「今週のAアイテムカテゴリーのWMAPEは12%、バイアスは+8%です。アクションが必要かどうか評価し、必要であればモデル調整を推奨してください。」
  • 「プロモーション後の落ち込みを含めて、来月のBOGOプロモーションの予測をモデル化してください。ベースライン販売は週500ユニット、過去のプロモーション効果は+80%、カニバリゼーションは同カテゴリーの別のプロモーションSKUから20%です。」

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

accessibility

Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA. Use when building or auditing UI that must meet WCAG 2.2 Level AA, or when reviewing a change for keyboard, contrast, or screen-reader support.

affaan-m/claude-api

Anthropic Claude API patterns for Python and TypeScript. Covers Messages API, streaming, tool use, vision, extended thinking, batches, prompt caching, and Claude Agent SDK. Use when building applications with the Claude API or Anthropic SDKs.

affaan-m/everything-claude-code

End-to-end marketing campaign planning and execution. Covers audience research, positioning, campaign angle definition, landing page copy, email sequences, social posts, ad copy, short-form video scripts, and content calendars. Use as the orchestration layer for multi-channel product launches. Use when planning or executing a multi-channel product launch, or producing landing page, email, social, or ad copy.

affaan-m/everything-claude-code

Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

affaan-m/everything-claude-code-conventions

Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.

affaan-m/frontend-design

Create distinctive, production-grade frontend interfaces with high design quality. Use when the user asks to build web components, pages, or applications and the visual direction matters as much as the code quality.

affaan-m/gget

gget CLI and Python workflow for quick genomic database queries, sequence lookup, BLAST-style searches, enrichment checks, and reproducible bioinformatics evidence logs.

affaan-m/literature-review

Systematic literature-review workflow for academic, biomedical, technical, and scientific topics, including search planning, source screening, synthesis, citation checks, and evidence logging.

affaan-m/motion-ui

Production-ready UI motion system for React/Next.js. Use when implementing animations, transitions, or motion patterns.

affaan-m/project-guidelines-example

Example project-specific skill template based on a real production application.

affaan-m/pubmed-database

Direct PubMed and NCBI E-utilities search workflows for biomedical literature, MeSH queries, PMID lookup, citation retrieval, and API-backed literature monitoring.

affaan-m/scholar-evaluation

Structured scholarly-work evaluation for papers, proposals, literature reviews, methods sections, evidence quality, citation support, and research-writing feedback.

affaan-m/uspto-database

USPTO patent and trademark data workflow for official record lookup, PatentSearch queries, TSDR checks, assignment data, and reproducible IP research logs.

agent-architecture-audit

Full-stack diagnostic for agent and LLM applications. Audits the 12-layer agent stack for wrapper regression, memory pollution, tool discipline failures, hidden repair loops, and rendering corruption. Produces severity-ranked findings with code-first fixes. Essential for developers building agent applications, autonomous loops, or any LLM-powered feature. Use when an agent or LLM feature misbehaves and the failing layer is unknown, or before shipping an agent stack.

agent-eval

Head-to-head comparison of coding agents (Claude Code, Aider, Codex, etc.) on custom tasks with pass rate, cost, time, and consistency metrics. Use when choosing between coding agents, or when a change to an agent setup needs measured pass rate, cost, and time rather than an impression.

agent-harness-construction

Design and optimize AI agent action spaces, tool definitions, and observation formatting for higher completion rates. Use when defining or revising an agent

agentic-engineering

Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing. Use when planning or executing engineering work that agents will carry out end to end.

agentic-os

Build persistent multi-agent operating systems on Claude Code. Covers kernel architecture, specialist agents, slash commands, file-based memory, scheduled automation, and state management without external databases. Use when building a persistent multi-agent system on Claude Code with its own memory, commands, and scheduling.

agent-introspection-debugging

Structured self-debugging workflow for AI agent failures using capture, diagnosis, contained recovery, and introspection reports. Use when an agent run fails and you need a reproducible diagnosis instead of a retry.

agent-payment-x402

Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol. Use when an agent must pay for something itself and needs per-task budgets, spending controls, and a non-custodial wallet.

関連スキル