agentsclimarketplace
Sign in

A 015 review design

Skill tkysi-mi/Yodogawa/skills/a-015-review-design

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

Install
npx -y skills add tkysi-mi/Yodogawa --skill a-015-review-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

6.7 KB, as published. Nobody here has run it

ReviewDesign (a-015)

目的

  • 設計フェーズで作成されたすべてのドキュメント間の一貫性を体系的にチェックする。
  • 設計ドキュメント間の不整合、漏れ、矛盾を検出し、修正提案を提供する。
  • 技術選定、アーキテクチャ、データモデル、API 仕様の整合性を確認する。
  • レビュー結果レポートを作成し、修正すべき項目を優先度付きでリストアップする。

前提

  • 要件・ドメインレビューが完了していること（/a-006-review-requirements-domain 実施済み）。
  • 以下の設計ドキュメントが作成されていること:
    • docs/project/04-design/01-tech-stack.md
    • docs/project/04-design/02-repository-structure.md
    • docs/project/04-design/03-screen-design.md
    • docs/project/04-design/05-data-model.md
    • docs/project/04-design/06-api-spec.md
    • docs/project/04-design/07-architecture.md
    • docs/project/04-design/08-infrastructure.md

手順

1. doctor によるドキュメント健全性検査

npx -y yodogawa doctor --json

findings から check: "structure" かつ file が docs/project/04-design/ で始まる項目を確認し、必須ファイル・見出しの欠落があれば対応するスキル（a-007〜a-014）の実行を促す。id-trace は 04-design 配下を対象にした ID 体系を持たないため、観点 2.1〜2.5 に直接的な機械判定は無い（bin/lib/project-spec.js の ID_FAMILIES に 04-design 向けの族が定義されていないため）。placeholder/links の finding は前提整合性の補助シグナルとして使う（未記入セクション・リンク切れの有無。[Owner名] の placeholder finding は観点 2.6 に振り分ける）。doctor が実行できない場合のみ、代替として ls -l docs/project/04-design/*.md を実行する。

2. 一貫性チェックの実行（観点別 PASS/FAIL + 根拠引用）

以下の 6 観点を PASS / FAIL で判定する（判定ルール: 観点内に Error 相当の指摘が1件以上あれば FAIL、Warning 相当のみなら PASS+注記）。doctor の id-trace は 04-design を検査対象にしないため、2.1〜2.5 はエージェント自身の Read/Grep による判断になる（2.6 のみ doctor の placeholder 検出を補助に使える）。各判定には file:line の引用を必須とする（詳細は reference/consistency-checks.md）。

エージェントの役割範囲: doctor が既に検査済みの機械的観点（手順1の存在確認）は再実装しない。一方、この手順2の観点は 2.6（placeholder が補助）を除きすべて doctor 非対応の意味判断であり、役割は「読解判断＋証拠引用」である。Read/Grep/Glob を自由に使ってよい（むしろ必須）。判断した結果は必ず file:line の引用を伴わせる。

  • 2.1 テックスタック ↔ アーキテクチャ: 選定技術の反映、ADR の記録
  • 2.2 データモデル ↔ ドメインモデル: Aggregate のカバレッジ、用語統一
  • 2.3 API 仕様 ↔ データモデル: リソース・フィールドの整合
  • 2.4 画面設計 ↔ API 仕様: 必要なエンドポイントのカバレッジ、状態対応
  • 2.5 インフラ ↔ アーキテクチャ: 構成の網羅、非機能要件の反映
  • 2.6 ドキュメントメタ情報（Owner / Status）（一部 doctor 対応）: 各設計ドキュメント冒頭のメタヘッダで Owner が記入済みか（[Owner名] の残置は doctor の placeholder が検出）、Status がフェーズと整合しているか。IF ヘッダ自体が無い（旧テンプレート由来） THEN FAIL にせず PASS＋注記とし、ヘッダの追補を提案する。Status の不整合も FAIL ではなく更新提案とする。

structure/links の finding は各観点に一対一対応しないため、判断材料としてのみ利用する（placeholder の [Owner名] は観点 2.6 に振り分ける）。

3. レビュー結果レポートの作成

観点別 PASS/FAIL の結果をまとめ、docs/project/DESIGN-REVIEW-REPORT-YYYYMMDDHHMMSS.md を作成する。フォーマットは examples/review-report-template.md を参照。

必須セクション:

  • サマリー（観点別 PASS/FAIL の件数）
  • 詳細（上記 6 観点ごとの PASS/FAIL・根拠(file:line引用)・コメント）
  • 推奨アクション（修正すべきタスクとスキル参照）

4. 結果の報告と修正提案

  • レポート内容を要約してユーザーに伝える。
  • 重大なエラー（Error）がある場合は優先修正を提案。
  • 「修正作業を開始しますか？それともレポートを Git に保存して終了しますか？」

5. Git への追加（任意）

git add docs/project/DESIGN-REVIEW-REPORT-*.md
git commit -m "docs: 設計整合性レビューレポートの作成"

完了条件

  • docs/project/DESIGN-REVIEW-REPORT-YYYYMMDDHHMMSS.md が作成されている。
  • 全設計ドキュメント間の整合性がチェックされ、観点ごとの判定（PASS/FAIL）と根拠（file:line引用）が記録されている。
  • 具体的な修正アクションが提案されている。

エスカレーション

  • 致命的な不整合がある: 「データモデルと API 仕様の間に大きな乖離があります。実装手戻りを防ぐため、設計の見直しを強く推奨します。」
  • ドメインモデルとの乖離: 「設計がドメインモデルの意図を反映していません。ビジネスロジックの破綻につながる恐れがあります。」
  • 判断基準は reference/consistency-checks.md を参照。

参考

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.