yodogawa

Plugin yodogawa from marketplace yodogawa in tkysi-mi/Yodogawa. Commands read from the repo's manifest — 1 month ago.

Skills (30)

• verify-issue-facts

  GitHub Issue の主張をコードベースと照合し、各主張を【事実/誤り/不明】判定し関連箇所マップを提示する。Issue対応に着手する前の事実確認に使用。読み取り専用でコードは一切編集しない。

• check-verification-readiness

  変更/Issueに対する「推奨検証方法」と「検証環境の現状（node/npm・依存・一時ターゲット・認証）」を診断し、検証可能までのギャップと手順を提示する。合意があれば検証環境のセットアップ（依存導入・一時ターゲット用意・copy smoke）まで行い、実装後の検証で使う検証 runbook を次ステップ用に残す。事実確認の後・実装計画の前に使用。

• plan-coding-and-verification

  事実確認(#1)・検証レディネス(#2)の後、コード実装に着手する前の計画段階で使用。Plan Mode で実装と検証を計画し、新規ブランチ作業とコミット先送りを徹底したいとき。実装・コミット・PR の前。

• execute-verification

  実装後（または既存の変更・PR）に検証を実際に実行し、証拠付き pass/fail と未検証項目を出すときに使用。静的ゲートだけで「動いた」と言わず、機能(CLI smoke)・公開(npm pack/install smoke)まで確認したいとき。#3 計画の検証段の実行・計画外の小変更・「この変更を検証して」。コミット/出荷の前。

• ship-and-confirm

  実装と検証(green)が済み、ユーザーが出荷を承認した後に使用。feature ブランチのコミット → push → PR → ローカルゲート/マージ可否確認 → squash マージ →(承認時)npm リリースまでを規約どおり安全に行う。未検証・承認前には使わない。コミット/マージ/リリースの局面。

• a-001-setup-doc-structure

  docs/ 配下にプロジェクト/タスク用のディレクトリ構造と README を作成する。新規リポジトリでドキュメント基盤を初期化する際に使用。

• a-002-initialize-project

  プロジェクトの問題定義(Why)を Product Brief（誰のどの課題を・なぜ今・どう解き・どう成功を測るか）として対話形式で作成し、要件定義の起点とする。MVP スコープ・ユーザーストーリーは後続スキルが担う。新規（greenfield）/ 既存（existing）の2モードに対応し、既定は新規。新規プロジェクト開始時、または要件が未整備の場合に使用。

• a-002a-slice-mvp-scope

  Product Brief を起点に Parking Lot（アイデア backlog）を生成し、候補機能を Must / Not Now / Won't に切り分けて MVP スコープを確定する。各 Must 機能を課題・仮説・成功指標に紐づけて正当化し、やらないこと（Out of Scope）も明示する。Product Brief 作成後（a-002 の後）に実行。

• a-002b-define-user-stories

  Product Brief と MVP スコープ確定後に、Must 機能を起点としたユーザーストーリー（役割・目的・価値）を作成し、要約レベルの受け入れ基準と優先度を付与する。a-002a（MVP スコープ）の後、a-003（シナリオ）の前に実行。

• a-003-create-scenarios

  MVP Scope の Must 機能から「価値提供が成立する最小行動（Core Scenarios）」を定義する。Day 1 の成功体験・価値を壊す重大失敗・MVP で対応しない範囲を固定する。詳細な Gherkin は任意。要件定義後、ドメイン設計前の振る舞い明確化に使用。

• a-004-define-domain-model

  Core Scenarios と MVP Scope から軽量な Domain Sketch（主要用語・境界・中核エンティティ・重要ルール）を定義し、ユビキタス言語を整備する。完全な Event Storming は任意（a-005）。シナリオ作成後、ドメイン理解を素早く固定する際に使用。

• a-005-create-domain-diagram

  （任意 / advanced）Domain Sketch を完全な Event Storming（Bounded Context・Aggregate・Context Map）へ拡張し、Mermaid 図で可視化する。複雑なドメインで Full DDD が必要なときに使用。標準の MVP フローには含まれない。

• a-006-review-requirements-domain

  要件定義・シナリオ・ドメインモデル間の一貫性を検証し、さらに MVP 正当化（過剰作り込み検査）と Go / Go with caveats / No-Go の PM Gate 判定を行う。ステークホルダー向け要約（STAKEHOLDER-SUMMARY.md）と AI 実装用コンテキスト（AI_CONTEXT.md）を生成する。ドメイン設計完了後、技術選定・実装フェーズへ移る前の関門として使用。

• a-007-define-tech-stack

  要件とドメインモデルを踏まえて推奨技術スタックを提案し、対話で最終確定する。ドメイン設計完了後、実装技術を選定する際に使用。

• a-008-define-repository-structure

  技術スタックに基づきディレクトリ構造・アーキテクチャパターン・命名規則を定義する。技術選定後、コードの配置方針を決める際に使用。

• a-009-define-screen-design

  ユーザーストーリーとシナリオから画面一覧・遷移フロー・レスポンシブポリシーを定義する。技術選定後、UI/UX 設計を開始する際に使用。

• a-010-define-design-system

  カラー・タイポグラフィ・スペーシング・コンポーネントスタイルを含むデザインシステムを定義する。画面設計後、UI 実装のスタイル基盤を固める際に使用。

• a-011-define-data-model

  ドメインモデルと画面設計からデータベース構造（ERD・エンティティ・属性・リレーションシップ・制約）を定義する。画面設計後、永続化層を設計する際に使用。

• a-012-define-api-spec

  データモデルと画面設計から API 仕様（認証方式・エンドポイント一覧・共通レスポンス形式）を定義する。データモデル確定後、フロント/バック間のインターフェースを固める際に使用。

• a-013-define-architecture

  技術スタック・リポジトリ構造・データモデル・API 仕様を統合し、システムアーキテクチャと ADR を定義する。各設計ドキュメント確定後、全体像と意思決定を文書化する際に使用。

• a-014-define-infrastructure

  アーキテクチャ設計を基にインフラ構成図・環境構成・運用方針を定義する。アーキテクチャ確定後、デプロイ/運用環境を設計する際に使用。

• a-015-review-design

  設計ドキュメント（技術・画面・データ・API・アーキ・インフラ）間の一貫性を検証し、要件・ドメインモデルとの整合性を確認する。設計フェーズ完了後、タスク分解に入る前の検査として使用。

• b-001-create-task-directory

  docs/tasks/ 配下に連番タスク ID 付きディレクトリを作成する。新しい実装タスクに着手する最初の手順として使用。

• b-002-create-task-definition

  対話を通じてタスク定義（目的・変更内容・受け入れ基準）を a-definition.md に記録する。タスクディレクトリ作成後、仕様を確定する際に使用。

• b-003-create-task-research

  タスク実装前に既存コード・ベストプラクティス・再利用候補・リスクを調査し b-research.md に記録する。タスク定義確定後、実装計画作成前に使用。

• b-004-create-task-implementation

  タスクをステップ単位に分割し、各ステップの成果物・受け入れ基準を c-implementation.md に定義する。リサーチ完了後、実装着手前に使用。

• b-005-review-task

  タスクの定義・リサーチ・実装計画ドキュメント間の一貫性をレビューし、不整合や抜け漏れを検出する。タスク実装に着手する前の最終確認として使用。

• c-001-implement-task

  c-implementation.md のステップを順次実行し、テスト・レビューを経て機能を完成させる。タスクレビュー後、実装を開始する際に使用（speckit.implement スタイル）。

• c-002-update-documentation

  実装完了後にタスクドキュメント（a-definition / b-research / c-implementation）とプロジェクトドキュメント（要件・ドメイン・API・データモデル等）を実装結果に合わせて更新する。実装完了後、ドキュメントと実コードの整合を取る際に使用。

• d-001-review-retrospective

  A〜Cシリーズ（または1タスク分のb/cサイクル）完了後、成果物ドキュメント（振り返り・ベストプラクティス・レビューレポート）から摩擦点を収集し、対象SKILL.mdへの修正案をdiff形式で提示、docs/LESSONS.mdに汎用的な学びを記録する。A〜Cシリーズ完了後の振り返りタイミングで使用。

Similar plugins