health-check

Plugin health-check from marketplace claude-development-skills in windschord/claude_skils. Commands read from the repo's manifest — 4 days ago.

Skills (25)

• ai-code-review

  指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。

• pr-comment-fixer

  GitHub PRのレビューコメントを自動検出し、コード修正を適用する。インラインスレッド・レビュー本文・Issueコメントに対応し、CodeRabbit・Copilot等のbotコメントも処理する。PRレビュー後の修正作業を自動化したい場合に使用する。Do NOT use for レビュー自体の実施（ai-code-reviewを使用すること）。

• self-review

  ローカルの変更差分（git diff）を3つのサブエージェントで並列レビューし、結果を統合して修正を適用する。PR作成前やタスク完了前のローカル品質チェックに使用する。ai-code-reviewと同一の6観点・重大度基準を適用する。

• depth-interviewing-career

  キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。

• depth-interviewing-product

  サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。

• key-needs-interview

  キーニーズ法（梅澤理論）に基づいて深掘りヒアリングを行い、会話ログを保存し、強さ×未充足度で分析したいときに使う。新商品・サービスのニーズ発掘や既存ヒアリングログの分析に使う。

• knowledge-base

  ローカルMarkdownファイルによる個人ナレッジベースを管理する。メモ・記録・ノートの保存、検索・参照、会議メモの構造化、既存ファイルの取り込みに使用する。Do NOT use for プロジェクトのソースコードやSDDドキュメントの管理。

• report-summarizing

  調査結果や分析レポートを4層構造（エグゼクティブサマリー→概要→詳細→Appendix）で整理し、意思決定者向けに構造化する。レポート作成、既存ドキュメントの再構成、経営層向け報告書の作成に使用する。Do NOT use for ナレッジベースへの情報保存（knowledge-baseを使用すること）。

• health-check

  インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。

• incident-rca

  インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。

• ipa-nfr-operations-design

  IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。

• operations-design

  運用設計コンサルタントとして、対象業界の調査とヒアリングに基づきITIL 4・SRE・DevOpsベストプラクティスの運用設計書を作成する。新規サービスの運用設計、既存システムの運用改善、運用移管の準備に使用する。Do NOT use for ソフトウェアの機能要求の定義（requirement-managementを使用すること）。

• orchestrating-agents

  Orchestrates multi-step tasks autonomously using a 3-tier agent hierarchy (Director/Manager/Worker). Use when user says "run this end-to-end", "handle everything", "execute all tasks", or needs parallel task execution with queuing, course correction, and session resume. Provides FIFO task queue, esc

• project-phase-risk-audit

  大規模システムリプレース・移行プロジェクトについて、マルチベンダー管理に長けたPMOの視点で「見落とされがちな潜在リスク」を洗い出す。正常系設計や特定ベンダーの担当範囲内には現れにくい「ベンダー間の隙間」「業務影響」「異常系」の死角を、4視点の分析フレームワークで特定し、Backlog起票用のリスク表とキラークエスチョンを生成する。要件定義・運用設計・負荷試験フェーズ特化フレームワークへの切替にも対応。総合テスト終盤・移行リハーサル前・負荷試験計画時のリスク総ざらいに使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rca）、要求の追加・変更・矛盾検証（

• saas-spec-document

  SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。

• requirement-management

  要求・ユーザーストーリー・理由・用語・要求間の関係をYAMLレジストリで管理し、追加・変更・廃止のたびに要求間の整合性と矛盾を機械的に検証する。要求の追加/変更/削除、矛盾チェック、トレーサビリティ確認、ユーザーストーリーと受入条件の管理が必要な場合に使用する。設計は実装時にPR本文・GitHubコメントに書くだけで永続化しない運用を前提とする。requirements-defining / software-designing / sdd-document-management の移行先。Do NOT use for 設計書の作成・永続化（設計はPRに書く）。

• requirements-defining

  【非推奨】requirement-management に統合された。新規の要件定義には requirement-management を使用すること。既存の docs/sdd/requirements/ を保守・参照する場合にのみ使用する。EARS記法によるMarkdownの要件定義書（ユーザーストーリー・受入基準・非機能要件）を作成・編集する。Do NOT use for 新規プロジェクトの要件定義（requirement-management を使用すること）。

• sdd-document-management

  【非推奨】要求の整合性チェックは requirement-management の reqctl.py validate に統合された。既存の docs/sdd/ を保守する場合にのみ使用する。SDDドキュメントの整合性チェック、実装同期確認、アーカイブ（CLAUDE.md同期含む）、ファイル最適化を行う。Do NOT use for 要求の矛盾検出（requirement-management を使用すること）。

• sdd-documentation

  SDDワークフロー全体を統括するオーケストレーター。要求管理・タスク計画・実装・逆順レビューの一連のフローを管理する。複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。要求は requirement-management、設計はPR本文が既定の記録先であり、requirements-defining と software-designing は非推奨。Do NOT use for 個別フェーズのみの作業（requirement-management、task-planningを直接使用すること）。

• sdd-troubleshooting

  エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。

• software-designing

  【非推奨】設計書を永続化しない運用へ移行したため非推奨。設計は実装時にPR本文とGitHubコメントへ記載し、要求の管理は requirement-management を使用すること。既存の docs/sdd/design/ を保守・参照する場合にのみ使用する。アーキテクチャ設計、コンポーネント定義、API設計、データベーススキーマのMarkdown文書を作成・編集する。Do NOT use for 新規プロジェクトの設計（設計はPR本文に記載すること）。

• task-planning

  設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。

• graphify-codebase

  Graphify（コードベースをナレッジグラフ化するCLI）を導入・更新・照会し、SDDの設計・レビュー・実装・トラブルシューティングで影響範囲や依存関係の調査に使う。既存コードの構造把握、変更の波及範囲の特定、2要素間の経路追跡が必要な場合に使用する。Graphifyは任意の補助ツールであり、未導入でも既存の調査手順にフォールバックする。Do NOT use for 要求の整合性検証（requirement-managementのreqctl.pyを使用すること）。

• jules-api

  【非推奨】Jules は 2026-12-31 にサービス終了する（2026-11-11 以降は読み取り専用）。新規のタスク実行には使用せず、task-executing（Agent tool）を使用すること。既存の Jules セッションの参照・完了処理にのみ使用する。Jules REST API（JULES_API_KEY_OP_URI または JULES_API_KEY で認証）でセッション作成・プラン承認・メッセージ送信・進捗監視を行う。Do NOT use for 新規タスクの実行（task-executingを使用すること）。

• things-url

  Things 3とClaude Codeのタスクを双方向で共有する。URLスキームによるタスク送信とAppleScriptによるタスク読み取りに対応する。macOS環境でThings 3とのタスク同期が必要な場合に使用する。Do NOT use for macOS以外の環境でのタスク管理。

Subagents (3)

• manager

  orchestrating-agentsスキルの子（Manager）セッション。フェーズの管理者として、孫への作業分解・委譲、品質評価、代理承認、親への報告を担当する。

• orchestrator

  orchestrating-agentsスキルの親（Director）セッション。ユーザーとの唯一の対話窓口として、指示解釈・子への委譲・達成評価・キュー管理・エスカレーション転送を担当する。

• task-executing

  docs/sdd/tasks/に記載されたタスクを実行し、コード実装を行うエージェント。タスクごとにステータス更新とコミットを作成し、実装完了後は逆順レビューで整合性を確認する。orchestrating-agentsスキルの3階層構成ではWorker（孫）としても動作する。SDDワークフローの実装フェーズで使用する。Do NOT use for 要求の定義・タスク計画の作成（requirement-management、task-planningを使用すること）。設計は本エージェントが実装時に行い、PR本文へ記載する。