実装完了後のセルフチェック時、PRレビュー前の品質確認時に使用。RuboCop/ESLintでは検出できない設計レベルの問題と、domain model attribute (plan_code / role / status 等) を更新する変更時の caller 業務副作用 (機能フラグ復活 / 認可 bypass 等の 2 段階副作用 chain)…
プロジェクト活動 (commits/PRs/README/ADR) を `~/.claude/skills-config/vision.md` のビジョン要素と照合し、対話型 draft → revise loop で Zenn 記事下書きを生成する。プロジェクト単位の物語化・キャリアブランディング・月次記事執筆時に使用。
Use when an AI-generated document (plan / design doc / RFC / PR description) has grown long with the same concept explained in multiple places and needs consolidation to a single…
Use after generating PR description, Jira ticket, design doc, RFC, or other reader-facing text from a local plan/spec file, to detect and rewrite vocabulary that exists only in…
コミット前やPR作成前に、プロジェクト規約への準拠・パターン一貫性・実装/spec 整合性 (Ruby の delegate / def 撤去後に残る dead mock の検出と削除を含む) を確認・修正したい時に使用。
実装完了後にChromeDevTools MCPでUI検証を行う。ACがあればAC項目ごとに画面操作・スクリーンショット・pass/fail判定。FAILなら自動修正→再QAを最大3回ループ。
プランモード中にプランファイルの受け入れ条件・技術リスクを定義する時に使用。詳細は分析ファイル（`<plan>.analysis.md`）に書き出し、プランファイル末尾には品質検証サマリーのみ追記する。/mece-plan-reviewの前に実行し、MECEの検証ターゲットを定義する。
JiraキーとStory Pointsのマップデータを受け取り、Jiraチケットに一括でStory Pointsを設定する。「ストーリーポイント設定」「SP設定」「story points」などのキーワードでトリガーされる。
プランファイルの受け入れ条件（AC）に対しMECE完全性検証を実施し、ユースケース漏れ・技術的対応漏れ・ACの改善点を検出して分析ファイルに記録する。プランにACが定義済みで実装前にMECE検証が必要な時に使用。事前に /define-acceptance-criteria でACを定義しておくこと。
設計書・プロジェクト仕様・Jira epic等からユーザーストーリーマップを作成し、タスク分解・スプリント計画まで行う場合に使用。新しいプロジェクトフェーズの計画、設計書の分析、大きな機能の実装単位への分解が必要な場合にトリガーされる。
ユーザーストーリーマップやタスク分解プランからJiraチケットを一括作成する場合に使用。ストーリーマップ完成後のチケット化、プランファイルからの一括作成、計画済みストーリー・タスクのJiraへの移行が必要な場合にトリガーされる。