toolbox

Plugin toolbox from marketplace agent-toolbox in MasashiFukuzawa/agent-toolbox. Commands read from the repo's manifest — yesterday.

Skills (24)

• adr

  Architecture Decision Record を起票・更新し、設計判断と既存記録の整合性を保つ。複数案から技術選定した時に使う。軽微な変更やコードベース全体の監査には使わない。「ADRにして」「この決定を記録して」を正のトリガーとし、コードベース全体の設計課題探索には codebase-audit を使う。

• ai-native-engineering

  設計・実装計画・スコープ・技術選択・工数見積もりを、AIが主実装者として継続・並列稼働する前提で判断する。「実装計画を作って」「MVPのスコープを決めたい」「まず簡易版で始めてよいか」「どれくらいで実装できる」「この構成はoverengineeringか」「将来の拡張をどこまで考慮する」を正のトリガーとし、非自明なarchitecture・security・コアUX設計と基盤選定では原則として使う。人間の工数感による妥協と、需要や脅威を確認しない機構追加を両方補正する。仕様と手段が確定した単純修正には使わない。

• ascii-diagram

  会話内に小さな ASCII・Unicode 図を描き、構成やフローを即座に説明する。簡潔な図解依頼で使う。保存する複雑な一枚物には html-artifact を使う。「ASCII図で」「会話内で図解して」を正のトリガーとし、表やSVGを含む保存用成果物には使わない。

• autopilot

  controllerが複数タスクの選択・委任・現物レビュー・出荷品質・継続監視を管理し、自律的に完了へ運ぶ。独立した作業の並列処理と結果回収を含む。「自律で進めて」「バックログを全部消化して」を正のトリガーとする。単発修正には使わない。品質受入だけならdoneを使う。

• behavioral-testing

  テストを書く・追加する・設計する作業で、退行を検出しリファクタリングを妨げないテストにする。「テストを書いて」「テストを追加して」「このバグの回帰テスト」「テストが壊れやすい」「モックが多すぎる」「テスト設計をレビューして」を正のトリガーとし、仕様根拠・モック方針・テストレベルの判断を伴う作業で使う。既存テストをそのまま実行するだけの時と、完了報告直前の品質ゲート（done の担当）には使わない。

• browser-operations

  Playwright CLI やブラウザ制御手段を選び、ログイン引き継ぎと永続セッションを安全に扱う。アドホックなブラウザ操作に使う。staging E2E の能力検証には使わない。「ブラウザで確認」「ログインを引き継いで」を正のトリガーとし、認証済みstagingの破壊的フロー検証には e2e-capability-verification を使う。

• claude-review

  Claude CLI の独立インスタンスでコードや設計を read-only レビューする。Claude・Anthropic・sonnet・opus・fable を明示した第三者レビューに使う。一般的なレビューや Codex 指定には使わない。「Claudeに見てもらって」「sonnetに見てもらって」「opusに相談して」「fableに相談して」を正のトリガーとし、provider未指定で選択権限も委任されていなければ確認する。

• cloudflare-data-pipeline

  D1、Vectorize、Queues、Workers をまたぐデータパイプラインの整合性と失敗処理を設計・レビューする。複数サービスの結合部に使う。単一 API の使い方には使わない。「Queue再処理」「D1とVectorizeの不整合」を正のトリガーとし、単一Workerのdeploy安全性には cloudflare-worker-cd を使う。

• cloudflare-worker-cd

  Cloudflare Workers の deploy、smoke test、失敗時 rollback を設計・レビューする。「WorkersのCDを設計して」「deploy手順をレビューして」「rollbackを整備して」を正のトリガーとし、本番 CD とリリース障害対応に使う。複数サービスのデータ整合性には cloudflare-data-pipeline を使う。

• codebase-audit

  コードベース全体を横断監査し、重大度・根拠ファイル・改善案を構造化する。技術負債や設計課題の包括的な洗い出しに使う。単一ファイルや PR のレビューには使わない。「技術負債を洗い出して」「横断的にレビュー」を正のトリガーとし、特定差分のセカンドオピニオンには codex-review / claude-review を使う。

• codex-review

  Codex CLI の独立インスタンスでコードや差分を read-only レビューする。Codex・OpenAI・sol・astra を明示した第三者レビューに使う。一般的なレビューや Claude 指定には使わない。「Codexに見てもらって」「solに相談して」「astraに相談して」を正のトリガーとし、provider未指定で選択権限も委任されていなければ確認する。

• context-handoff

  作業状態を別セッションや別エージェントへ渡す再開可能な引き継ぎ文書を作る。中断・担当交代・セッション切替の時に使う。「別セッションへ引き継いで」「再開用文書を作って」「引き継ぎを作って」を正のトリガーとし、現在地を判断者へ報告するだけなら progress-report を使う。

• daily-plan

  これから最大24時間でやる作業を人と合意し、その期間の進捗を自動で最新化する1枚のHTMLで追う。朝に1日分、夜に翌朝までの分のように、計画1つにページ1枚を作り、期間の目標との差・タイムライン・手順ごとの状態を示す。「今日の計画を作って」「今日やることを決めよう」「今夜から朝までの作業を決めて」「計画ページを最新化して」を正のトリガーとする。単発の進捗報告にはprogress-report、人への依頼と回答の記録にはowner-board、一枚物の判断資料にはhtml-artifact、自律実行の管理にはautopilotを使う。

• e2e-capability-verification

  staging や test 環境で認証付き E2E と機能可否を安全に検証する。破壊的操作や storageState が関わる検証に使う。アドホックなブラウザ操作には browser-operations を使う。「stagingで可能か確認」「認証付きE2Eを検証」を正のトリガーとし、日常的なサイト閲覧やログイン引き継ぎには使わない。

• git-worktrees

  並列開発の git worktree を作成・同期・整理し、衝突を避ける。別セッションや複数タスクを同時進行する時に使う。「worktreeを切って」「worktreeを掃除して」「別セッションと並列で進める」を正のトリガーとし、単一branch内の通常作業や単なるbranch削除には使わない。

• html-artifact

  計画・比較・進捗・説明を、人が見て理解し追加のやり取りなしで判断できる、図解中心の自己完結HTMLにする。論点を絞り、冒頭に結論（課題・目的・実施事項）とAsIs/ToBe図を置く。「HTML一枚物で」「HTMLで図解して」「比較を視覚化して」や、HTML作成・更新での「シンプルに」「図解多めで」「要点だけ」を正のトリガーとする。会話内の小さな図にはascii-diagram、人への依頼を継続管理する連絡板にはowner-boardを使い、production UIには使わない。

• human-notify

  人間への急ぎの連絡をrepo名付きの画面表示と音声で届ける。急ぎの連絡時に使う。「Macに通知して」「スピーカーで呼んで」「急ぎの依頼を通知して」で使う。owner-board等からも利用する。依頼・回答の継続管理にはowner-boardを使う。自律実行の管理にはautopilotを使う。通常の進捗報告には使わない。

• model-selection

  controllerが実装・調査・独立レビューを委任する際、タスクに適したモデルとeffortを選び、結果に応じて見直す。「モデルを選んで」「workerのモデルを決めて」を正のトリガーとする。レビューの実行そのものには使わない。実行はclaude-review/codex-review、進行管理はautopilotへ委ねる。

• owner-board

  人間への判断依頼・作業依頼を、マイルストーン上の現在地とともに、継続更新する一枚のオーナー連絡板HTMLへ集約する。自律運用や複数セッションで人の判断が必要な時に使う。「オーナー連絡板を作って」「連絡板を最新化して」「連絡板のQへの回答を反映して」を正のトリガーとする。依頼は背景・課題・目的・相談事項の形で書き、固定のQ番号で回答と中継を記録する。単発の進捗報告にはprogress-report、一般的なHTML資料にはhtml-artifact、自律実行の管理にはautopilotを使う。

• progress-report

  背景を知らない人が目的に対する現在地・見通し・必要な判断を理解できる進捗報告を作る。「今どうなってる」「進捗を報告して」を正のトリガーとする。progress-reportに続く自由文で焦点・粒度・形式を上書きできる。次の作業者向けの再開手順には使わない。その場合はcontext-handoffを使う。

• step-back

  障害対応や作業に没頭して視野が狭まった判断を、目的の分解・原因の証拠・目的を保つ案から立て直し、逆providerの第三者レビューを添えて推奨を出し直す。「step-backして」「step-backで考え直して」と明示的に呼ばれた時だけ使う。設計やスコープを最初から決めるならai-native-engineering、成果物のレビューだけならcodex-review / claude-reviewを使う。

• structured-text-parsing

  ログ、CSV、JSON、コードなど予測可能な構造化テキストを決定的に解析する。抽出・変換・集計を求められた時に使う。「JSONから抽出」「ログを集計」「CSVを変換して」を正のトリガーとし、入力形式が定義できず意味解釈そのものが必要な曖昧な依頼には使わない。

• technical-research

  非自明な技術課題を、既存実装と一次資料から調査して根拠付きの方針にする。実装前の調査や API の不確実性解消に使う。「技術調査して」「公式仕様を確認」「実装前に調べて」を正のトリガーとし、既知の局所修正やコードベース全体の改善監査には使わない。

• typescript-project-foundation

  新規 TypeScript project の runtime・package 境界、stack、API/data contract、security、testing、CI/CD を設計・scaffold・検証する。「新規TypeScriptプロジェクトの基盤を作って」「greenfieldのscaffold計画をレビューして」を正のトリガーとし、repository 新設・初期 architecture 決定・foundation plan のレビューで使う。既存 project の機能実装・migration・production UI design・単独 API 調査には使わない。

Similar plugins