Communitygithub.com

Irnist/website-pipeline

エンドツーエンドのクライアントWebサイトパイプライン(ヒアリング → 方向性決定 → 構築 → QA → プレビュー公開 → 納品)。自動操縦で動作し、重要な質問があるときだけ停止します。ユーザーが /website を実行したとき、クライアントサイトの開始/構築/続行を依頼したとき、または「新規Webサイト」ランチャーで作成されたフォルダ内で実行したときに使用します。引数: フリーテキストのビジネス情報、または status | qa | deploy | handoff のいずれか。

website-pipeline とは?

このスキルは、クライアント向けWebサイトの作成プロセス全体を自動化するエージェントスキルです。ヒアリングから方向性決定、構築、QA、プレビュー公開、納品までの各フェーズを、ユーザーの入力を最小限にして自動的に進めます。主にClaude CodeやCodexなどのAIエージェントで動作するように設計されており、指定されたワークスペース内でパイプラインを管理します。特筆すべき点は、自動操縦モードで動作すること、各フェーズ間で「続けますか?」と質問しないこと、Gitによるバージョン管理を徹底すること、そして質問ポリシーとして「クリティカルな問題のみ」をユーザーに問い合わせる点です。QAプロセスでは、専用ツール(qa.py, browser_qa.mjs)を使用して機械的にチェックし、レビュアー(impeccable)によるデザイン批評も自動化されています。サンプルサイト(ポートフォリオ用)と実際のクライアントサイトでモードが分かれており、クライアントモードでは事実の捏造が禁止され、プレースホルダーとdata-todo属性で未定事項を管理します。

対応✓Claude Code~Codex CLI~Cursor
npx skills add Irnist/website-pipeline

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

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

ドキュメント

Webサイトパイプライン

あなたは、クライアントのWebサイトを、生の入力からデプロイされたプレビューまで、可能な限りユーザーの入力を減らして実行します。最初に、すべての実行時(新規、再開、単一フェーズのいずれでも): <pipeline>/RULES.md を読み込んでください。これはWebサイトのルールです。このセッションでまだ読んでいない場合に限ります。このルールはすべてのステップに適用されます。tools/ 内のツールは、それらのほとんどを機械的に強制するため、目視で再確認する代わりにそれらを実行してください。

ワークスペース

すべてのファイルは、1つのワークスペース C:\Users\Administrator\Desktop\Claude Workspace(<workspace>)に配置されます。以下のパスはこれに対する相対パスです。スクリプト内では、ハードコードされたデスクトップパスではなく、スクリプト自身の場所(Path(__file__))からパスを導出してください。

項目場所
パイプライン(<pipeline>)Workflow and Pipeline/website-pipeline/(~/.claude/skills/website はこれへのジャンクション)
共有ツール<pipeline>/tools/: qa.py、browser_qa.mjs、deploy.py…の単一のコピー。各サイトの tools/ には、そのサイトでそれを実行するスタブが含まれています(L-052)。そのため、修正や新しいチェックはすべてのサイトに同時に反映されます。サイト専用のスクリプトはスタブの隣に配置されます。
サンプルサイトConcept Websites/<名前> Website/
オーナーのポートフォリオPortfolio Site/
ポートフォリオのスクリーンショットPortfolio Screenshots/: 完成したサイトのスクリーンショットのみ。それ以外は何も置かない。
スクラッチファイル(テストスクリプト、テストスクリーンショット、バックアップ、埋め込まれた欠陥)_temp/。システムの一時フォルダ、プロジェクト、またはテンプレートには決して置かない。

0. 今どこにいるのか?

フォルダの状態と引数からエントリポイントを決定します:

状態アクション
カレントディレクトリに _src/build.py がないスキャフォールディング: powershell -NoProfile -ExecutionPolicy Bypass -File "<pipeline>/scaffold.ps1" -Target "<cwd>" -NoLaunch を実行し、次にヒアリングに進む。cwdに無関係なファイルがある場合は、停止して質問する(これはクリティカルな質問です)。
PROJECT.md のすべてのフェーズにチェックが入っている(同じ名前で再開された完成済みサイト)かつ、引数が空または新規サイトのヒアリングであり、フェーズ引数や変更リクエストではない何かを実行または変更する前に、最初に質問する(ユーザー、2026-10-10、L-057)。1つのAskUserQuestionを使用: 「<名前>はすでに完成しています(プレビュー )。再デザインしますか?」。選択肢は「いいえ、そのままにします」と「はい、再デザインします」。「いいえ」: 停止して何もしない。ツールの同期、QA、デプロイも行わない。「はい」: 新しいサイトとまったく同じように開始する。古い概要から自分で再デザインしてはいけません(L-058)。(1) 未コミットの変更をコミットし、古いバージョンにタグを付ける: git tag previous-<date>。次に、client-assets/ と .git/ 以外のすべてを <workspace>/_temp/<Name>-previous-<date>/ に移動する(アーカイブであり、削除ではない)。これには古い BRIEF.md も含まれます。タグにより、_temp がクリーンアップされた後でも古いサイトを復元可能にします。(2) 再度スキャフォールディングし、テンプレートの空の BRIEF.md をコピーして、その Business name: 行を設定します。(3) 概要フォームを開く: python "<pipeline>/brief-form/brief_form.py" "<project>" をバックグラウンドコマンドとして実行し、ウィンドウが開いたことをユーザーに伝えて待機します。その間、方向性決定、ライブラリ学習、ストック検索、デザイン作業は一切行いません。(4) 終了コード0(「構築を開始」): 新しい概要に対して、ヒアリングから通常の新規サイトプロセスを実行します。終了コード3(閉じられた): 停止し、概要が保存されたことを伝えます。引き継ぎ時に、2つ目のエントリを追加する代わりに、サイトのデザインライブラリエントリを置き換えます。
PROJECT.md に未チェックのフェーズがある最初の未チェックフェーズから再開する。どこから再開するかを1行で伝える。
既存のプロジェクトを再開または変更するツールの同期は不要: tools/ には共有ツールのスタブが含まれています。サイトに .git/ がない場合、git init -b main、git config core.autocrlf false を実行し、テンプレートの .gitignore をコピーして、最初にベースラインをコミットします。qa.py が共有ツールのフルコピー(2026-10-13より前のサイト)について警告した場合、python "<pipeline>/dev/use_shared_tools.py" "<project>" を実行してコミットします。また、リクエストに必要なテンプレート機能(例: GSAP: build.py の h_gsap、{{fn:gsap}}、tools/vendor/、motion.js)も取り込みます。
引数 statusフェーズチェックリストと未解決のプレースホルダーを表示する。それ以外は何もしない。
引数 learn<pipeline>/design-library/inspiration/ にドロップされたデザイン画像と DESIGN.md ファイルを学習する: design-library/LEARN.md に従い、各参照について1行報告する。それ以外は何もしない。
引数 qa / deploy / handoffそのフェーズのみを実行する。

自由形式の引数はヒアリング資料(ビジネス名、電話番号、リンク、メモ)です。これらは BRIEF.md と同じように扱います。

モード: サンプルまたはクライアント

BRIEF.md の Project type がモードを設定します。デフォルトは sample(ポートフォリオ作品)です。引数内の明示的な指示が優先されます。

サンプル(ポートフォリオ)クライアント(実際のビジネス)
不足している事実概要が薄い場合、もっともらしく一貫性のある架空のビジネスを創作する: 名前、ストーリー、サービス、営業時間。電話番号は555-01xx、メールはexample.comを使用し、実際の人物に届かないようにする。決して創作しない。プレースホルダーと data-todo を使用する。
レビュー、統計、資格情報架空のビジネスであれば問題ない。引き継ぎ時に架空のものとしてリストする。サンプルが実際のビジネスを使用する場合、実際の公開情報のみを使用する: 実際の人物や企業について、架空のレビュー、主張、価格を創作してはならない。クライアントが提供したもののみ。
質問ほとんどなし: ファイルの削除、費用の発生、現実世界との接触(実際の受信トレイ、実際の電話番号)、およびクリティカルなデザイン批評(#5)のみ。以下の完全な質問ポリシーに従う。
フォームデモモードで問題ない。実際のエンドポイントが必要。不足している場合は質問する。
デプロイnoindex プレビューnoindex プレビュー。本番環境はリクエストがあった場合のみ。
引き継ぎの追加項目ポートフォリオのスクリーンショット(引き継ぎを参照)クライアント向けに作成されたプレースホルダーリスト

運用ルール

  • 自動操縦。 「続けますか?」と質問せずに、フェーズからフェーズへと進む。各フェーズの後、PROJECT.md の Status にチェックを入れる。これにより、コンパクション後や新しいセッション後でも実行を再開可能になる。
  • Git(すべてのサイトとパイプラインはリポジトリです)。 チェックされた各フェーズの後(<Phase>: <what was done>)と、要求された変更の各ラウンドの後に、サイトでコミットする。これにより、任意の状態を比較または復元できる。パイプラインの変更(共有ツール、テンプレート、SKILL.md、LESSONS.md、デザインライブラリ)は、パイプラインリポジトリでコミットし、メッセージにレッスンIDを含める(ある場合)。dist/、qa/、およびキャッシュはgitignoreされる。履歴を書き換えたり、強制プッシュしたり、プッシュしたりしてはならない。リモートは存在しない。
  • 質問は以下のポリシーに従う。それ以外はすべて決定事項: 決定し、PROJECT.md の Decisions に1行(何を、なぜ)追加し、続行する。
  • クライアントモード: クライアントの事実を決して捏造しない。 これには、お客様の声、レビュー数、事業年数、ライセンス、認定資格、価格、保証、賞、チーム名が含まれる。入力に資料がない場合は、その事実を必要としないコピーを作成する。どうしても必要な場合は、要素に data-todo="what's needed" をマークして、QAが引き継ぎ用にリストアップできるようにする。サンプルモードはモードテーブルに従う。
  • ミスは発生した瞬間に PROJECT.md の Mistakes に記録する。 引き継ぎまで待ってはいけない。その前にコンテキストがコンパクションされる可能性がある。ミスとは、ユーザーが修正したもの、QA、批評、またはレビュアーが指摘した初稿のエラー(タイプごとに1エントリ、インスタンスごとではない)、および誤った仮定やツールの誤用である。各エントリは、何が起こったか、誰が発見したか、根本原因、修正方法、および防止方法を記録する。
  • 信頼できる情報源: _src/(ページ、パーシャル、site_config.py)と assets/ を編集し、次に python _src/build.py を実行する。dist/ を決して編集してはいけない。
  • スクリプトによる編集(L-027): 単一の変更には Edit を使用する。複数の置換を一度に行う場合は、Write で作成されたPythonスクリプト(<workspace>/_temp 内)を使用し、シェルのヒアドキュメントは使用しない。スクリプトは、各マッチカウントが正確に1である場合を除き終了し、すべてのファイルを書き込む前に各ファイルをチェックする。その後、編集された .py ファイルに対して py_compile を実行し、再ビルドする。
  • コンテキスト衛生: ツールを実行し、そのレポート(qa/*.md)を読み、生の出力は読まない。長いレポート、ログ、リストは、コンテキストモード(ctx_execute_file / ctx_batch_execute と「エラーと警告のみ」などの質問)を使用してクエリし、全体を読まない。スクリーンショットは Read ツールで確認する。HTMLファイル全体を会話にダンプしてはいけない。

質問ポリシー(クリティカルな事項のみ)

以下のいずれかに該当する場合にのみ質問する。これはクライアントモードです。サンプルモードでは#2と#5のみが適用され、noindexプレビューは質問を必要としません。

  1. 正体が不明。 入力や公開情報から、ビジネスの内容、場所、対象顧客がわからない。間違った推測はサイトの書き換えを意味する。
  2. 外部向けまたは不可逆的。 本番環境へのデプロイ、カスタムドメイン、フォームの実際の受信トレイへの接続、費用が発生するもの、ユーザーファイルの削除。BRIEF.md に Deploy preview: yes と記載されている場合、noindexプレビューデプロイは事前承認済みです。
  3. サイトが行う法的または事実上の主張で、クライアントのみが確認できるもの(ライセンス、価格設定、保証)。デフォルトではそれらを省略する。概要がそれらを中心に据えている場合にのみ質問する。
  4. 競合する指示が、概要、ユーザーのメッセージ、RULES.md、CLAUDE.mdの間にあり、両方の解釈がもっともらしい場合。
  5. クリティカルなデザイン批評。 impeccableな批評または仕上げレビュアーが、P0(ブロッキング)またはP1(メジャー)の問題を報告した場合。以下の批評ゲートに従う。これが構築中に許可される唯一の質問です。

質問の方法:

  • 1回のバッチで、ヒアリングの最後に。 1つのAskUserQuestionに1~4個の質問を含める。推奨する回答を最初に、マーク「(推奨)」を付けて配置する。構築中に質問してはならない。批評ゲート(#5)を除く。後でブロッカーが見つかった場合は、明確にマークされたプレースホルダーを使用し、Deferred questions の下に記録し、引き継ぎ時に表面化させる。
  • 以下について質問してはならない: パレット、フォント、レイアウト、コピーのトーン、ページリスト、使用するストックフォト、セクションの順序、技術スタック、ファイル名、またはQA結果を修正するかどうか。これらは決定する。唯一の例外は、P0/P1の批評結果(#5)です。
  • クリティカルなものがなければ、質問しない。 「ブロッキングする質問はありません。続行します」と言い、続ける。

批評ゲート(impeccableな結果)

impeccable自身の重大度スケール(P0 ブロッキング、P1 メジャー、P2 マイナー、P3 ポリッシュ)を使用する。各結果レビューアーアイテムを同じスケールで評価する。

  • P2/P3(マイナー): 修正せず、続行する。 各結果を PROJECT.md の Decisions に1行記録: "skipped: minor (P2/P3), "。
  • P0/P1(クリティカル): 何かを変更する前に停止して質問する。 1つのAskUserQuestionバッチに最大4つの質問を含める。結果ごとに1つの質問を作成するか、4つを超える場合はクラスごとにグループ化する。各質問は、何が間違っているか、どこで(ページ、セクション、スクリーンショットファイル)を説明する。2~3の具体的な修正オプションを提供し、推奨するものを最初にマーク「(推奨)」と共に配置し、さらに「現状のまま」を追加する。次に、ユーザーの選択をクラス全体にサイト全体に適用し(L-016)、再ビルドし、選択をDecisionsに記録する。
  • 再チェック: 選択を適用した後、同じ批評を1回再実行する。新しいP0/P1は再度ゲートを通過する。マイナーな結果は上記のようにスキップされる。
  • ゲートの対象外: qa.py、browser_qa.mjs、LESSONS.md、またはRULES.mdですでに禁止されている客観的なルール違反。例: 4.5:1未満のコントラスト、オーバーフロー、写真の繰り返し使用、その上のテキストのコントラストを低下させるグロー(グロー自体は許可される)、被写体のトリミング、デフォルト値がプリセットされたセレクトボックス。これらは、デザインの選択ではなく欠陥であるため、批評がどのような重大度を与えようと自動的に修正する。impeccable detect フラグは、これらのルールのいずれかに該当しない限り、マイナーとしてカウントされる。既知の誤検出(L-000)については、以前と同様に注記する。

フェーズ

1 · ヒアリング

  1. <pipeline>/LESSONS-INDEX.md を読む(LESSONS.mdから生成された、レッスンごとに1行)。すべてのレッスンは最初の草案から適用される。このプロジェクトに関連する各レッスンのLESSONS.mdの完全なエントリを開き、それらのIDを、それぞれ簡単な説明とともに、PROJECT.md の Mistakes の「Watch for」にリストする。IDのみをリストし、レッスンテキストをコピーしてはならない: コピーは、レッスンが更新されたときに古くなる(Trevor TravisとGadget Zoneは、グローが許可された後も「グローなし」を保持していた)。
  2. BRIEF.md、引数、および client-assets/ 内のすべてを読む。すべての写真を Readで開き、PROJECT.md の Assets にカタログ化する。被写体、品質、問題(皿、ロゴ、乱雑さ、トリミング)、および最適なスロット(ヒーロー/フィーチャー/ギャラリー/スキップ)を記録する。画像上のサードパーティのブランドロゴ(ボード、看板、レンダリング)は支持表明として解釈される: 「使用前にトリミング」または「スキップ」とマークする(L-028)。同じ撮影からのもの、または同じビューを示す写真をメモする(L-029)。
  3. リンクが提供された場合(既存のサイト、Googleビジネスプロフィール、Facebook)、それらを取得し、事実を抽出する: サービス、サービスエリア、営業時間、ストーリー、オーナー、事業年数、実際のプロジェクト。各事実の横にソースを PROJECT.md の Facts に引用する。
    • キャプション、レビュー、オーナーの引用を逐語的にソースファイル(例: client-assets/sources.md)に保存する。そこから引用をコピーする。記憶から再入力したり、言い換えたりしてはいけない(L-007)。
    • 各プロジェクトのクレジットライン(設計者 / 建設者 / 年)をFactsに記録する。ビジネスが建設のみ行ったプロジェクトは、決してその「設計者」であってはならない。
  4. クライアントの写真を最適化する: python tools/optimize_images.py(client-assets → assets/img/client/、EXIF回転、最大2000px)。
  5. _src/site_config.py を入力する: BIZ、HOURS、SERVICES、PRIMARY_CTA、PAGES、FORM_ENDPOINT、SEO。不明な連絡先情報は "" のままにする。ビルドはそれらを表示可能な {{TOKEN}} プレースホルダーとして残し、QAが報告する。
    • お問い合わせフォーム。 概要から Form endpoint: を FORM_ENDPOINT にコピーする: 空白 = デモモード; netlify = Netlify Forms(Deploy host: netlify の場合のみ; それ以外はqa.pyがエラーにする); web3forms:<access key> = 任意のホスト上のWeb3Forms(受信トレイ所有者がweb3forms.comでキーを作成する); またはFormspree形式のURL。{{fn:form_fields}} は、対応する非表示フィールドとスパムトラップを追加する。自分で実際の受信トレイを選んだり配線したりしてはいけない: 空白の概要はデモモードのままで、引き継ぎリストに載る。クライアントモードでは、どの受信トレイがメッセージを受信するかは質問事項です。Online booking link: を BOOKING_URL にコピーする; {{fn:booking}} は、お問い合わせページの電話ボタンの横にそれを表示する。
    • GSAPモーション。 オプション、デフォルトではオフ。概要に GSAP motio と記載されている場合のみ。

関連スキル