Skill.md検索

Steel.devクラウドブラウザを使い、実ユーザー視点でWebアプリを自動テストし、バグを検出できます。 ページレンダリング、リンク・フォーム機能、エッジケース（空入力、特殊文字、ネットワーク遅延）、JavaScriptエラーを包括的にチェックできます。 検出したバグをCritical/High/Medium/Lowに分類し、Tier（Quick/Standard/Exhaustive）に応じた自動修正ループで品質を向上させます。 テスト実行から修正検証までのワークフローを自動化し、Paperclip Heartbeatで定期的にQAを実行できます。 Web アプリケーション開発チームの品質保証（QA）担当者 継続的デリバリーで定期的な自動テストが必要なスタートアップやSaaS企業 ブラウザの互換性確認やレイアウト崩れ検出を自動化したいフロントエンド開発チーム バグ検出から修正検証までを効率化したいプロダクト開発チーム Dev QA（Browser Testing & Bug Fix Agent）は、Steel.dev クラウドブラウザAPI を使い、Paperclip Heartbeat上でWebアプリを実ユーザー視点でテストします。 環境変数STEEL_API_KEY、PAPERCLIP_API_URL/KEY、COMPANY_ID、RUN_IDを設定後、Heartbeatフローは以下の通り：割り当てIssueを取得 → テスト対象URL・スコープを抽出 → ブラウザセッション作成 → テスト実行・バグ検出・修正・再検証 → レポートをIssueコメントに投稿 → セッション終了。 Steel.dev API操作は、POST /sessions でセッション作成（CDP_URL取得）、POST /actions/navigate でページ遷移、GET /actions/screenshot でスクリーンショット取得、DELETE /sessions でセッション終了。テストプロセスは、IssueからTarget URL・Scope・Tier を抽出。テスト実行ではレンダリング（HTTP 200、レイアウト、モバイル表示）、インタラクション（リンク・フォーム・ボタン・連打耐性）、エッジケース（空入力・特殊文字・遅延・戻る）、コンソール（JSエラー・ネットワークエラー）をチェック。バグをCritical/High/Medium/Low に分類し、Tier別に修正範囲を決定します。

売れるアイデアを「拾って」設計：お客さんの脳内にある「売れる世界」を探し出し、その世界で求められる隠れた提案を考える。クリエイティブに「生み出す」のではなく「拾う」ことで、実際に売れるコンセプトを発掘します。 ベネフィットを引き出して訴求：商品の特徴やメリットではなく、お客さんが本当に欲しい「嬉しい未来」を定義。「ということはつまり法」やターゲット分析で、刺さるベネフィットを導き出します。 ターゲット別に訴求トーンを切り替え：関心度別に「タイプ①（購入意欲高）→シンプルにオファー」「タイプ②（検討客）→差別化を強調」「タイプ③（非関心）→ベネフィットに徹する」と3種類の訴求を使い分けます。 キャッチ・リード・ボディの構成を一気通貫で設計：13の表現法に基づいたキャッチコピー、引き込むリード、説得するボディまで、段階的に読者の感情を動かす文章構成を組み立てられます。 広告・LP・DM等、文章だけで売る案件を手がける営業やコピーライター：アイデア発掘から執筆まで、体系立てたプロセスで効率的に売れるコピーを作りたい人。 ベネフィット抽出やターゲット別訴求を素早く出したい人：複数の商品やキャンペーンで繰り返し使える、実践的な設計フレームワークが欲しい人。 成約率を高めたい事業者：心理トリガーやオファー設計の技術を学び、非対面・非接触でもバカ売れさせる仕組みを構築したい人。 商品の価値をうまく言語化できていない人：特徴の羅列ではなく、お客さんの「欲しい気持ち」に直結するコピーを書きたい人。 セールスコピー設計ガイドは、「見て、読んで、買ってもらえるコトバの作り方」を体系化。基本は①セールスコピーは売れるアイデアを探して表現する技術であること②売れるアイデアは「拾うもの」で、3ステップ（脳内の売れる世界を探す→隠れた提案を考える→魅力的に語る）で完成すること③お客さんはベネフィット（嬉しい未来）にお金を払うこと。ベネフィット導出は「ということはつまり法」か「ターゲット像の明確化」で実施。ターゲットは関心度で3タイプ（①購入意欲高：ブランド力・信頼・超強力オファーで判定、シンプル訴求→②検討客：差別化要因で判定、違いを強調→③非関心：最高解決策提案）に分類し、各タイプのドンピシャ訴求トーンを変える。コピー構成はキャッチ（初心者4ステップ法と13の表現法）→リード→ボディの段階的構成で、読者感情を掴んでから説得へ導きます。

モバイルやCloudflare経由でセッション開いた直後に発生する「再接続中...」ループを診断・修正できます。 ブラウザコンソールの WebSocket connection failed エラーと 502 Bad Gateway の原因を特定できます。 ttydプロセス起動時のタイミングレース問題を解決する2段階確認方式を実装できます。 サーバーログから「ポートリッスン準備完了」を確認してからクライアント接続を許可する仕組みに変更できます。 既存アクティブセッションの再起動時に旧ロジックが残っている問題を検出・修正できます。 ttydを使ったブラウザベースターミナルを運用している開発者 モバイルやプロキシ経由でのリモート接続が多い環境の管理者 WebSocket接続エラーのトラブルシューティングに時間がかかっている方 接続の安定性を改善したいインフラエンジニア ttydプロセス起動には2つのステップが存在します：(1)プロセス起動（spawn完了）と(2)ポートリッスン開始（WebSocket接続受付可能）。旧実装では(1)までしか確認していないため、クライアントが(2)完了前にWS接続を試行してしまい失敗します。特にCloudflare Zero Trust経由ではプロキシ遅延により顕著に発生します。解決策として、新規メソッド waitForTtydReady() を実装し、ポートリッスン確認を10秒間、100ms間隔でリトライします。このメソッドは port、timeoutMs、retryIntervalMs をパラメータに取り、ポート監視完了時に「Port ready after XXXms」ログを出力します。session-manager.js の起動フローに2段階確認方式を導入し、Step 1でプロセス生存確認、Step 2でポートリッスン確認を実行する実装が commit: e0775da で提供されています。

AIに業務の80%以上を実行させる「業務主体性の逆転」により、人間のボトルネック（調整・ルーチンワーク・中間管理）を排除した組織構造を構築できます。 Midjourneyのように11人のチームで年間300億円規模の売上を実現するなど、従来型企業の約50倍の一人当たり生産性を達成する仕組みを設計できます。 マネジメント・アズ・コード（MaC）により、組織ポリシーや技術標準をコードベースのガバナンスに転換し、人間の介入なしにコンプライアンスとベストプラクティスを自動保証できます。 エンジニアリング中心主義（組織の60%をエンジニアで構成）により、AIシステムの構築・維持・改善能力を最大化する人材配置戦略を立案できます。 戦略的判断の質と創造性に組織のボトルネックを転換することで、スケーリングを人件費や採用難易度に左右されない構造に変革できます。 少人数で大きな成果を上げたいスタートアップの経営者やファウンダー 組織の生産性向上に課題を感じている企業の経営幹部やCEO AIを事業の中核に据えて組織全体を再設計したいテクノロジー企業のリーダー 中間管理機能をコード化して意思決定の質を高めたいエンジニアリング組織の責任者 このスキルは、AIファースト企業が採用する「人間をボトルネックとしない」組織論と仕組み化戦略を詳細に解説しています。 三つの基本原則： 1. 業務主体性の逆転（AI実行率80%の法則） - 従来の人間主体から、業務の80%以上をAIが実行する体制へシフト。Midjourneyはコンテンツ生成100%、カスタマーサポート90%、マーケティング85%をAI実行。 2. エンジニアリング中心主義（60%人材配置ルール） - エンジニア60%以上、プロダクト20%、ビジネス20%の構成。AIシステムの構築・維持・改善能力の最大化を図る。 3. マネジメント・アズ・コード（MaC） - 従来のマネジメント機能をコードベースのガバナンスシステムに代替。Cursorなど経営者不在の組織で実践。組織ポリシーをAIエージェント実行コンテキストに直接適用し、人間介入なしに自動で保証。 生産性指標の破壊的インパクト：Midjourneyの11人チームが年間$200M収益、一人当たり年間$18M達成（従来型スタートアップの約50倍）。このパラダイムシフトは単なるツール導入ではなく、組織設計の根本的革新による結果。従来の「人を増やして売上を伸ばす」モデルから脱却し、戦略的意思決定の質へボトルネックを転換。

返信やプロフィール遷移を増やすための投稿設計を逆算で行い、実装可能な具体策を自動生成できます。 マーケティング・コンパスのWHO×WHATから、ターゲットユーザーとメッセージの整合性を検証し、一貫性のあるアカウント戦略を立てられます。 ドラマ・断定・実験ログ・共感など4つのレーン（投稿パターン）を自動分配し、SNSの「揺れ」を保ちながら効果的な運用ができるようになります。 Promise（約束）・Proof（証拠）・Path（次のステップ）の観点からプロフィール設計を最適化し、ユーザーの行動喚起を促進できます。 アカウント設計の変更を自動的にSSOT（_codex配下のルール定義）に反映させ、チーム全体で統一的な運用ルールを共有できます。 SNSを事業の重要なチャネルとして活用したい起業家やマーケティング責任者 X（Twitter）での発信効果を高め、プロフィール訪問やフォロワー増を目指す個人事業主やPM 複数人でSNSアカウントを運用し、投稿ルールを一元管理したい組織 投稿内容のバリエーション（レーン）を保ちながら、戦略的にプロフィール遷移を促進したい運用チーム SNS Account Factoryは、返信・プロフィール遷移を起点にbrainbaseのSSOT（_codex）と工場ラインへ落とすアカウント設計を行います。参照すべきSSOTは_codex/sns/x_account_profile.md、_codex/sns/sns_strategy_os.md、_codex/sns/x/00_line_charter.md、_codex/sns/x/ops/variety_gate.md、_codex/sns/x/ops/runbook.mdです。ワークフローは行動ゴールからの逆算（返信/プロフィール遷移→低コスト回答→A/B選択）、WHO×WHAT再確認（少人数経営者向けマネジメント自動化ログ）、Promise/Proof/Pathでのプロフィール設計、レーン分け（ドラマ・断定・実験ログ・共感），返信/遷移トリガー設計、SSOTへの反映（line_charter/variety_gate/runbook/account_profile更新）で構成されます。全投稿に同一ルールを当てず、レーン運用で揺れを残すことが必須。出力はPromise/Proof/Path案、レーン配分、SSOT差分。

マーケティング・インサイドセールス・営業・カスタマーサクセスの4部門が行う営業プロセスを「分業から共業」へシフトさせ、各段階のハンドオフ基準を明確に設定できます。 リード獲得から受注、そして顧客活用まで一貫した「顧客ステージ」と「商談フェーズ」の体系を設計し、各部門のKPIと責任を整理できます。 新規リードの65%が「将来購入の可能性はあるが今すぐではない」という見込み客であることを踏まえ、失注・未商談リードの再商談化（リサイクル）プロセスを構築できます。 営業活動を5つのフェーズ（フェーズ1: 0%～フェーズ5: 75%）に細分化し、各段階での移行判定基準と顧客対応を明示できます。 SMB市場とエンタープライズ市場の違いに応じた戦略・人材・営業モデルを使い分け、「選択と集中」に基づく事業計画を立案できます。 B2B企業でマーケティングから営業、CSまで一気通貫で営業成果を高めたい経営者や営業責任者 レベニュー組織のボトルネック診断を行い、各部門のKPI・ハンドオフ基準を整備したい営業企画・組織開発担当者 インサイドセールス組織を立ち上げる際に、リード育成と商談供給の基準を明確にしたい企業 SMBとエンタープライズの異なる市場戦略を同時に運用し、市場戦略に基づく人材採用・育成を行いたい企業 このスキルは『ザ・モデル』に基づくB2B営業プロセス設計の体系的フレームワークです。 ザ・モデルの核となる概念：営業プロセスを従来の「一人が全工程を担当」から「部門横断の分業・共業」へシフト。マーケティング（リード獲得）→インサイドセールス（ナーチャリング・クオリファイ）→営業AE（提案・交渉）→カスタマーサクセス（活用促進・アップセル）の専門分業で再現性を追求。 顧客ステージ：認知拡大 → リード獲得 → リード育成 → 有望リード（購買意欲高）の4段階でマーケティング・インサイドセールスが管理。 営業フェーズ（5段階）：フェーズ1（0%確度、リード以上商談未満）→ フェーズ2（25%、課題認識とBANT確認）→ フェーズ3（30%、評価・選定・差別化）→ フェーズ4（50%、最終交渉・Mutual Close Plan）→ フェーズ5（75%、稟議決裁）。 リサイクルの重要性：失注・未商談リードはMA（マーケティングオートメーション）による継続ナーチャリング対象。リード件数を4倍にせず、既存リードの再商談化で効率化。 市場戦略：SMB市場（安定基盤、Volume×Velocity）とエンタープライズ市場（成長基盤、高単価）で異なる営業組織・人材・プロセスを適用。選択と集中で集中投下。

PMとして必要な4つのコア技能（コミュニケーション・組織化・リサーチ・実行）を習得し、日々の判断に活かせます。ステークホルダー管理やチームマネジメントで具体的な指針が得られます。 ユーザーリサーチの正しい進め方を学び、仮説検証に基づく意思決定ができるようになります。ペルソナの罠や「ベストプラクティスの限界」など、実践的な落とし穴を避けられます。 上司や経営層との関係構築、「権力から情報へ」の転換、Disagree & Commitなど、階層を超えたコミュニケーションテクニックを活用できます。 曖昧さに対処し、チームのベストを引き出し、直属チーム以外との協業を円滑にする3つのPM責任を果たせるようになります。 アジャイル実践やロードマップ作成、優先順位付けなど、PM業務全般で迷った時に参照・判断できる実践的ガイドが得られます。 プロダクトマネージャーとしてステークホルダー管理やチーム協業に悩んでいる人 上位者の指示と実現性のギャップで困っている企画・マネージャー職の人 優先順位付けやロードマップ作成で判断基準を探している人 ユーザーリサーチやデータ分析に基づいた意思決定を強化したい人 Matt LeMay著『Product Management in Practice, 2nd Edition』に基づくPM実践ガイド。PMの3つの責任は「チームメンバーのベストを引き出す」「直属チーム以外の人と一緒に働く」「曖昧さに対処する」。悪いPMの5パターン（ジャーゴンジョッキー、スティーブ・ジョブズ信奉者、英雄のPM、張り屋さん、殉教者）を回避する指針を提示。COREスキルは①コミュニケーション（明快さと心地よさのバランス）②組織化（自らを不要とする）③リサーチ（好奇心をもって生きよ）④実行（すべての努力はアウトカムのために）。ユーザーリサーチは週1回以上、「ペルソナの罠」を避けて実在ユーザーと話すこと。Disagree & Commitの実践、シニアステークホルダーマネジメント、フレームワークの限界理解など、実践的な技術とマインドセットを習得できます。

_codex正本ファイルとプロジェクト側ファイルのリンク切れを自動検出し、修正対象を明確化できます。 プロジェクト側が誤ってコンテンツを直接編集していないかをチェックし、「情報の一本化」原則を守れるようになります。 01_strategy.md の必須項目（プロダクト概要・ICP・価値約束・価格・TTFV目標・KPI・アクションなど）が全て揃っているかを一発検証できます。 全プロジェクトの01～05ファイル充足率をレポートし、設計漏れを組織全体で可視化できます。 _codexの正本性を維持し、プロジェクト間での情報ズレを防ぐ運用をルール化できます。 複数プロジェクトを一元管理し、情報ガバナンスを強化したいPOやプロダクト責任者 brainbase運用の正当性を確認したい事業責任者やGM（ゲームマスター） ドキュメント管理の自動化により、手作業チェックを減らしたい運用チーム Git管理とDB管理の役割分担を厳格に実行したい組織基盤チーム _codex正本検証ロジックはbrainbaseの4大原則「情報の一本化」を守るため、_codex配下のみを編集対象とし、プロジェクト側はリンク参照のみに統制します。検証項目は、リンク切れ検出（PROJECT_FILEが_codexを参照しているか・参照先ファイルが存在するか）、誤編集検出（プロジェクト側の行数・見出し含有をチェック）、正本必須項目チェック（01_strategy.mdの「プロダクト概要」「ICP」「価値約束」「価格」「TTFV目標」「主要KPI案」「次のアクション」）、01-05充足率チェック（全プロジェクトで01～05ファイルが揃っているか）です。検証結果はサマリ形式で、OK/警告/エラー件数、詳細（プロジェクト毎の項目チェック）、推奨アクションを出力。

新規リード獲得用LP（ランディングページ）や広告文を、体系的な3ステップで素早く組み立てられます。「特徴→欲しい人→ベネフィット」の流れで、商品の魅力を正しくターゲットに伝える提案文が作成できます。 キャッチコピー、ボディコピー、CTA（Call-to-Action）など、オンラインで売るための「読まれる提案」を、10のテクニック（ベネフィット表現、ターゲット絞込、驚き・禁止・数字・証拠・結果・五感・ストーリー）を活用して磨き上げられます。 読まれない広告をAB テストなしで改善できます。成功の80%は「書く前の思考」で決まるという原則のもと、ターゲット分析→ベネフィット明確化→キャッチコピー設計を正確に実行するので、「とりあえず書いてみた」という試行錯誤が減ります。 既存顧客以外の「欲しい人」を発見し、新しい市場セグメントへのアプローチも可能。商品の特徴を再解釈して、全く別の購買層にリーチするLPが作れます。 新商品・サービスのLP・広告文を作りたい企業のマーケティング担当者。テンプレートに頼らず、本質的に売れるコピーを作りたいとき。 既存の広告・LPが読まれていない、コンバージョン率が低い企業。「何が悪いのか」を言語化し、テクニック別に改善できます。 リード獲得単価（CPA）を下げたい営業・マーケティングチーム。読まれる提案なら広告費の無駄が減ります。 e-コマース、SaaS、オンラインコース等、オンライン販売の比率が高い企業。 『ポチらせる文章術』の本質は「見てもらい、共感してもらい、買ってもらう」というゴール達成のためのネット文章術。売れない広告の最大原因は「読まれていない」こと。コピーライティング成功の80%は「書く前の段階」で決まり、「考える8割+表現する2割」が重要。基本ルール「欲しい人へ、欲しいものを売る」を徹底すれば他要素（価格・ブランド）に惑わされない。3ステップ：①商品特徴・メリットの洗い出し→②既存ターゲット以外で「欲しい人」を探す（視点転換で欲求高い泳ぎを発見）→③ベネフィット明確化（商品入手で解決される問題・ハッピーな未来を具体的にイメージ可能に）。キャッチコピーは読み進めるか判断する最重要要素で、10テクニック：ベネフィット語る、ターゲット絞込、驚き提供（ザイガニック効果）、オファー提示、禁止（カリギュラ効果）、数字活用、証拠提示、結果ビフォーアフター、五感訴求、ストーリー（V字構造：日常→どん底→成功）で構成。

日本のトップマーケター16人による、実際のヒット商品・サービスの成功事例から営業・マーケティング戦略を即座に参照できます。 「Amazonと自社サイト、どちらの販売チャネルを重視すべき？」「インフルエンサーを活かした販売展開とは？」といった具体的な経営判断の参考になります。 EC・D2C（Direct to Consumer）事業で新商品をヒットさせるための思考法やパターンを、実際の事例を通じて学べます。 EC・D2C事業に携わるマーケターや企業経営者 新商品・新サービスのローンチ戦略を検討している方 インフルエンサー活用やSNSマーケティングを計画している事業者 ECモール（AmazonやShopifyなど）と自社サイトの戦略的な使い分けを知りたい方 本書は16人のトップマーケターの事例を6章＋応用編で構成。第1章は「トレンド×自社強み×明確なコンセプト」の掛け合わせやニッチ市場狙いの事例（YOLU、BULK HOMME、BOTANIST）。第2章はインフルエンサー発のP2C戦略からD2C化への進化（VALXプロテイン・山本義徳事例で「シャワー効果」によるファン拡大を記録）。第3章は「プロセスエコノミー」として製造過程や作り手の努力に価値を付与する手法（FACTELIER工場直結戦略、TELESA育児ターゲット設定）。第4章はAmazon・楽天等ECモールと自社サイトの特性を活かした売上最大化戦略（ALLNA ORGANIC競合ベンチマーク手法）。第5章はニッチ市場特化プラットフォーム、第6章は経営改革によるブランド刷新事例を扱い、全体として「売れた未来から逆算する」ビジネス設計の本質を記述しています。

brainbase-uiのコード変更時に、バージョン番号を自動的に更新する手順を提供します。 MAJOR・MINOR・PATCH の3段階で、変更内容に応じたセマンティックバージョニングを適用できます。 package.json と index.html（デスクトップ・モバイル両対応）に統一されたバージョンを自動反映できます。 サーバーの再起動コマンドを自動実行し、バージョン変更を即座に反映できます。 コミットメッセージに自動的にバージョン情報を付与し、変更履歴を正確に追跡できます。 brainbase-ui の開発・保守を担当する開発者 UIのリリース管理を確実にしたいプロジェクトマネージャー バージョン管理の手順をチーム全体で統一したい開発リーダー ユーザー向けにUIバージョンを常に正確に表示したい製品チーム バージョン形式は「v0.0.0」（vプレフィックス必須、セマンティックバージョニング採用）。更新基準：破壊的変更は MAJOR、新機能追加は MINOR、バグ修正・小さな改善は PATCH。更新手順：①package.json の"version"フィールド更新、②index.html の2箇所（デスクトップ版: id="app-version"、モバイル版: id="mobile-app-version"）を手動更新、③サーバー再起動（ps aux | grep "node.*server.js" | grep -v grep | awk '{print $2}' | xargs killで停止後、nohup node server.js > /tmp/brainbase-ui.log 2>&1 &で起動）、④コミットメッセージに「feat(ui): 説明 (v0.1.1)」形式でバージョン含める、⑤デスクトップ左ナビ最上部・モバイルセッション一覧ヘッダーで表示確認、curl http://localhost:3000/api/versionで確認可能。実装場所：package.json（正本）、server.js（/api/versionエンドポイント）、index.html（バージョン表示要素）、app.js（loadVersion()関数）、style.css（.app-versionスタイル）。

ユーザーが「これスキルに登録して」と一言指示するだけで、直前の会話内容や調査結果からClaudeスキル（SKILL.md）を自動的に抽出・作成できます。 複数の研究調査結果やトラブルシューティング手順など、再利用性の高い知識を自動的にスキル化して.claude/skills/{skill-name}/に配置できます。 kebab-case形式の適切なスキル名を自動提案し、既存スキルとの重複をチェックして命名ミスを防げます。 SKILL.mdの必須要素（YAML frontmatter、目的、機能説明、使用方法、コード例）を自動生成し、.claude/skills/README.mdも更新されるため、スキルライブラリが常に最新に保たれます。 スキル化により、類似タスク時にユーザーが過去の手順や知識を素早く参照でき、チーム全体の効率化につながります。 日常的に調査やトラブルシューティングを繰り返し、その知識を属人化させたくない開発者・エンジニア プロジェクト独自の手順やベストプラクティスをチームで共有・再利用したいテックリード 会話の中で「これは今後も使いそう」と思った内容を手軽にドキュメント化したい全職種 Claude Skillsの運用で、スキル作成・登録の手間を削減したい運用者・管理者 スキル作成は4つのフェーズで進みます：(1)要件分析—ユーザー指示から対象範囲、目的、利用シーン、必要情報を抽出、(2)スキル設計—name（kebab-case）、description（1-2文）、purpose、features（機能リスト）、usageCases、codeExamples配列を設計、(3)SKILL.md生成—設計に基づき「name」「description」YAMLフロントマター、「目的」「主な機能」「使用方法」「コード例・コマンド例」「関連ドキュメント」セクションのMarkdownを生成、(4)ファイル配置—mkdir -p .claude/skills/{skill-name}してSKILL.mdを配置、README.mdを更新。出力ファイル構造は.claude/skills/README.md（スキル一覧）と.claude/skills/{skill-name}/SKILL.md（スキル詳細）です。コード例にはlanguage（typescript、bash、markdown等）、code（実コード）、description（説明）を含めます。

worktree環境で開発サーバーを起動する際、既存サーバーとのポート競合を自動的に回避できます。 使用可能な最小ポート番号（3001から開始）を自動選択し、複数の開発環境を同時に実行できます。 正本（main）用ポート3000と worktree用ポート（3001以降）を明確に分離し、環境ごとに独立した開発サーバーを管理できます。 バックグラウンドでサーバーを起動することで、ターミナルを占有せずに開発を継続できます。 Gitのworktreeを使った並行開発を行うエンジニア：複数ブランチで同時に開発サーバーを起動したい フルスタック開発者：フロントエンドサーバーを複数環境で実行し、異なる機能の検証を同時に行いたい チーム開発をしている人：main環境を影響を受けないようにしながら、feature環境で開発・テストしたい worktree開発サーバー起動の手順は以下の通りです。1. ポート確認：lsof -i :3000 -i :3001 -i :3002 -i :3003で使用中のポートを確認し、3001から開始する最小の空きポートを選択。2. 依存関係インストール：node_modulesがない場合はnpm installを実行。3. サーバー起動：PORT=[空きポート] npm run devで起動。バックグラウンド起動はrun_in_background: trueを使用。ポート割り当ては、3000を正本用、3001以降をworktree用とします。worktreeではnode_modulesが各worktreeで独立しており、シンボリックリンクではなく実物コピーである点に注意が必要です。

ワークフロー課題の自動検出：プロジェクトのタスクやマイルストーン管理がbrainbase標準に適合しているか自動チェックし、不整合な部分を具体的に特定できます。 標準準拠度の数値化：タスクフォーマットとマイルストーン管理ルールの適合率を算出し、現状の問題度を数字で把握できます。 優先度付き改善提案：検出された課題に対して、brainbase価値観に基づいた推奨アクションを優先度順に提示し、何から取り組むべきかが明確になります。 検証レポート自動生成：2段階の分析プロセス（要件分析→レポート生成）で、課題サマリーから詳細リストまで一貫した検証レポートを自動作成できます。 プロジェクトマネージャー：プロジェクトのワークフローが標準に沿っているか確認し、改善の指針を得たい。 プロジェクトリーダー：チームのタスク管理やマイルストーン設定に問題がないか客観的に評価したい。 品質保証担当者：複数プロジェクト間で管理ルールの統一度を測定したい。 プロセス改善担当者：ワークフロー最適化の課題を体系的に洗い出し、優先順位を付けて改善したい。 このOrchestratorは2 Phase workflowでプロジェクトワークフローの検証を自動化します。Phase 1（要件分析）では、プロジェクト配下のファイルを調査し、task-formatスキルでタスク管理標準フォーマット、milestone-managementスキルでマイルストーン管理ルールとの整合性をチェック。適合率を算出し、具体的な課題リストを出力します。Phase 2（検証レポート生成）では、Phase 1で特定した課題リストと適合率をinputとして受け取り、principlesスキルでbrainbase価値観に基づいた優先度付けを行い、最終的な検証レポート（課題サマリー+重大度別分類+推奨アクション）を生成します。入力はプロジェクト名（必須）と検証スコープ（オプション）で、出力はMarkdown形式の検証レポートです。

マイルストーン・スプリント・タスク・シップの4テーブルを連動させ、Decision→Work→Ship→Learnの循環を継続的に回せるようになります。 プロジェクト進捗をリアルタイムに可視化し、ブロッカーや学びを次の判断に素早く反映させられます。 NocoDBベースIDと対応するGM（責任者）を一元管理し、プロジェクト横断で統一的な運用ができるようになります。 スプリント単位の週次目標と個別タスクを効率的に計画・実行・評価できるようになります。 複数のプロジェクトを並行管理するプロダクトマネージャーや事業責任者 スタートアップで高速なPDCAサイクルを回したい経営層 チームの進捗管理を自動化し、手作業を減らしたい管理者 Value Loop（意思決定→実行→納品→学習）の循環を形式知化したい組織 NocoDB 4テーブル運用は、brainbaseの根幹をなす循環モデル（Value Loop）を回し続けるための装置です。Decision→Work→Ship→Learnの4フェーズが止まると組織は停止し、速く回すほど強くなります。4テーブルとの対応は、マイルストーン（Decision：何を達成するか）、スプリント+タスク（Work：計画・実行）、シップ（Ship：成果を外に届ける）、スプリント振り返り（Learn：学びを次に返す）となります。情報の正本は2層に分け、WHY・ルールは_codex/のGit、進捗・ステータスはNocoDBで管理します。テーブル間のリレーションはマイルストーン1:N→シップ→タスク、スプリント1:N→タスクで構成されます。各プロジェクトベースのID一覧（BAAO、DialogAI、NCOM、SalesTailor、Senrigan、Mywa、Zeims、BackOffice、Brainbase、Tech Knight、VibeProなど）とGM責任者が記録され、4テーブル（マイルストーン・スプリント・タスク・シップ）の構造・カラム設計により統一的な運用を実現します。

fly logsコマンドの無限実行を防止 - ストリーミング方式のfly logsコマンドに自動的にタイムアウトを設定し、処理がハングアップするのを確実に防げます。 目的に応じたタイムアウト時間を自動提案 - 特定ログ検索は10秒、直近ログ確認は10-15秒、長期調査は30秒など、用途に応じた推奨タイムアウトを提示できます。 grepと組み合わせた効率的なログ検索 - エラーログのみ抽出、特定機能のログ追跡、アクセスログ検索など、必要な情報だけを素早く取得できます。 複数のタイムアウト設定方法に対応 - timeoutコマンド、Bashツールのtimeoutパラメータなど、実行環境に応じた設定方法を使い分けられます。 適切なエラーハンドリング - タイムアウトしても結果が得られない場合の対処法や、タイムアウト前に終了する場合の確認手順を提示できます。 Fly.ioでアプリを運用するエンジニア - ログ調査時のハングアップを確実に防ぎ、デバッグを効率化できます。 Claude Code開発者 - Bashツールでfly logsを実行する際、ミリ秒単位のtimeoutパラメータを正確に設定して安全に実行できます。 本番環境トラブルシューティングの担当者 - エラーログを素早く特定・抽出し、障害対応を迅速に進められます。 複数Fly.io環境を管理するチーム - --configオプションで正しい設定ファイルを指定しながら、複数環境のログを安全に確認できます。 fly logsはストリーミング方式でログを出力し続けるため、タイムアウトを設定しないと無限に実行され続けてハングアップします。timeoutコマンド使用時はtimeout 10 fly logs --config fly.web-unson.toml形式で秒単位で設定。Claude CodeのBashツール使用時はtimeoutパラメータをミリ秒単位で設定（10秒=10000）。推奨タイムアウト時間：特定ログ検索10秒、直近ログ確認10-15秒、長期調査30秒。よくある使用例：エラーログ検索はtimeout 10 fly logs --config fly.web-unson.toml 2>&1 | grep -i "error\|exception\|failed" | head -30、特定機能ログ追跡はtimeout 15 fly logs --config fly.web-unson.toml 2>&1 | grep "フォーム送信" | head -50。トラブルシューティング：タイムアウト後も結果が得られない場合はタイムアウト延長（15-30秒）またはgrep条件緩和；タイムアウト前に終了する場合は正常動作です。ベストプラクティス：常にタイムアウト設定、grep+headで効率化、2>&1でエラー出力も含める、10-15秒を基準に調整。

複雑な業務やプロセスを「システム思考」で分解し、改善可能な形に構造化できます。 属人化した業務を手順化・標準化し、誰でも同じ結果を生み出せるようにドキュメント化できます。 問題が発生したときに根本原因を特定し、火消しではなく継続的改善に転換できます。 組織全体で必要な「戦略的目標」「運営原則」「作業手順」の3つの文書を構築できます。 経営やチーム運営の視点を客観的に高い位置から捉え直し、システム全体の効率性を向上させられます。 経営者・マネージャーが、チームの生産性を高めたい場合 業務が複雑化して対応が後手に回っている組織 スタートアップ・スケール期の企業で業務プロセスを整備したい方 個人の時間管理や人生設計を改善したい起業家やフリーランス 本スキルの根幹は「システム思考」の採用であり、世界をシンプルで制御可能な線形プロセスの集合体として認識します。現実は99.99%が完璧に機能するシステムで成り立っており、失敗は機械的な欠陥が原因です。重要な視点転換は「Outside and slightly elevated」、つまり自分のシステムを外部から高い視点で客観的に観察することです。実行方法は3つの主要ステップで構成されます。第1段階は「分離・解剖・修復」で、問題システムを特定し、非効率性を根本から排除します。第2段階は「文書化」で、改善されたシステムの目標・原則・手順を書面化し、「防火環境」を構築します。第3段階は「継続的維持」で、システムの監視・調整・維持を行います。組織全体に適用する際は、「戦略的目標」（会社の方向性を定義する1ページの文書）、「一般的運営原則」（意思決定のガイドライン、2～3ページ）、「作業手順」（1-2-3-4ステップの線形フォーマットで記述）の3つの文書を作成し、すべての業務の基礎とします。

ファイルの性質に応じたコミット先の自動判別: 正本ディレクトリ（_codex, _tasks など）はmain直接、プロジェクトコードはセッションブランチ、という分離ルールを適用できます。 シンボリックリンク方式の正本管理: worktree 作成時に正本ディレクトリへのシンボリックリンクを自動生成し、すべてのセッションで同じ最新正本を参照できます。 セッション終了時の自動マージ処理: /merge コマンドで（1）セッションブランチの変更確認 → （2）正本の変更確認 → （3）マージ実行、を自動で実行できます。 worktree 作成時のセットアップ自動化: ブランチ・シンボリックリンク・CLAUDE.md の初期配置を一括処理できます。 brainbase-ui で複数の worktree を同時運用し、正本ファイルの競合を避けたい開発者 セッションごとに独立した feature ブランチを作りながら、共有ナレッジ（_codex など）は常に最新に保ちたい人 Git worktree のセットアップと mergeプロセスを標準化・自動化したいチーム ブランチ分岐とファイル共有の複雑さを「ファイル性質による分離」で整理したい人 基本原則: ファイルの性質によってコミット先を分離 — 正本ディレクトリ（全セッション共有、性質：常に最新）は main 直接、プロジェクトコード（ブランチローカル）はセッションブランチ。 正本ディレクトリ: /Users/ksato/workspace/ 配下の _codex, _tasks, _inbox, _schedules, _ops, .claude, config.yml。 Worktree構造: /Users/ksato/workspace/.worktrees/session-xxx/ に正本ディレクトリへのシンボリックリンクを配置。CLAUDE.md, brainbase-ui/, projects/ は実ファイル（ブランチローカル）。 コミットフロー: プロジェクトコードはセッションブランチ（git add brainbase-ui/ → git commit）、正本ファイルは main 直接（cd /Users/ksato/workspace → git add _codex/ .claude/ → git commit）。 /merge コマンド: (1) セッションブランチの変更確認・コミット → (2) 正本の変更確認・mainへの直接コミット（確認含む） → (3) セッションブランチを main にマージ。

Airtable API呼び出しで「429 Too Many Requests」エラーが発生した際に、自動的にエクスポネンシャルバックオフ（段階的な待機）でリトライしてエラーを解決できます。 Promise.raceを使ったタイムアウト処理（デフォルト30秒）により、無限待機を防ぎ、エラーハンドリングが確実に動作します。 ページング処理にスロットリング（200ms待機）を組み込むことで、レート制限（5req/秒）を自動遵守し、API削減なしに安定運用できます。 キャッシュやバッチ処理の設計パターンで、API呼び出し回数を削減し、月間リクエスト制限に余裕を持たせられます。 manaプロジェクトでAirtable連携機能を開発・保守するエンジニア Airtableレート制限エラーに頻繁に遭遇する開発者 APIの安定性を重視し、自動リトライ機能を実装したい人 ワークスペース単位のレート制限仕様を理解し、プラン最適化を検討している組織 Airtable APIレート制限対策の実装パターンを提供します。レート制限はワークスペース単位で適用され、Freeプランは5req/秒・1000req/月、TeamプランはTeamプランは5req/秒・無制限、Business/Enterpriseプランは10req/秒・無制限です。実装パターンは3つ：(1)Promise.raceによるタイムアウト処理でオプション指定（デフォルト30秒）、(2)エクスポネンシャルバックオフリトライで最大3回リトライし1秒→2秒→4秒→最大10秒の待機を自動計算、(3)ページングスロットリングで200ms待機を挟み5req/秒以内に抑制。実装例は/Users/ksato/workspace/mana/api/airtable-mcp-client.jsに記載され、各リトライ試行時には必ずログ出力し、pageSize: 100でAPI効率化を実現します。

コードリリース・請求書送付・契約締結など、形式は異なっても「完了して外に出した成果物」を統一的に記録・追跡できます。シップのステータス（planned→in_progress→in_review→shipped→verified）を一貫性を持って管理し、チーム全体のアウトプット速度を可視化します。 North Star指標として「1スプリントあたりのshipped数」を自動集計することで、チームの生産性トレンド・ブロッカーの有無・タスク粒度の適正さを数値で把握できます。 複数タスクを1つのシップに紐付け（N:1関係）ることで、「何をやったら何が出荷されたか」の追跡可能性が向上し、チーム内の因果関係が明確になります。 スクラムマスター・アジャイルコーチ：チームの出荷速度を可視化し、スプリント計画を最適化したい人 CEO・経営層：組織全体のアウトプット（開発・営業・バックオフィス）を統一メトリクスで把握したい人 プロダクトマネージャー：機能リリースから営業資料納品まで、全出荷物のステータスを一元管理したい人 核概念：シップ＝「チームが外に出したもの」。タスク（Input・やること）とシップ（Output・出したもの）の違いを明確に区別。North Star指標＝shipped数/スプリント期間でチーム生産速度を計測。 ステータスフロー：planned（出荷予定登録）→in_progress（作業中）→in_review（レビュー待ち）→shipped（出荷完了、出荷日・証跡URL必須記入）→verified（効果確認済み）。 Ship種別分類：開発系（feature_released・improvement_released・bugfix_released・maintenance_resolved等）、営業・マーケ系（campaign_delivered・sales_material_delivered・contract_executed等）、バックオフィス系（invoice_sent・vendor_paid・expense_reimbursed・month_close_done・tax_filed等）。 タスク紐付け：複数タスクが1シップに紐付く（N:1）ことで、何をやったら何が出荷されたかを追跡可能に。shipped時には出荷日・証跡URL（PR・納品書・メール記録等）必須記入。