xero plugin catalog

事業戦略の壁打ちを対話的に行う顧問スキル。注力/撤退の判断、案件・プロダクトの優先順位づけ、リソース配分、事業の方向性を整理したいときに使用。「戦略の壁打ちをしたい」「何に注力すべきか整理したい」「この事業を続けるか迷っている」と言われたとき、または /biz-strategy で呼び出されたときに使う。単発の判断の反証は decision-reviewer エージェント、市場調査は market-researcher エージェントに委譲する。

個人事業主の財務・会計の相談相手となる顧問スキル。資金繰りの整理、単価・価格戦略の検討、経費・節税の考え方、法人化の検討、キャッシュフロー予測など、お金まわりを整理したいときに使用。「資金繰りを整理したい」「単価を上げるべきか」「法人化すべきか」「お金の相談」と言われたとき、または /finance-advisor で呼び出されたときに使う。税務の最終判断は税理士に委ねる。

個人開発者が参入できる市場の空白領域（ニッチ）を、構築期間別の3トラック（1日/1週間/1ヶ月で作り切れるもの）＋反証役の並列web調査で洗い出すスキル。トラックごとに market-researcher エージェントへ委譲し、出典付き・「推測/未確認」明記のレポート群と横断比較サマリを market_research/<日付>/ に保存する。「儲かるニッチを探して」「参入できる空白領域を調査して」「マイクロSaaSのネタを調査して」「1日で作れて売れるものを探して」と言われたとき、または /market-research で呼び出されたときに使う。単一テーマの深掘り調査は market-researcher エージェント単体、判断の反証は decision-reviewer の領分。

新規サービスのアイデア・領域について市場調査（市場規模・競合・価格相場・需要の根拠・空白領域）を行い、pj_*/01_research.md を生成する。調査の実行は market-researcher エージェントに委譲する薄い入口スキル。pj-系サービス開発スキル群の第1工程で、後工程は /pj-2-concept。テーマが未定でニッチ探索から始めたい場合は /market-research の領分

新規サービスのコンセプト（誰の・どんな課題を・どんな価値で解決するか）を対話的に設計し、pj_*/02_concept.md を生成する。サービスのアイデアや価値定義を整理したいときに使用。pj-系サービス開発スキル群の第2工程で、前工程は /pj-1-research（その出力 01_research.md があれば入力に使う。調査済みなら省略可）、後工程は /pj-3-strategy

サービス戦略（ポジショニング・差別化の源泉・勝ち筋・参入順序・チャネル・やらないこと）を対話的に設計し pj_*/03_strategy.md を生成する。pj-系サービス開発スキル群の第3工程で、前工程は /pj-2-concept（02_concept.md を前提とし、01_research.md があれば競合根拠に使う）、後工程は /pj-4-business-model。事業全体の壁打ちは /biz-strategy の領分で、こちらは単一サービスの戦略が対象

サービスのビジネスモデル（最終ゴール金額からの逆算・収益モデル・価格設定・コスト構造・マイルストーン）を設計し pj_*/04_business-model.md を生成する。pj-系サービス開発スキル群の第4工程で、前工程は /pj-2-concept と /pj-3-strategy（02_concept.md・03_strategy.md を前提とする）、後工程は /pj-5-spec

サービスの仕様設計（情報設計・機能一覧・コンテンツ設計・画面/UX概要・技術構成の方針・非スコープ）を対話的に行い pj_*/05_service-spec.md を生成する。「実装して」と依頼できる状態を作る工程。pj-系サービス開発スキル群の第5工程で、前工程は /pj-4-business-model（02〜04 の成果物を前提とする）、後工程は /pj-6-execution-plan

仕様を実行可能なタスクに分解し、MVPスコープ・週次タスクリスト・検証項目と判定日・後工程スキルへの振り分けを pj_*/06_execution-plan.md として生成する。pj-系サービス開発スキル群の最終工程で、前工程は /pj-5-spec（02〜05 の成果物を前提とする）。以降の構築・集客は既存の専門スキル（frontend系・marketing-strategy・content-seo-editor 等）へ振り分ける

pj-系スキル群の成果物（pj_*/01_research.md 〜 06_execution-plan.md 等）を、指定したプロジェクトフォルダの docs/ 配下にディレクトリを切って移設する。docs/ がなければ作成する。引数はすべて省略可で、省略時は移設元・移設先・サブディレクトリ名を対話でヒアリングしてから実行する。サービスの実装リポジトリができたタイミングで、設計ドキュメント一式をリポジトリ管理に移すときに使う。pj-系の工程スキル（1〜6）ではなく後始末用ユーティリティ

契約書・利用規約・業務委託契約・NDA・SaaSの規約などを読み、個人事業主（受託開発＋自社SaaS）にとってのリスクと不利な条項を検知して指摘する法務チェッカー。「この契約書を見て」「不利な条項がないか確認して」「利用規約のリスクをチェックして」「下請法的に問題ないか」と言われたときに使う。専門的な法的判断が必要な箇所は弁護士相談を促す。

下そうとしている判断（参入・撤退・価格改定・技術選定・大きな出費など）を「反証する側」の立場から徹底的に叩き、見落としている前提・リスク・代替案を洗い出す悪魔の代弁者。「この判断をレビューして」「この決定の穴を探して」「反対意見をぶつけて」「本当にこれでいいか叩いて」と言われたときに使う。賛成意見や励ましは返さない。

市場規模・競合・価格相場・技術動向・ターゲット像を web を横断して調べ切り、出典付きのリサーチレポートにまとめる調査専任エージェント。新サービスの立ち上げ判断、受託提案の裏付け、価格設定の相場観、競合の機能比較などに使う。「この市場を調べて」「競合を洗い出して」「この分野の相場を調べて」「参入余地があるか調査して」と言われたときに使う。

自社SaaS・サービスのカスタマーサクセスを設計する対話スキル。オンボーディング設計、解約防止（チャーン対策）、LTV向上、ヘルススコア設計、問い合わせ対応の仕組み化を整理したいときに使用。「解約が多い」「オンボーディングを設計したい」「LTVを上げたい」「CS対応を仕組み化したい」と言われたとき、または /cs-design で呼び出されたときに使う。

マーケティング戦略（ターゲット・ポジショニング・チャネル設計）を対話的に設計する司令塔スキル。「誰に・何を・どこで売るか」を整理したいとき、集客の全体設計を作りたいとき、「マーケ戦略を考えたい」「集客の設計をしたい」「どのチャネルに注力すべきか」と言われたとき、または /marketing-strategy で呼び出されたときに使う。LP制作は lp-1〜4 スキル群、記事量産は content-seo-editor エージェント、市場調査は market-researcher エージェントに委譲する下流を持つ。

Web広告（Google検索広告・Meta広告等）の運用を支援する広告運用担当。キャンペーン設計（アカウント構成・キーワード・オーディエンス・予算配分）、広告文の量産、LPとの整合性チェック、成果データ（CSV・スクリーンショット・数値メモ）の分析と改善提案を行う。「広告を出したい」「広告文を作って」「キャンペーン構成を設計して」「広告の成果を分析して」「CPAが高いので改善したい」と言われたときに使う。広告を出すべきかの判断・チャネル選定は marketing-strategy スキル、LP自体の制作は lp-1〜4 スキル群の領分。実際の入稿・配信操作はしない。

集客用コンテンツ（ブログ記事・note・技術記事）の企画・構成・SEO最適化を行う編集者。キーワードやテーマから、検索意図の分析→記事構成案→執筆→タイトル・見出し・メタ情報の最適化までを一気に行う。「集客記事を書いて」「このキーワードで記事構成を作って」「記事をSEO最適化して」「コンテンツを量産したい」と言われたときに使う。マーケ戦略の全体設計は marketing-strategy スキル、サイト全体のSEO診断は seo-audit スキルの領分。

「Macが重い・遅い・固まる」の原因を、推測ではなく実測で特定する診断スキル。一次計測で CPU型 / メモリ型 / ディスクI-O型 / サーマル型 / 常駐プロセス型 を切り分け、該当する型だけを深掘りして原因を名指しする。wired メモリの肥大、カーネルのゾーンリーク、スワップ地獄（スラッシング）、暴走プロセス、ディスク枯渇に対応する。「Macが重い」「急に遅くなった」「ファンがうるさい」「原因を調べて」と言われたとき、または /doctor で呼び出されたときに使用。対処（再起動・設定変更）の前に必ず原因を確定させることを目的とし、対処法の提示だけで済ませない。

新しいスキルを作るときの雛形となるサンプルスキル。SKILL.md / INSTRUCTIONS.md の二層構造を確認したいときの参照用。実運用では削除またはコピーして使う。

複雑なExcelファイル（数式・他シート参照が多いブック）をWebアプリ移植に向けて解析するスキル。構造棚卸し→数式依存グラフ→ロジック仕様書→回帰テスト用スナップショットの4工程を、専用エージェント（excel-inventory / excel-dep-graph / excel-logic-spec / excel-snapshot）に順に委譲して excel_analysis/<ブック名>/ に成果物を出力する。「このExcelを解析して」「ExcelをWebアプリ化したい」「数式の依存関係を調べて」と言われたとき、または /excel-analyze <path> で呼び出されたときに使用。

公開Googleスプレッドシートを全シート漏れなくダウンロードし、シートごとのMarkdownテーブルとして保存する。htmlviewから全シート（gid＋シート名）を列挙し、シートごとにCSVで取得（表示値そのまま）→md変換する2段構え。生CSVも csv/ に一次データとして保存し、各mdのfrontmatterに取得元URL・シート名・gid・取得日時を記録する。「このスプレッドシートをmdで保存して」「シートをダウンロードして」と言われたとき、または /gsheet-to-md <URL> [出力先] で呼び出されたときに使う。認証が必要な非公開シートは対象外。

公開Notionページ（notion.site）を子ページ・データベースも含めて再帰的にMarkdownエクスポートする。各ページのfrontmatterにNotion上の作成/更新日時と元ページURLを記録し、トップページには取得元URLと取得日時を記載、画像はattachments/へローカル保存する。「このNotionページをmdで保存して」「Notionをエクスポートして」と言われたとき、または /notion-to-md <URL> [出力先] で呼び出されたときに使う。認証が必要な非公開ページは対象外。

docs/refactoring/ のリファクタリング計画（refactor-plan スキルが生成する形式）を 1 ファイル読み、コードベースの現状から未実施の PR ステップを洗い出し、サブエージェント（refactor-implementer → refactor-verifier）に git worktree 隔離で実装・検証させて、残り全ステップぶんの PR を一気通貫で作成するオーケストレータ。1 PR ステップ = 1 PR の粒度は維持し、依存する PR は stacked（PR N の base = PR N-1 のブランチ）で積む。ステップ番号を明示すればそのステップだけの単発実行も可能。計画の最終ステップの PR には計画 md 自体の削除を含め、最終的に refactoring フォルダを空にする。スキル自身はコードを書かない。検証コマンドやプロジェクト規約はリポジトリごとに実測・収集してエージェントに渡す（特定プロジェクトに依存しない）。「リファクタリングを進めて」「〜のリファクタ計画を実行して」と言われたとき、または /refactor-page [計画名] で呼び出されたときに使用。計画書の作成は refactor-plan の領分。

肥大化したページ・モジュールのリファクタリング計画書を docs/refactoring/<対象>.md として作成するスキル。対象ごとに refactor-plan-analyzer エージェントを並列起動して実測（wc -l / grep / 依存・重複の洗い出し）させ、その分析を refactor-plan-writer に渡して「現状分析→問題点→目標構造→PR 単位の実行ステップ→テスト戦略→リスク」構成の計画書に仕上げる。全 PR 挙動不変・1 PR = 1 構造変更・独立マージ可能を原則とする。「リファクタ計画を作って」「この god-component を分割する計画が欲しい」「docs/refactoring に計画書を追加して」と言われたとき、または /refactor-plan [対象] で呼び出されたときに使用。計画の実行（PR 作成）は別スキル（refactor-page 等）の領分。

Excelブックの数式依存関係グラフを構築する。excel-analyze スキルの第2工程として呼び出される。第1工程の 01_inventory.json を入力に、数式のセル参照（他シート・名前付き範囲含む）をパースして有向グラフを作り、入力セル/中間計算/出力セルの3層分類と未使用セルの検出を行い、02_dependencies.json と 02_dependency-graph.md を出力する。

Excelブックの構造棚卸し（インベントリ作成）を行う。excel-analyze スキルの第1工程として呼び出される。対象の .xlsx を openpyxl で走査し、シート一覧・セル分類（定数/数式/空欄）・名前付き範囲・テーブル・データ検証・非表示要素を抽出して 01_inventory.json と 01_inventory.md を出力する。

Excelブックの計算ロジックを業務語彙の仕様書に翻訳する。excel-analyze スキルの第3工程として呼び出される。01_inventory.json と 02_dependencies.json を入力に、数式を周辺ラベル（見出し行・左隣セル）と突き合わせて「粗利率 = (売上 − 原価) / 売上」のような意味のある仕様に変換し、03_logic-spec.md を出力する。

Excelブックの入出力スナップショット（回帰テスト用データ）を採取する。excel-analyze スキルの第4工程として呼び出される。02_dependencies.json の入力セル・出力セル分類に基づき、現在の入力値と計算結果値のペアを 04_snapshot.json として保存し、Webアプリ移植後の検証方法を 04_test-cases.md にまとめる。

受託開発・制作案件の工数見積・スケジュール・リスク分解を行うプロジェクトマネージャー。要件や提案内容をWBS（作業分解）に落とし、タスクごとの工数レンジ・クリティカルパス・バッファ・リスクと対策をまとめる。「工数を見積もって」「スケジュールを引いて」「この案件どれくらいかかるか」「タスクを分解して」と言われたときに使う。金額はproposal-writer、純粋な工数と計画はこちら。

受託開発・制作案件の提案書と見積を作成する営業ライター。要件メモ・ヒアリングメモ・RFP・問い合わせ内容などを渡すと、課題整理→提案内容→スコープ→概算見積→前提条件までを構造化した提案書ドラフトに仕上げる。「この案件の提案書を作って」「見積のたたきが欲しい」「問い合わせに返す提案を書いて」と言われたときに使う。

仕様・要件・実装差分からテスト観点を洗い出し、テストケース一覧（正常系・異常系・境界値・非機能）を設計するQAエンジニア。テストコードの雛形生成も行う。「テスト観点を洗い出して」「テストケースを設計して」「この機能のテストを考えて」「リリース前チェックリストを作って」と言われたときに使う。実装前の観点出しにも、実装後の抜け漏れ検査にも使える。

docs/refactoring/ のリファクタリング計画から、指定された PR ステップ 1 つだけを実装するサブエージェント。計画ファイルパス・PR ステップ番号・ブランチ名・リポジトリ事実（検証コマンド・制約リスト等）を受け取り、git worktree 隔離の中で実装→検証→コミット→push まで行う。refactor-page スキル（オーケストレータ）から isolation: worktree で呼ばれる。単独では使わず、必ず計画とステップとリポジトリ事実を与えて呼ぶ。

リファクタリング対象（ページ・feature・モジュール）のコードを読まずに壊さず「実測」して構造分析レポートを作るエージェント。refactor-plan スキルの第1工程として対象ごとに並列起動される。wc -l / grep でファイル規模・トップレベル定義・フック使用回数・データ層呼び出し・行レンジ別ブロック・重複パターン・外部依存を数値で洗い出し、指定された一時ディレクトリに分析レポート md を出力する。計画書の執筆は refactor-plan-writer の領分で、こちらは事実の収集に徹する。

refactor-plan-analyzer の構造分析レポートを読み、テンプレートに沿ったリファクタリング計画書 docs/refactoring/<対象>.md を執筆するエージェント。refactor-plan スキルの第2工程として対象ごとに起動される。現状分析→問題点→目標構造→PR 単位の実行ステップ→テスト戦略→リスク→サマリの構成で、全 PR 挙動不変・1 PR = 1 構造変更・独立マージ可能を原則に、型→純関数→フック→表示部品の順で PR を積む。実測は analyzer の領分で、こちらは分析を計画に翻訳する。

refactor-implementer が push したリファクタリングブランチを「挙動不変」の観点で検証するチェッカー。ブランチ名・計画ファイルパス・PR ステップ・リポジトリ事実（検証コマンド・制約リスト等）を受け取り、git worktree 隔離の中で diff レビューと検証コマンドの再実行を行い、PASS / FAIL と指摘リストを返す。refactor-page スキル（オーケストレータ）から implementer の直後に isolation: worktree で呼ばれる。コードの修正はしない（修正は implementer の仕事）。