wp-project-triage

wp-project-triage skill の概要

wp-project-triage ができること

wp-project-triage skill は、WordPress リポジトリを素早く、かつ決定論的に一次判定するためのインスペクタです。プロジェクトの種類を推定し、使われているツール類やテスト環境を検出し、バージョンの手がかりを拾い上げて、構造化されたレポートを返します。これにより、推測に頼らず適切なワークフローを選べます。Workflow Automation で wp-project-triage が必要な場合、何かを編集する前にエージェントが次に何をすべきか判断する助けになるのが、この種の skill です。

こんな人に向いている

WordPress のコードベースに入り込んだとき、それが plugin なのか、theme なのか、block theme なのか、site なのか、WP core なのか、あるいは Gutenberg 関連の repo なのかを見極めたいなら、wp-project-triage skill を使ってください。実装前、レビュー前、テスト前に、再現性のあるトリアージ手順を置きたい agent や maintainer に特に向いています。

何が違うのか

wp-project-triage の価値は、要約文を作ることではありません。意思決定を支えることにあります。リポジトリのシグナルを読み取り、ガードレールを適用し、一般的なプロンプトよりも信頼しやすい JSON レポートを出力します。そのため、ファイル名をいくつか見せて LLM に「この repo を判断して」と頼むより、ずっと適しています。

wp-project-triage skill の使い方

インストールして repo ルートを指定する

wp-project-triage install を使うときは、標準の skills コマンドで skill を agent workspace に追加し、その後は repository root から実行してください。そうすることで、detector が実際の project layout を確認できます。この skill は、bash と Node が使える filesystem ベースの環境を前提にしています。ワークフローによっては WP-CLI も必要になります。

まず読むべきファイル

最初に skills/wp-project-triage/SKILL.md を読み、次に references/triage.schema.json で report の形を確認してください。repo には scripts/detect_wp_project.mjs も含まれており、分類や signal detection の仕組みを理解したいならこれが重要です。この 3 つを見れば、ディレクトリツリーをざっと眺めるだけよりもはるかに多くのことが分かります。

あいまいな目的を実用的な prompt に変える

良い wp-project-triage usage prompt は、「スキャンしてほしい」だけでなく、何を判断したいのかを明確に伝えます。たとえば、「この repo に wp-project-triage を実行して、plugin か block theme か、どんな tooling が入っているか、コード変更前に従うべき guardrail は何かを教えてください」のように書きます。そうすると、skill は十分な意図を受け取り、実行可能なトリアージ report を返しやすくなります。

レポートを使って次のワークフローを選ぶ

detector が動いたら、その結果をもとに build config、test setup、version constraints、content structure のどれを次に見るべきか判断します。レポートが unknown を返した場合は、正しい root で実行しているか、あるいは repo 側にもっと良い detection rules が必要ではないかを示すサインとして扱ってください。theme.json、block.json、build tooling の追加など、構造が変わったら detector を再実行します。

wp-project-triage skill の FAQ

wp-project-triage は WordPress リポジトリ専用ですか？

はい、想定用途はそこです。wp-project-triage guide は、plugin、theme、block theme、site repo、core、Gutenberg といった WordPress の project shape 向けに設計されています。WordPress エコシステム外で作業しているなら、一般的な filesystem scan や別の repo classifier のほうが適しています。

使うのに WP-CLI は必要ですか？

必ずしも必要ではありません。filesystem だけの環境でも skill 自体は役立ちますが、下流のワークフローによっては WP-CLI や WordPress 周辺の tooling を前提にすることがあります。wp-project-triage の役割は、何が入っているかを明らかにして、その後の手順が現実的かどうか判断しやすくすることです。

リポジトリを AI に直接見せるより優れていますか？

最初の一次判定としては、たいていそうです。通常の prompt では、バージョンの手がかりを見落としたり、シグナルを無視したり、構造があいまいなときに勝手に補完したりしがちです。wp-project-triage なら、インストールして実行する手順が再現可能で、出力契約も明確です。しかも役割はより限定されていて、まず分類し、そのあとで行動する、という流れになっています。

どんなときに使わないほうがいいですか？

code review、security auditing、深い architecture analysis の代わりとしては使わないでください。これは triage layer であり、完全な診断ではありません。すでに project type が分かっていて、狙いを絞った code task をしたいなら、この step は不要かもしれません。

wp-project-triage skill の改善方法

開始条件を整える

wp-project-triage の結果を最も改善しやすいのは、正しい repository root から実行し、partial checkout や nested working directory を避けることです。detector が違う folder を見てしまうと、レポートの有用性はすぐに落ちます。これは凝った prompt よりも重要です。

判断を変えるコンテキストを足す

wp-project-triage usage をより良くしたいなら、求める結果を具体的に伝えてください。たとえば、plugin と theme のどちらかの分類、build-tool の検出、test readiness などです。そうすると、次のステップに十分なレポートかどうかを判断しやすくなります。「全部要約して」ではなく、「最小限で安全な編集経路を教えて」のような follow-up prompt のほうが有効です。

よくある失敗パターンに注意する

主な失敗パターンは、シグナル不足、変則的な repo layout、無視された directory によって unknown あるいは説明不足の分類になることです。もう 1 つは、生成ファイルはあるのに source の手がかりが弱い repo で、最初の report を過信してしまうことです。そうなったら、detector の入力を改善するか、ignore rules を拡張してください。場当たり的に判断を足すのは避けるべきです。

最初の実行後に繰り返す

最初の report で不足点を洗い出し、その後に theme.json、block.json、test config、version metadata などの不足している手がかりを追加してから、wp-project-triage を再実行してください。この skill は、検出、確認、調整、再検出という反復的な guardrail として使うと最も効果を発揮します。