Add Claude Assistant workflow

[fumikito]

Summary

• Issue/PRコメントで @claude とメンションすると、Claudeが文脈を読み取って応答するワークフローを追加
• tarosky/workflows/.github/workflows/claude-assistant.yml 共有ワークフローを呼び出し
• OWNER / MEMBER / COLLABORATOR のみトリガー可能（外部ユーザーのコメントは無視）

Test plan

• PRをマージ後、任意のIssueで @claude とコメントして応答を確認
• 外部ユーザー（COLLABORATOR以外）のコメントでは実行されないことを確認

🤖 Generated with Claude Code

[claude]

AI トリアージ: PR #81

リスク: 🟡 中（secrets継承＋@main未固定）
スコープ: `scope:config` `scope:security`
不足: `needs-manual-test`

サマリー

• GitHub Issueおよびレビューコメントで `@claude` メンションにより応答するワークフローを追加。
• `secrets: inherit` で全シークレットを共有ワークフローに渡しており、渡す対象を絞れていない。
• 共有ワークフローが `@main` 参照で固定されておらず、上流変更が即時反映される。

詳細レビュー

テスト要否

• ⚪ テスト不要: .github/workflows/claude-assistant.yml — CI/設定ファイルのみ、PHPコードの変更なし

レビュワーが確認すべき箇所

1. .github/workflows/claude-assistant.yml:11 — uses: tarosky/workflows/...@main
@main ブランチを直接参照しており、共有ワークフロー側の変更が即座にこのリポジトリに影響する。セキュリティ的には特定のコミットSHA（例: @abc1234）に固定することが推奨される。

2. .github/workflows/claude-assistant.yml:12 — secrets: inherit
   リポジトリの全シークレットが共有ワークフローに引き渡される。Claude API キーだけでなく、他の機密情報（デプロイキー等）も含まれる可能性がある。本当に必要なシークレットのみを明示的に渡す形（with: ブロックを使う）が望ましい。

3. アクセス制御の透明性
   PR説明には「OWNER / MEMBER / COLLABORATOR のみトリガー可能」とあるが、その制御ロジックはすべて tarosky/workflows 側に委譲されており、このリポジトリ内のファイルから確認できない。共有ワークフローのレビューも別途必要。

4. issue_comment イベント
   フォークからのPRコメントでもトリガーされる可能性がある。共有ワークフロー側で github.event.comment.author_association によるフィルタリングが実装されているか確認が必要。

設計上の懸念

• プラグイン本体とは無関係な変更: このPRはWordPressプラグインのコードを変更しない純粋なCI/運用ツールの追加。rich-taxonomyリポジトリに必要かどうかも含め、方針の確認が望ましい。
• 上流ワークフローへの依存: tarosky/workflows が非公開リポジトリであれば問題は限定的だが、公開リポジトリ上でのコード実行権限は最小権限の原則に基づいて設計すべき。

---

🤖 AI triage — レビュー内容は人間のメンテナーが必ず確認してください。