AgentSkillsCN

concept-editor

适用于“创建 concept.md”、“构思/修正/完善 concept”、“评估/审查 concept 文档”等需求。以固定 11 个章节的格式进行编辑，同时确保产品概念、用例、功能模块与核心数据的一致性。可用于规格说明书的概要撰写，或服务企划的文档化需求。

SKILL.md
--- frontmatter
name: concept-editor
description: 「concept.mdを作成」「conceptを作る/直す/修正」「concept文書を評価/レビュー」など、concept.mdの作成・更新・評価を行う。プロダクト概念・ユースケース・機能ブロック・主要データの整合性を担保しながら編集する固定11セクション形式。仕様書の概要やサービス企画の文書化依頼で使用。

Concept Editor

基本方針

  • •出力は日本語で一般的な仕様書トーンにする。
  • •出力は concept.md 本文のみとし、前後の説明文を付けない。
  • •フォーマットは下記テンプレートに完全一致させる。
  • •既存の concept.md がある場合は内容を活かしつつ、テンプレート順に整形する。
  • •出力品質の基準が必要なときは references/sample-concept.md を読み、構成・粒度を合わせる。
  • •読みやすさを優先し、一覧系は表形式で作成する（#5, #6, #8, #9）。
  • •各章の切れ目に空行を1行入れる（詰め込みを避ける）。

出力の分離ルール（矛盾回避）

  • •concept.md 本文は単独で出力する（レビュー文は同じ出力に混ぜない）。
  • •レビューは依頼がある場合のみ、concept.md 出力の後に別メッセージで行う。

情報収集と仮説

  • •不足情報は質問で補う。質問は重要度が高い順に最大5件までに抑える。
  • •不足があっても推測できる場合は妥当な案を提示し、「この前提で良いか」を確認する。
  • •ユーザーが未認識の観点がありそうなら、仮説を提案して引き出す。

生成フロー（厳守）

  • •まず「提案案（4観点）」を提示し、ユーザーの同意/修正を確認する。
  • •同意後に concept.md を生成する。

最小質問例

  • •何を作るか（製品/サービスの一言要約）
  • •誰のどんな困りごとを解決するか
  • •主要なユースケース（2〜5件）
  • •使われる場面や前提環境（端末/OS/ネットワーク/社内外など）
  • •技術スタックの希望や制約

生成前に提案して確認すべき観点（範囲の曖昧さを潰す）

  • •役割と権限範囲（利用者/管理者/閲覧者などの操作範囲）
  • •データの保存方針（削除/退職者/履歴保持/監査の必要性）
  • •データの公開範囲（社内のみ/部署内/個人のみ）
  • •例外時の扱い（操作不可の条件、競合・二重操作の扱い）

必須運用

  • •上記4観点は必ず「こちらの提案案」を先に示し、ユーザーの同意/修正を確認してから生成する。

仮説の立て方（情報不足時）

  • •プラットフォーム未指定なら「Webアプリ（PC/スマホ両対応）」を仮定する。
  • •ターゲット未指定なら「業務担当者/管理者」を仮定する。
  • •仮説は「前提（Assumptions）」に明記し、了承が得られるか確認する。

出力テンプレート（厳守）

markdown
# concept.md（必ず書く：最新版）
#1.概要（Overview）（先頭固定）
- 作るもの（What）：
- 解決すること（Why）：
- できること（主要機能の要約）：
- 使いどころ（When/Where）：
- 成果物（Outputs）：
- 前提（Assumptions）：

#2.ユーザーの困りごと（Pain）

#3.ターゲットと前提環境（詳細）

#4.採用する技術スタック（採用理由つき）

#5.機能一覧（Features）
| ID | 機能 | 解決するPain | 対応UC |
|---|---|---|---|
| F-1 |  |  | UC-1 |

#6.ユースケース（Use Cases）
| ID | 主体 | 目的 | 前提 | 主要手順（最小操作） | 成功条件 | 例外/制約 |
|---|---|---|---|---|---|---|
| UC-1 |  |  |  |  |  |  |

#7.Goals（Goalのみ／ユースケース紐づけ必須）
- G-1: （対応：UC-1）

#8.基本レイヤー構造（Layering）
| レイヤー | 役割 | 主な処理/データ流れ |
|---|---|---|
| プレゼンテーション層 |  |  |

#9.主要データクラス（Key Data Classes / Entities）
| データクラス | 主要属性（不要属性なし） | 用途（対応UC/Feature） |
|---|---|---|
|  |  |  |

#10.機能部品の実装順序（Implementation Order）

#11.用語集（Glossary）

セクション別の作成ルール

  • •#1 は6項目すべて埋める。
  • •#4 は採用理由を必ず併記する（1行で良い）。
  • •#5 は表形式で F-1, F-2… と採番する。
  • •#6 は表形式で UC-1, UC-2… の形式で採番する。主要手順は最小操作で具体的に書く。
  • •#7 は G-1, G-2… の形式で採番し、各Goalに「対応：UC-?」を必ず付ける。
  • •#7 は Goal のみを書く（達成指標や実装詳細は書かない）。
  • •#10 は順序が分かるように番号付きで並べる。
  • •追加セクションは作らない。

最小性の判断ガイド（内容依存だが基準は固定）

過剰機能を避ける

  • •機能は「Painを解決するために必要な最小集合」に限定する。
  • •各機能に「解決するPain / 対応UC」を必ず割り当てる。割り当てできない機能は削除候補。
  • •反証テスト: その機能を削ってもPain/UCが成立するなら過剰機能とみなす。

最小操作にする

  • •ユーザーの明示操作（入力/クリック/画面遷移）を最小化する。
  • •同一情報の再入力は不可。既存データ/自動補完/推定で代替できるなら採用する。
  • •UCごとに「必須入力」と「自動化できる入力」を分け、後者は極力排除する。
  • •UCで必要な操作が多い場合、フローを短縮する代替案を必ず検討する。

最小データにする

  • •データクラスは「UCを成立させるために必須の永続データ」に限定する。
  • •各データクラスは「不要属性がない」ことを確認する（使われない/重複/推測可能な属性は削除候補）。
  • •派生データは原則保存せず算出に寄せる（必要な場合のみ保存理由を明記）。
  • •1つの概念は1つの正のソース（Single Source of Truth）に集約する。
  • •レイヤー/ブロックはUCに必要な最小データ流れのみを通す（冗長な中間層を作らない）。

対応表チェック（整合性を担保する）

  • •Pain → UC → Features → Layering → Data Classes の順で「対応できること」を確認する。
  • •逆方向にも検証する（Data Classes → Layering → Features → UC → Pain）。対応先がない要素は削除候補。
  • •1つのPainは最低1つのUCで解決されること。
  • •1つのUCは最低1つのFeatureで支えられること。
  • •FeatureはLayering上のブロック/層に必ず割り当てること。
  • •Data Classは必ずFeatureまたはUCに登場すること（未使用データは削除候補）。

技術スタックの分岐指針（簡潔に）

  • •まず「希望する言語/フレームワーク」を確認する。
  • •希望がない場合は、用途に合うメジャー技術を2〜3案提示して選んでもらう。
  • •速度優先・少人数運用: マネージドサービス優先（例: フロントSPA + BaaS）。
  • •高い拡張性・複雑要件: 標準的3層（Web/API/DB）で保守性を優先。
  • •リアルタイム要件: WebSocket/Push対応を明記する。
  • •オフライン/現場利用: ローカルキャッシュ/同期方式を明記する。
  • •既存環境制約（言語/クラウド/DB）がある場合は最優先で採用する。

メジャー技術の提示例（希望がない場合）

  • •フロント: React + TypeScript / Vue + TypeScript
  • •バックエンド: Node.js(NestJS) / Python(FastAPI) / Java(Spring Boot)
  • •DB: PostgreSQL / MySQL
  • •インフラ: Docker + 主要クラウド（AWS/GCP/Azure）

品質チェック

  • •11セクションすべて存在するか確認する。
  • •#7 の対応UCが #6 に存在するか確認する。
  • •前提・技術・ユースケースが矛盾していないか確認する。
  • •#2 の困りごとが #5 の最小機能で解決できているか確認する（過剰機能を避ける）。
  • •#6 のユースケースが最小操作で完結するか確認する（頻繁な入力要求や多操作を避ける）。
  • •#8 のレイヤー/ブロックが #6 のユースケースを実現する最小のデータ流れとして構造化されているか確認する。
  • •対応表チェックの両方向（Pain→…→Data / Data→…→Pain）が成立するか確認する。

レビューの扱い

  • •レビュー/評価が明示的に依頼された場合のみレビューを行う。
  • •文書編集のみの依頼ではレビュー提案・定型文を出さない。
  • •レビュー未実施の状態で「レビュー済み」「評価済み」等の表現は禁止。
  • •レビューは concept.md 出力の次メッセージで行う（本文と混ぜない）。

レビュー出力フォーマット（固定）

  • •評価: XX点 / 合格（または要改善）
  • •良い点
    • •箇条書き
  • •改善した方が良い点
    • •箇条書き
  • •次のアクション
    • •修正したい点があれば教えてください（修正します）

レビュー時のルール

  • •100点満点で評価し、80点以上なら「合格」を明示する（例：「評価: 85点 / 合格」）。
  • •改善点は具体的に列挙し、修正希望があれば反映する。