Skill.md検索

「記事を書きたい」という要望から、ピラミッド原則とSCQAフレームワークに基づき、読者を引き込める技術記事を6フェーズで段階的に完成させられます。 ユーザーと対話しながら進むため、途中で方針修正できし、自分の思いと違う記事になる失敗を防げます。 目的・読者層・構成・執筆・推敲・公開設定が体系的に進むため、品質が安定し、執筆時間を大幅に削減できます。 導入部を SCQA（Situation → Complication → Question → Answer）で設計するため、読者が最初から引き込まれる記事になります。 テック企業のブロガー・エンジニア：定期的に技術記事を公開したい、でも何から始めればいいか分からない 初めてブログを始める技術者：「良い記事」の構成やロジックを学びながら書きたい 社内ナレッジ共有チーム：複数の技術情報を体系的な記事に整理したい Zenn/Qiita 投稿者：アクセス・スター数を伸ばしたい 6フェーズワークフロー：(1) 目的と読者の確認（記事ゴール・想定読者・前提知識・読了後の期待状態を質問で明確化）、(2) SCQA導入部の設計（Situation/Complication/Question/Answer 各要素を定義）、(3) ピラミッド構造でセクション構成（結論を支える3〜5個のキーポイント → 各セクションの詳細トピック を洗い出し）、(4) 各セクションの執筆（セクション単位で執筆 → ユーザーレビュー → 修正を繰り返す）、(5) 全セクション推敲と微調整（全体の流れ・用語の一貫性を確認）、(6) 公開設定（メタディスクリプション、タグ、公開日の確認）。ピラミッド原則は結論を先に述べ、その後に根拠・詳細を階層構造で展開します。

ライブラリ選定、アーキテクチャパターン決定、技術スタック変更などの議論を ADR（Architecture Decision Record）として記録し、将来同じ議論を繰り返さずに済みます。 決定の背景、選択理由、代替案、メリット・デメリット、結果・影響を体系的に記録できます。これにより、なぜその技術を選んだのか、その判断は今も有効なのかが明確になります。 既存 ADR との整合性を保ちながら、新しい技術決定を docs/architecture-decision-record/ に自動作成できます。 技術決定の置き換えが発生した場合、既存 ADR のステータスを「Deprecated」に変更し、ADR 一覧を自動更新できます。 チーム全体で技術的意思決定の背景を共有でき、オンボーディング時や設計レビュー時の参考資料として活用できます。 ソフトウェアアーキテクト・技術リード：チーム全体の技術判断を可視化・共有したい スタートアップ・新規プロジェクト立ち上げ時のエンジニア：技術スタック選定の理由を記録したい 設計レビューを行う開発チーム：過去の判断理由を参照しながら新しい判断を下したい 開発ドキュメント整備の責務を持つ人：技術的意思決定の履歴を一元管理したい ADR 記録のタイミング：新ライブラリ・フレームワーク選定、アーキテクチャパターン決定、DB・認証方式選択、既存技術決定の変更、トレードオフ伴う設計判断。議論が一段落したら「この決定をADRとして記録しますか？将来同じ議論を繰り返さずに済みます」と確認。ユーザー同意時のみ以下を実施：(1)タイトル、選定理由、代替案、背景、メリット・デメリットをヒアリング、(2)docs/architecture-decision-record/ に XXX-.md を作成、テンプレートに「ステータス」「コンテキスト」「決定内容」「結果・影響（メリット・デメリット）」「代替案と却下理由」「決定日」を記載、(3)README.md の ADR 一覧に追加、既存 ADR 置き換え時は「Deprecated」に変更、overview.md を必要に応じて更新。すべて日本語で記述し、既存 ADR との整合性を保証。

ユースケース一覧とタスク表から、UIに必要な「概念オブジェクト」を自動抽出し、それらの関連性を整理できます。 オブジェクト間の関係性や多重度（1対1、1対多など）を定義し、Mermaid図で可視化するため、複雑なコンテンツ構造が一目で理解できます。 UIデザインの前段階で、中身の構造を明確にすることで、後続の画面設計やデータベース設計がスムーズに進むようになります。 UI/UXデザインの初期段階で、コンテンツ構造を整理したい設計者やデザイナー ユースケースから実装すべき概念オブジェクトを洗い出したい開発者 モデルベースUIデザイン（MBUD）のフェーズ3を実施する人 複雑なシステムの構造を図で可視化し、ステークホルダーと合意したい人 このスキルは、フェーズ1（ユースケース定義）とフェーズ2（タスク整理）が完了した後に実行されます。処理フローは以下の通りです。① 出力ファイルのパスをユーザーに確認し、存在しなければ ${CLAUDE_SKILL_DIR}/../mbud/references/output-template.md を基に新規作成。② 以下3つのファイルをgeneral-purposeエージェント（サブエージェント）に読ませて実行：general-rules.md、phase3-content-structure.md、出力ファイル。③ サブエージェントの結果をユーザーに提示し、フィードバックを得る。④ 修正が必要な場合はサブエージェントを再起動。途中から再開する場合は ${CLAUDE_SKILL_DIR}/../mbud/references/context-clear-recovery.md を参照します。

コード調査・レビュー・CI分析の中で見つかった問題を「Issue化しますか？」と提案し、ワンステップで GitHub Issue として記録できます。 対象領域・問題内容・修正方法・優先度・種別を段階的にヒアリングし、ISSUE_TEMPLATEに準拠した整形済みIssueを自動作成します。 既存Issueとの重複防止チェック、ラベル自動付与（種別+優先度）により、Issue管理の質を統一できます。 /issue コマンドでIssue一覧を即座に確認でき、未処理の問題を視覚的に把握できます。 コードレビューやリファクタリング（コードの整理・改善）で頻繁に問題を発見する開発者 CI分析やテスト不足の問題を組織的に管理したい テックリード・QAエンジニア 技術的負債（後々のコスト増加につながる設計の問題）を可視化して優先順位付けしたいプロジェクト管理者 GitHubをタスク管理のハブとして、会話の中で見つかった問題を即座に記録したいチーム全体 GitHub Issueを使って問題を管理します。自動提案場面はコードレビュー・CI分析・リファクタリング・テスト不足・依存関係問題・技術的負債発見時に「Issue記録しますか？」と確認。/issueコマンドで明示的な作成または一覧確認を実行。Issue作成時は5項目をヒアリング（対象領域・問題内容・修正内容・優先度・種別・検証方法）し、.github/ISSUE_TEMPLATE/default.mdテンプレートに準拠したタイトル「{対象領域}—{概要}」と本文（パッケージ/対象、問題、修正内容、対象ファイル、検証方法）をgh issue createで実行。ラベルは種別（bugfix/refactor/improve/docs/infra/feature/chore）+優先度（priority:high/medium/low）の2つを付与。一覧確認はgh issue list --state openで実行。全て日本語で記述し、既存Issue重複確認とリポジトリルート相対パス記載を厳格に。

6段階で記事を完成させる — 目的確認からSCQA設計、アウトライン作成、セクション執筆、推敲、公開設定までを対話しながら進められます。 読者に響く導入部を設計できる — ピラミッド原則とSCQAフレームワーク（状況→問題→疑問→答え）に基づき、読者を自然に本題へ導く構成を作成できます。 階層的で分かりやすい記事構成 — 結論を先に述べ、その後に根拠や詳細を展開する「ピラミッド原則」で、読みやすく論理的な記事を執筆できます。 セクション単位のレビュー&改善 — 完成した各セクションをユーザーがレビューし、フィードバックに基づいて修正するサイクルを繰り返せます。 想定読者に合わせた執筆 — 初心者・中級者など想定読者のレベルに合わせた表現・前提知識・例示で、誰に何を伝えたいのかが明確な記事になります。 技術ブログやZenn記事を書きたい人 — 構造化されたステップで初心者でも完成度の高い技術記事を執筆できます。 執筆の方向性に迷っている人 — 対話的に目的・読者・構成を整理するため、「何を書くか」が明確になります。 記事の導入部を上手く書きたい人 — SCQAフレームワークで読者を惹き込む導入を設計できます。 チームで記事品質を高めたい人 — 段階的なレビュー&修正で、品質のブレを減らしたベストプラクティスに沿った記事が作成できます。 技術記事の執筆を6つのフェーズで構造化します。Phase 1: 目的と読者の確認では記事のゴール・想定読者・前提知識・読了後の状態を明確化。Phase 2: SCQA導入部の設計では状況（Situation）→問題（Complication）→疑問（Question）→答え（Answer）の4要素で導入部を構成。Phase 3: ピラミッド構造でセクション構成では結論を支えるキーポイント3〜5個を洗い出し、各セクションと詳細トピックを列挙。Phase 4: 各セクション執筆ではセクション単位で執筆→ユーザーレビュー→修正のループを反復。Phase 5・6で推敲と公開設定を行います。ピラミッド原則（結論→根拠→詳細）とSCQAフレームワークを設計基盤とし、各フェーズで成果物を記録形式として markdown で記録し、完了条件を明確に設定します。

複雑な要件を幅優先で段階的に具体化し、テストが書ける粒度の小さなタスクに分割できます。 コードベース調査に基づいて技術的な制約や影響範囲を判断し、現実的な実装計画を立てられます。 タスク間の依存関係を整理し、最適な実装順序をツリー構造のチェックリストで可視化できます。 進捗状況をファイルに自動記録するため、途中で作業を中断しても、後で履歴を追える構造になります。 テスト駆動開発（TDD）で即座に着手できるレベルまでタスクを具体化するため、設計から実装への移行がスムーズです。 新機能追加や大きな修正を前に「どこから手をつけたらいいか分からない」と困っているエンジニア 要件から実装計画を立てるPMやテックリード チーム全体で実装進捗を共有・管理したいプロジェクトマネージャー リファクタリング（コードの整理・改善）の範囲や順序を明確にしたい人

現在のプルリクエストのCI（継続的インテグレーション）が失敗している場合、自動でログを分析します。 ビルドエラーやテスト失敗など、複数のエラーがある場合は優先度順に整理し、修正方針を提案します。 ローカルで再現するための確認事項も示唆するため、CIに何度もプッシュして試行錯誤する手間が削減できます。 エラーと修正方針を分かりやすく報告するため、非エンジニアでもエラーの内容を理解できます。 プルリクエストを出したが、CIが失敗して原因が分からないエンジニア エラーログの解読に時間をかけたくない忙しい開発者 CI/CDパイプラインの安定性を把握・改善したいチームリード

ステージング済みおよび作業ツリーの変更内容を分析し、単一の関心事ごとに分割したコミット案を提案します。 各コミットに対して、プロジェクトの規則に沿った分かりやすいメッセージを自動生成します。 ブランチ分割が必要な場合、ブランチ命名規則に従った提案を行うため、チーム全体で一貫性のあるGitワークフローが実現できます。 コミット分割が適切かユーザーに確認を取ってから実行するため、不適切な分割を防げます。 複数の変更が混在した状態をきれいにコミット分割したいエンジニア Gitの履歴を読みやすく保ちたいプロジェクトマネージャーやコードレビュアー mainブランチへの直接コミットを防ぎたいチーム

要件定義から実装、レビューまで、開発の全フェーズを構造化されたワークフローで進行します。 各フェーズの完了条件を明確にするため、どの段階で次に進むべきかが曖昧にならず、開発がブレません。 ファイルベースで各フェーズの成果物を記録するため、途中でコンテキストが切れても後で履歴をたどれます。 複雑な開発タスク（新機能追加、機能修正、リファクタリング）を、一連の流れで管理できるため、チーム全体での進捗把握が容易になります。 大型の新機能追加を計画・実行するプロダクトエンジニアやテックリード 要件から最終レビューまでの開発プロセスを標準化したいプロジェクトマネージャー チーム全体で開発進捗を透明かつ構造化して管理したい組織 開発中の意思決定（設計判断）を記録・共有したいテクニカルリーダー

要件やビジネスロジックからエンティティ（テーブルの概念）を抽出し、段階的にテーブル設計に落とし込みます。 正規化（データの重複を排除）、データ型・表現方法の選択、テーブル間の関係設計など、複数の段階に分けて設計するため、検討漏れを防げます。 既存のコードベース（スキーマ定義など）やADR（アーキテクチャ決定記録）を参考にしながら設計するため、チーム全体で一貫性のあるDB設計が実現できます。 各段階でユーザーに確認を取り、最終的にMermaid形式のERD図（テーブル構造図）を生成するため、チーム全体で設計内容を共有できます。 新しいデータモデル（テーブル構造）を一から設計する必要がある開発チーム 要件から効率的にDB設計に落とし込みたいバックエンド開発者やDB設計者 複雑なテーブル間の関係を整理・可視化したいデータベース管理者やアーキテクト チーム全体でDB設計の意思決定を共有・記録したいテックリード

ユースケース定義からナビゲーション設計まで、6つのフェーズに分けてUI構造を段階的に構築できます 見た目のモックから始めるのではなく、ユーザーのニーズ・タスク・概念モデルという設計の基盤から積み上げることで、堅牢で拡張性の高いUI設計ができます 各フェーズの進捗と設計判断を自動的に記録されるため、途中で中断した場合も簡単に再開できます AIが各フェーズの作業を管理・サポートするので、複雑なUI設計プロセス全体を一貫性を保ちながら進められます 設計の前提が変わった場合も、該当フェーズから効率的にやり直せます 新規プロダクトや大規模なUI刷新を計画しているPM・プロダクトマネージャー ユーザー理解をベースにした堅実なUI設計を進めたいデザイナー コードベースから既存設計資産を活かしながら、新しいUI要件を構造化したい開発チーム UI設計の進捗を可視化・共有し、ステークホルダーと段階的にレビューしたい組織

ユースケース・タスク・コンテンツ構造の上流設計から、デザインの「芯」となるコンセプトを導き出せます ユーザーのメンタルモデル（ユーザーが頭の中に持つUIの理解の仕方）を整理し、文書化できます UIの骨組み（ヘッダー・メイン・サイドバーなどのフレーム構造）を設計し、全体のレイアウト方針を決められます 単独でこのフェーズに取り組めるため、既存の設計プロセスの一部として活用することも可能です ユースケースやタスク分析が済んでおり、UI骨組みの設計を次のステップにしたいデザイナー モードレスで直感的なUI構造を定義したい・デザイナー 既存のUI設計フェーズ4のみを改善・やり直したい組織

コンテンツ構造・フレーム構造・ユースケースの情報から、ユーザーが目的に到達するための画面遷移経路を設計できます 「どこからでも検索可能」「ホームに戻りやすい」などのナビゲーション原則に基づいた構造化ができます ボトムアップ（ユーザーのニーズから必要な経路を抽出）とトップダウン（システムの情報構造から経路を計画）の両方向から設計し、漏れのない遷移設計ができます Mermaid形式の図として自動生成されるため、チームで共有・議論しやすくなります UI設計の前工程（コンテンツ構造・フレーム構造）が完了し、画面遷移設計に進みたいデザイナー 複雑なユースケースを持つアプリケーションのナビゲーション構造を体系的に設計したい組織 設計フェーズ5のみを単独で実行・やり直したい場合

ユースケース・タスク・コンテンツ構造・コンセプト・フレーム・ナビゲーション設計の全成果物を一度に検証できます 各フェーズ間の整合性（例：コンセプトとナビゲーション設計がズレていないか）を自動的に確認できます 指摘事項を「Critical（対応必須）」「Improvement（改善推奨）」「Note（参考）」の3段階に分類し、優先順位をつけたレビューレポートが得られます モードレス原則・プラットフォーム適合性・拡張性といった設計品質の観点からチェックできます UI設計全6フェーズが完了し、品質確保と最終承認を担当する設計リード・マネージャー 各種UI設計ツール・フレームワークの成果物を統合的に検証したいチーム ステークホルダーへの提示前に、設計の漏れや矛盾を洗い出したい組織

ユースケース（ユーザーがシステムを使って達成したいこと）から、具体的なタスク（ユーザーのアクションとシステムの反応の組み合わせ）の一覧表を作成できます タスクをCreate（作成）・Read（参照）・Update（更新）・Delete（削除）の4つに分類するため、UI設計の材料として活用しやすくなります 単独でこのフェーズに取り組めるため、既存の設計プロセスの一部として活用することも可能です タスク表により、要件漏れや重複を早期に発見できます ユースケース定義が済んでおり、タスク分析を次のステップにしたいPM・デザイナー UI要件定義の精度を上げたい・基礎を固めたい組織 既存のUI設計フェーズ2のみを改善・やり直したい場合

ペルソナモデルと行動シナリオから、ユーザーが本当にやりたいことを「ユースケース」として整理できます。 曖昧な要望を具体的な用途に言い換えることで、以降の設計・実装の共通言語を確立できます。 定義したユースケース一覧を文書として残し、チーム内で合意を取ることができます。 途中から作業を再開する際も、これまでの定義内容を参照しながら続行できます。 プロダクトマネージャーやUXデザイナーで、ユーザーの行動パターンを整理して設計に活かしたい人 エンジニアで、実装前に「何のために」という軸を明確にしておきたい人 チームで「このユースケース、本当に必要？」という議論を構造的に進めたい人

実用性・懐疑性・理想性・接続性の4つの思考スタイルを持つレビュアーが同時にコードをチェックします。 単一の視点では見落としやすい問題（過剰設計、セキュリティリスク、保守性の低下、システム全体への影響など）を多角的に抽出できます。 異なる視点からの指摘を「必須対応」「推奨対応」「検討事項」に分類し、優先順位をつけて提示できます。 レビュアー間で矛盾する意見が出た場合も、その対立を明示することで、より深い技術的判断ができます。 コードレビューで「何か引っかかるけど、理由が言語化できない」という経験をしている開発者 チーム全体でコードの品質基準を高めたい技術リーダー 新人エンジニアの成長を加速させたいメンターで、多角的なフィードバックを提供したい人

ユーザーの漠然とした「こういうのってできる？」という質問を、具体的で検証可能な要件に変換できます。 「要望」（実現したい状況）と「要求」（手段の提案）を分離し、より良い代替案がないか検討できます。 暗黙の前提（ユーザーが当たり前だと思っていること）を洗い出し、本当にそれでいいのかを確認できます。 コードベースやWebの調査を通じて、「実装は可能か」「既に似た実装がないか」「制約はないか」を事前に評価できます。 議論の進捗を継続的に記録するため、コンテキストクリアになった後も一貫性を保ったまま議論を再開できます。 プロダクト開発で、顧客の漠然とした要望を形にするプロダクトマネージャー 企画段階で手戻りを減らしたいデザイナーやプランナー 仕様決定前に十分な検討をしておきたい開発リーダー 会議の中で「何を作るか決めたい」と考えているメンバー

タスクやコード実装の完了後に振り返りを実施し、うまくいったことや改善点を整理できます。 学んだパターンやベストプラクティスを、プロジェクトルール・コーディング規約・スキル定義など最適な設定ファイルに自動で反映できます。 同じ問題への対応方法や新しい技術活用のノウハウを、チーム全体で再利用できる知識として蓄積できます。 複数の設定先から最適な場所を提案してくれるため、どのファイルに書くべきか迷わずに済みます。 振り返り内容と反映内容をすべて記録に残し、コンテキスト喪失時も参照できます。 プロジェクトのルールやベストプラクティスを継続的に改善したいエンジニア・プロジェクトマネージャー 完了後の「あのときどうしたっけ？」を防ぎたい開発チーム 新しい技術を導入したときに、そのナレッジを設定に落とし込みたい人 レビュー後の改善点を単発で終わらせず、将来の参考にしたい人

テスト→実装→整理（Red→Green→Refactor）のサイクルで堅実に機能を組み上げることができます。 ToDoリストで進捗を可視化し、どのタスクがどの段階にあるかひと目で確認できます。 各段階で専門家（レビュアー）による品質チェックが入るため、単独開発でも安心です。 セッション途中でコンテキストがクリアされても、進捗記録から即座に再開でき、やり直しが発生しません。 テスト・実装・リファクタリングの細かな判断をAIが担当し、ユーザーは「何をテストするか」という重要な判断に集中できます。 バグを早期に発見し、保守性の高いコードを書きたいエンジニア 複雑な機能を安全に実装し、テストで動作を保証したい開発チーム 実装途中で中断しても、後で続きからすぐに再開したい人 「テストを先に書く」というプラクティスを実践したい人