インストール
npx skills add firecrawl/skills誰向けか
AI コーディング Agent に、下層の取得 API を呼ぶだけでなく、結果のある Firecrawl ワークフロー成果物を渡してほしいときに、この一式を使う。公式はここを Firecrawl ワークフロースキルの事実上の源と呼び、調査報告、SEO 監査、QA 報告、知識ベース、リード名簿、Agent が使えるサイトデザインシステムを扱う。ワークフロースキルは全部で 16。すでに明確な納品物があり、Agent が公開ページを訪れることを受け入れられる人に向く。ページは秘密変数名を書いていない。自分で作らない。資格情報が必要なときはインストール後のスキル説明に従う。変えたいのが CLI スキル家系（調査/開発者インデックスを含む）なら、公式は firecrawl/cli を指し、本リポジトリでの変更ではない。
3 分で最初の試行を終える
公式の第一選択インストール、つまり完全カタログ（これらのワークフローを含む）だけを使う：
npx skills add firecrawl/skills
同じページは、本リポジトリから直接入れてもよく、同じ 16 ワークフローを提供すると書く：
npx skills add firecrawl/firecrawl-workflows
最初は最初のコマンドを使う。二つを一本に繋がない。カタログも臆測で作らない。継続的インテグレーションが本リポジトリの skills/ を firecrawl/skills へミラーする。それが推されているインストール入口であり、二番目のコマンドの別表記ではない。
入れ終わったら、先に低リスクの照合をする。目標が短い調査報告なら、どの種類のワークフローを使うか、あなたが渡したどの URL を訪れるか、ファイルを書くかを Agent に言わせる。先に「いまは計画だけで取得しない」と復唱させる。URL が実在し訪問が許されることを確認してから実行を許す。成功の合図は、Agent がワークフロースキルで手順を組むことであり、未記載のスキル短縮名を作らないこと。最初にリード名簿やサイト全体のデザインシステムはしない。副作用が大きい。
利用事例
事例一：調査報告または知識ベース。Agent に題材と取得を許す URL を渡し、ワークフローで調査報告または構造化知識ベースを出させる。公開ページを一通の読める材料にまとめたい人向け。説明に報告テンプレートは無いので、体裁は実際の出力に従う。実行前に、渡していない住所を取得しないことを確認する。
事例二：QA 報告または SEO 監査。公開済みページを Agent に渡し、ワークフローで品質確認または SEO 監査をさせる。公開後の公開ページ照合向けであり、コード変更ではない。監査は対象サイトを訪れるので、先にドメインを確認する。ページは QA 報告と SEO 監査を結果一覧に並べるが、点検項目表は無い。必ず覆う項目を作らない。リード名簿とサイトデザインシステムも同じ一覧にある。根拠は「これら 16 ワークフローの成果物の種類である」までで、段階操作は無い。
利用上の境界
第一選択のインストールは npx skills add firecrawl/skills。本リポジトリのコマンドは、カタログを通らないとき用に同じ 16 スキルを提供する。ワークフローは本リポジトリで書く。CLI スキル家系の変更は次を指す：
https://github.com/firecrawl/cli
カタログリポジトリ：
https://github.com/firecrawl/skills
秘密変数やスキル短縮名を作らない。クライアントは指名されていないので、独占対応だと推測しない。取得と報告作成はどちらも副作用がある。先に確認する。リポジトリページ：
https://github.com/firecrawl/firecrawl-workflows