Skill.md検索

新機能開発の際に、要件・設計・タスクをセットで作成し、計画的に実装を進められます。ステアリングファイル（.steering/）に requirements.md、design.md、tasklist.md を自動生成し、プロジェクトの方針に沿った構成をサポートします。 タスク実行中は tasklist.md を常に参照しながら、リアルタイムで進捗を記録・更新できます。チェックボックス形式で各タスクの完了状況を可視化し、実装漏れを防ぎます。 全タスクが完了するまでの進捗追跡を強制化し、「時間の都合で後回し」などの理由でタスクをスキップさせません。大きなタスクは自動的にサブタスクに分割し、完了可能な粒度に調整します。 実装完了後、振り返り内容をドキュメントに記録し、次のプロジェクトへの知見として蓄積できます。 プロジェクトマネージャーやリーダー：複数のタスク進捗を一元管理し、チーム全体の完了状況を把握したい方 開発エンジニア：要件から実装まで迷わずに進めたい、やるべきことを明確にしたい方 品質管理担当者：すべてのタスクが確実に完了したことを確認し、実装漏れを防ぎたい方 スタートアップやアジャイルチーム：短い周期で機能開発を進める際に、計画と進捗の両方を効率的に管理したい方 このスキルは3つの主要な使用タイミングを定義しています。作業計画時は、docs/ フォルダ内の永続ドキュメント（product-requirements.md、functional-design.md、architecture.md、repository-structure.md、development-guidelines.md）を読み込み、プロジェクト方針を理解した上で、.steering/[YYYYMMDD]-[機能名]/ 形式のディレクトリを作成し、テンプレートから requirements.md、design.md、tasklist.md を生成します。実装時が最重要モードで、tasklist.md を常に開いた状態を維持し、タスク開始時に [ ] を [x] に、完了時にもEditツールで記録することを必須とします。複数タスクをまとめて更新することや、tasklist.md を見ずに実装することは禁止です。タスク完全完了の原則として、全タスクが完了するまで作業を継続することを絶対とし、「時間の都合により」「別タスクとして実施予定」などの理由でのスキップを禁止しています。ただし技術的理由（実装方針変更、アーキテクチャ変更など）に該当する場合のみ、理由を明記してスキップが許可されます。大きすぎるタスクは自動的にサブタスクに分割し、tasklist.md に追加して対応します。

アイデアの壁打ちから始まり、初期要求仕様(docs/ideas/initial-requirements.md)をもとに高品質なPRDを段階的に生成できます。 Mermaid図解による視覚的な説明、ユーザーストーリー、優先度分類（P0/P1/P2）など、実装チームが実際に動くために必要な詳細情報をすべて記載した要件定義書を自動生成します。 AIレビュー（プロダクトビジョンの明確性、ターゲットユーザーの具体性、成功指標の測定可能性など5つの観点）を組み込み、品質の低い要件を検出・改善できます。 既存PRDがある場合は、それを優先して参考にしながら更新・拡張できます。 具体性と測定可能性の基準に基づいてレビュー→改善→再レビューのサイクルを自動化します。 プロダクトマネージャーや企画担当者で、漠然としたアイデアを実装可能な要件定義書に変える必要がある方 スタートアップや新規プロジェクトの立ち上げで、短期間に質の高い要件定義を作る必要がある方 エンジニアチームへの要件説明書を体系的に作りたい方 「プロダクトビジョン」「ユーザー中心設計」「測定可能な成功指標」を意識した要件定義を学びたい方 このスキルは、高品質なプロダクト要求定義書(PRD)作成のための詳細ガイドとテンプレートを提供します。前提条件として、ユーザーがClaude Codeとの対話を通じてアイデアのブラッシュアップを完了し、その内容をdocs/ideas/initial-requirements.mdに保存していることが必要です。PRD作成プロセスは以下で構成されます：(1)initial-requirements.mdの確認、(2)テンプレートに従ったPRDドラフト生成、(3)5つの観点（ビジョンの明確性、ユーザーの具体性、成功指標の測定可能性、機能要件の詳細度、非機能要件の網羅性）でのレビュー、(4)改善→再レビューサイクル。作成したPRDはdocs/product-requirements.mdに保存します。重要なポイントとして、すべての要件は具体的で測定可能であり、ユーザーストーリー形式「[ユーザー]として、[目的]のために、[機能]が欲しい」に従い、P0(MVP必須)・P1(初期リリース後)・P2(将来検討)の優先度を設定します。既存PRDがある場合はそれを最優先し、このガイドは補足資料として参考にしてください。

PRD（製品要件書）と機能設計書の要件を技術的に実現するシステム構造を自動生成できます。 テクノロジースタック（使用する技術・ツール・言語）の選定と理由付けができます。 既存のアーキテクチャ設計書がある場合、その構造を維持しながら更新・改善できます。 アーキテクチャ設計書のテンプレートとガイドに従い、品質の高い設計ドキュメントを作成できます。 システムの技術構成を決める必要があるプロジェクトマネージャーやリーダー 新しいプロジェクトで最初のアーキテクチャ設計書を作成する必要がある技術責任者 既存プロジェクトのアーキテクチャを整理し直す必要がある開発チーム 複雑なシステムを設計するときに、標準的な手順やベストプラクティスを参考にしたい人 このスキルは以下の流れでアーキテクチャ設計書を作成します。前提条件として、docs/product-requirements.md（PRD）とdocs/functional-design.md（機能設計書）を確認してから開始します。アーキテクチャ設計は、PRDの要件と機能設計を技術的に実現するためのシステム構造とテクノロジースタックを定義します。優先順位として、既存のdocs/architecture.mdがある場合はそれを最優先し、このスキルのガイドはあくまで補足資料として使用します。新規作成時はテンプレートとガイド（./guide.md、./template.md）を参照してください。出力先はdocs/architecture.mdに統一します。

Discord、Slack、Notion等の外部連携や新規システムブロックをワークフローエンジンに追加できます。 Migration形式でブロック定義をデータベースに登録し、UIアイコン・カラー・設定スキーマを同時に設定できます。 JavaScriptコード（ctx.http、ctx.secrets等を使用）で簡単に実装でき、複雑な認証フロー等が必要な場合はGo Adapterを追加できます。 統一ブロックモデルに基づいた標準的な手順で、システムブロック（tenant_id = NULL）またはテナント固有ブロックを追加可能です。 新規の外部連携機能をワークフローエンジンに組み込みたい開発者 Discord通知やSlack連携等の統合機能を実装したいプロダクトマネージャー LLMプロバイダーやOAuth2認証を要するブロックを追加したいバックエンドエンジニア ワークフロー機能を拡張して顧客要望に対応したい技術リード 新規ブロック追加の標準ワークフロー。必読ドキュメント：UNIFIED_BLOCK_MODEL.md（Block execution architecture）、BLOCK_REGISTRY.md（既存ブロック定義）、migrations/011_unified_block_model.sql（既存パターン）。ほとんどのブロックはMigration方式で追加：backend/migrations/XXX_{name}_block.sqlを作成、block_definitionsテーブルにINSERT（tenant_id=NULLでシステムブロック、codeフィールドにJavaScript実装、ui_configでUI設定）、make db-reset実行、BLOCK_REGISTRY.mdを更新。ctx インターフェース提供：ctx.http（HTTPリクエスト）、ctx.llm（LLM API呼び出し）、ctx.workflow（ワークフロー制御）、ctx.human（Human-in-the-loop）、ctx.secrets（秘密情報アクセス）。Go Adapter追加が必要なケース：LLMプロバイダー、OAuth2等複雑認証、バイナリ処理。

プロジェクト固有の用語と技術用語を体系的に定義し、チーム全体で共通理解を作れます。 製品要件書、機能設計書、アーキテクチャ設計書など複数のドキュメントから用語を自動抽出して整理できます。 既存の用語集がある場合は優先順位（既存 > ガイド）に従い、一貫性を保ちながら更新・拡張できます。 テンプレートと詳細ガイドに従うだけで、統一フォーマットの用語集が作成できます。 プロジェクトマネージャーやPO：チーム内の用語の統一により、認識ズレを防ぎたい方 新しいチームメンバー：プロジェクト固有の用語を素早く学びたい方 ドキュメント管理者：複数ドキュメント間の用語の一貫性を保ちたい方 エンジニア・デザイナー：技術用語とビジネス用語を整理して開発効率を上げたい方 前提条件として、docs/product-requirements.md（PRD）、docs/functional-design.md（機能設計書）、docs/architecture.md（アーキテクチャ設計書）、docs/repository-structure.md（リポジトリ構造）、docs/development-guidelines.md（開発ガイドライン）を確認します。用語集は全てのドキュメントで使用される用語を統一的に定義し、各ドキュメントから用語を抽出して体系的に整理します。既存の用語集（docs/glossary.md）がある場合は最優先とし、このスキルのガイドは参考資料として使用します。新規作成時はテンプレート（./template.md）とガイド（./guide.md）を参照し、出力先はdocs/glossary.mdです。

PRD（製品要件書）の技術的な実装方法を詳細な設計書として作成できます。 プロジェクト固有の既存設計書がある場合、それを優先して参考にしながら新規作成・更新ができます。 汎用的なテンプレートと詳細ガイドに従い、一貫性のある機能設計書を生成できます。 作成した設計書を docs/functional-design.md に自動保存できます。 設計書のテンプレートと作成ガイドを参照しながら、品質の高い設計ドキュメントを効率的に作成できます。 プロダクト企画から開発への手引きを明確にしたい企画・PM 要件を技術仕様として落とし込む必要がある開発リーダー チーム全体で設計の一貫性を保ちたいプロジェクト管理者 既存の設計ルールを後発メンバーに引き継ぎたい技術責任者 このスキルは、機能設計書作成時に使用する詳細ガイドです。前提として docs/product-requirements.md の存在が必須です。既存の機能設計書 docs/functional-design.md がある場合はそれを最優先で参照し、次にこのスキルのガイドを補助資料として使用します。新規作成時はスキル内のテンプレート（./template.md）と詳細ガイド（./guide.md）を参照して作成してください。作成した機能設計書は必ず docs/functional-design.md に保存し、既存の設計書を更新する際も既存の構造と内容を維持しながら追記するようにします。

アーキテクチャ設計書をもとに、プロジェクトの最適なディレクトリ構造を自動生成できます。 技術スタックに応じた標準的なフォルダ配置やファイル構成を定義でき、チーム全体で統一された構造を維持できます。 既存のリポジトリ構造定義書がある場合は優先順位に従って適切に更新・保守できます。 リポジトリ構造定義書（docs/repository-structure.md）をテンプレートとガイドに従って作成・管理できます。 プロジェクト立ち上げ時にディレクトリ構造を整理したい企画・マネージャー 技術スタックが決まったので、それに合わせたリポジトリ構造を定義したい開発リーダー チーム内でコードの場所がばらばらで、構造を統一したい開発チーム 既存プロジェクトの構造が設計書と乖離している場合に正しい構造へ戻したい方 このスキルは、リポジトリ構造定義に必要な前提条件として、PRD（docs/product-requirements.md）、機能設計書（docs/functional-design.md）、アーキテクチャ設計書（docs/architecture.md）の確認を必須としています。リポジトリ構造は、アーキテクチャ設計で決定された技術スタックとシステム構成を反映した具体的なディレクトリ構造を定義します。既存のdocs/repository-structure.mdがある場合は最優先として、スキルのガイドより優先されます。新規作成時はテンプレート（./template.md）とガイド（./guide.md）を参照し、出力先はdocs/repository-structure.mdに統一しています。

Go（バックエンド）とTypeScript/Vue（フロントエンド）の両方に対応した、テストケースの追加テンプレートを提供します。どの言語でも同じテストの思考方法（準備→実行→検証）で効率的にテストを書けます。 テーブル駆動テスト（複数のテストケースを統一形式で管理）の構造を提示することで、正常系・異常系・境界値を網羅的かつ保守性高くテストできます。 テストファイルの配置ルール、実行コマンド、ベストプラクティスをまとめて提供するため、プロジェクト全体で一貫性のあるテスト体制を構築できます。 カバレッジ（テストの網羅度）を高めるためのガイドラインが含まれており、どの程度までテストすべきかが明確になります。 新機能実装と同時にテストを書きたい開発者 テストコードの書き方を統一したいテックリード プロジェクトのテストカバレッジを段階的に向上させたいQAエンジニア

自己レビューから PR 作成まで の流れを一連で実行でき、レビュー漏れを防げます。 テストと品質チェック を自動で行い、問題のあるコードが混入するのを防止できます。 CI 結果と AI レビュー結果 をリアルタイムで確認でき、指摘事項があればすぐ修正できます。 マージまでの手順 が明確になるため、うっかり不完全な状態で統合してしまうミスが減ります。 開発初心者で PR 作成時に何を確認すればいいか分からない人 チーム開発で品質基準を統一したい PM やリーダー バグやレビュー指摘を減らしたい開発チーム全体

バグが本当に再現するか最初にテストで確認 でき、原因の特定が早くなります。 修正後のテストが自動で実行 されるため、修正漏れや新たなバグの発生を防げます。 関連する境界値やエッジケース も一緒にテストするので、同じバグの再発を減らせます。 よくあるバグパターン と確認ポイントが一覧でまとまっているため、原因探しが効率的になります。 バグ修正時に何から始めればいいか分からない開発者 テスト駆動開発（TDD）を導入したいチーム バグの再発やリグレッション（後戻り）を減らしたい QA・テスト担当者

CI テストと AI による自動レビュー の結果をコマンド一つで確認でき、待ち時間を短縮できます。 指摘事項があった場合の修正フロー が明確なため、何をすればいいか迷わずに対応できます。 マージ可能な状態 をチェックリストで判断できるため、不完全なまま統合するミスが防げます。 修正→再審査 の流れが自動で回るため、レビュー待ちの時間を効率的に使えます。 PR のマージ判断に迷うことがある開発者 CI やコードレビューツールの使い方をチームに統一させたい PM コードレビューのターンアラウンド時間を短縮したい開発チーム

テスト実行と品質チェック を自動で行い、PR 作成前に問題を発見できます。 セキュリティやパフォーマンス の一般的な問題を事前チェックリストで検出でき、本レビュー時の指摘を減らせます。 デバッグコード残りや TODO 残し を検出でき、不要なコードが本番環境に混入するのを防げます。 プロジェクト規約への準拠状況 が一目で分かるため、チーム標準を保ちやすくなります。 コードを書き終わった後の確認方法が分からない開発者 PR レビュー時の指摘を減らしたいチームリーダー コード品質を一定以上に保ちたい開発チーム全体

何のドキュメントを更新すべきか が表でまとまっているため、更新漏れを防げます。 既存の形式に合わせた更新 ができるので、ドキュメント全体の統一感が保ちやすくなります。 コードとドキュメントのズレ が発生しにくくなり、後々の保守作業が楽になります。 API 仕様や DB スキーマの変更 が正確に記録されるため、チーム内の情報共有がスムーズになります。 どのドキュメントを更新すればいいか分からない開発者 ドキュメントの更新漏れでトラブルが起きている PM・リーダー コードとドキュメントのズレをなくしたい開発チーム全体

コーディング規約の整備：型定義、命名規則、関数設計など、コード実装時に必要な統一ルールを具体例付きで定義できます。 開発プロセスの標準化：Git運用、ブランチ戦略（Git Flow）、コミットメッセージ、PRプロセスなどをチーム全体で統一できます。 品質基準の明確化：テスト方針（テストピラミッド）、カバレッジ目標、コードレビュープロセスを定義し、品質を可視化できます。 新規開発時の指針：命名規則やテスト戦略、セキュリティ対策など、新規開発の際に必要な実装パターンをすぐに参照できます。 CI/CD基盤の構築支援：品質自動化やパイプライン構築の方針を定義し、継続的インテグレーション（継続的に品質をチェックする仕組み）の実装をサポートできます。 チームの開発生産性を上げたいプロジェクトマネージャーやリーダー 属人的なコード品質のばらつきを統一したいチーム全体の開発メンバー 新メンバーがすぐに開発に参加できる環境を整えたい開発チームの管理者 複数プロジェクトのコーディング規約を統一的に管理したい企業の技術統括者