AgentSkillsCN

spec-editor

可用于“编写/修订规格说明书”“创建/修改spec.md”“编写并修订相当于spec.md的规格说明书”等需求。参考concept.md判断项目规模，以日语完整且一致地编写或更新整体或按功能单元划分的规格说明书。

SKILL.md
--- frontmatter
name: spec-editor
description: 「仕様書を作る/直す」「spec.mdを作成/修正」「仕様書(spec.md相当)を作って/直して」などの依頼で使用。concept.mdを参照して規模を判断し、全体または機能単位の仕様書を日本語で整合性を保って作成・更新する。

Spec Editor

基本方針

  • •出力は日本語で一般的な仕様書トーンにする。
  • •concept.md を参照して整合性を担保する（用語・UC・機能・データ）。
  • •読みやすさを優先し、一覧系は表形式を使う。
  • •各章の切れ目に空行を1行入れる。
  • •I/F詳細・API使用の詳細は書かない（要件レベルに留める）。
  • •要件は「正常系（XXする/できる）」のみを書く。
  • •エラーは各要件の枝番仕様として整理し、ERR/MSGと必ず紐づける。
  • •通信断/タイムアウト/バリデーション/権限/競合/重複/対象なし/ファイルアクセス失敗/DB記録失敗/長時間処理の多重起動等の典型エラーは可能な限り盛り込む。

出力の分離ルール

  • •仕様書本文は単独で出力する（レビュー文は同じ出力に混ぜない）。
  • •レビュー提案は仕様書出力の後、別メッセージで行う。

生成フロー（厳守）

  • •まず concept.md の有無を確認する。未提示なら要約を依頼する。
  • •concept.md を読み、規模判定表で「全体仕様のみ」か「機能別仕様」に分ける。
  • •不足情報は提案案を示し、ユーザーの同意/修正を確認してから生成する。

規模判定（concept.mdから判断）

条件出力
UC ≤ 5 かつ Feature ≤ 8 かつ 主要ロール ≤ 3全体仕様のみ（spec.md）
上記のいずれかを超える全体仕様 + 機能別仕様

例外

  • •ユーザーが明示的に指定した場合はそちらを優先する。

事前確認（提案して確認する）

  • •対象スコープ（全体/機能別の分割方針）
  • •対象ユーザー/権限範囲（ロールごとの操作）
  • •データの保存方針（履歴保持・削除・監査）
  • •公開範囲（社内/部署/個人）
  • •例外/制約（競合・重複・不可条件）
  • •REQ-IDの命名ルール（プロジェクト名/機能短縮名のどちらを使うか）

出力形式

  • •全体仕様のみ: spec.md を1つ出力する。
  • •機能別仕様: spec.md（全体） + spec/feature-<id>.md を出力する。
  • •機能別仕様は xxxx_spec.md（機能名に応じたファイル名）でもよい。
  • •複数ファイルの場合は、各ファイルを個別のコードブロックで示し、先頭にファイル名行を付ける。

spec.md テンプレート（全体仕様）

markdown
# <プロジェクト名>

要件とは（レビュー者視点）＋ Given/When/Done ＋ MSG/ERR のID管理  
※I/F詳細・API使用は書かない

# 要件一覧（Requirements）
| ID | 要件（固定書式・正常系のみ） | 関連UC-ID |
|---|---|---|
| REQ-0001 | XXXをしたら、YYYYする。 | UC-1 |

### [<プロジェクト名>-0001] XXXをしたら、YYYYする。
Given：前提状態  
When：トリガ（ユーザー操作や内部イベント）  
Done：完了条件（観測可能な結果）

#### エラー分岐（REQ-0001の枝番）
| ERR-ID | 発生条件 | ユーザーアクション | 関連MSG-ID |
|---|---|---|---|
| ERR-<プレフィックス>-0001 |  |  | MSG-<プレフィックス>-0001 |

（必要なら）短い例：
- 例：XXXをしたら、YYYYする。

## メッセージID管理（MSG-xxxx）
| ID | 文面テンプレ | 出力先 | 発生条件 | 関連REQ/ERR |
|---|---|---|---|---|
| MSG-<プレフィックス>-0001 |  |  |  | REQ-0001 |

## エラーID管理（ERR-xxxx）
| ID | 原因 | 検出条件 | ユーザーアクション | 再試行可否 | 関連MSG-ID | 関連REQ |
|---|---|---|---|---|---|---|
| ERR-<プレフィックス>-0001 |  |  |  | 可/不可 | MSG-<プレフィックス>-0001 | REQ-0001 |

機能別仕様テンプレート

markdown
# <機能名>

要件とは（レビュー者視点）＋ Given/When/Done ＋ MSG/ERR のID管理  
※I/F詳細・API使用は書かない

# 要件一覧（Requirements）
| ID | 要件（固定書式・正常系のみ） | 関連UC-ID |
|---|---|---|
| REQ-0001 | XXXをしたら、YYYYする。 | UC-1 |

### [<機能名>-0001] XXXをしたら、YYYYする。
Given：前提状態  
When：トリガ（ユーザー操作や内部イベント）  
Done：完了条件（観測可能な結果）

#### エラー分岐（REQ-0001の枝番）
| ERR-ID | 発生条件 | ユーザーアクション | 関連MSG-ID |
|---|---|---|---|
| ERR-<プレフィックス>-0001 |  |  | MSG-<プレフィックス>-0001 |

（必要なら）短い例：
- 例：XXXをしたら、YYYYする。

## メッセージID管理（MSG-xxxx）
| ID | 文面テンプレ | 出力先 | 発生条件 | 関連REQ/ERR |
|---|---|---|---|---|
| MSG-<プレフィックス>-0001 |  |  |  | REQ-0001 |

## エラーID管理（ERR-xxxx）
| ID | 原因 | 検出条件 | ユーザーアクション | 再試行可否 | 関連MSG-ID | 関連REQ |
|---|---|---|---|---|---|---|
| ERR-<プレフィックス>-0001 |  |  |  | 可/不可 | MSG-<プレフィックス>-0001 | REQ-0001 |

整合性チェック

  • •concept.md の UC/Feature と要件の関連UC-IDが一致するか確認する。
  • •要件一覧の REQ-xxxx と詳細見出し（<プロジェクト名/機能名>-xxxx）の番号が一致するか確認する。
  • •各要件に Given/When/Done が揃っているか確認する。
  • •要件一覧は正常系のみで書かれているか確認する。
  • •各要件のエラー分岐が ERR/MSG と紐づいているか確認する。
  • •MSG/ERR が REQ と紐づいているか確認する。
  • •I/F詳細・API使用の詳細が書かれていないか確認する。
  • •concept.md のユースケースが仕様書群（spec.md + 機能別仕様）で網羅されているか確認する。
    • •単一の spec.md だけで網羅できない場合は、機能別仕様でのカバーを明記する。

出力後の提案（レビュー促進）

  • •仕様書出力の次メッセージで、必ずレビュー提案を行う（下記テンプレートを使用）。

レビュー提案テンプレート（固定文）

「SWEエージェント観点でspecを評価します。評価としては100点満点でXX点くらいで、こういった点は改善した方がいいかもしれません、というレビューをしますか？」

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

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

レビュー時のルール

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

REQ-ID ルール（必須）

  • •REQ-xxxx は4桁のゼロ埋め連番とする（例: REQ-0001）。
  • •詳細見出しは [<プレフィックス>-xxxx] を使う。
    • •プレフィックスは「プロジェクト名」または「機能短縮名」のどちらでもよい。
    • •どちらを使うかは事前確認で決め、文書内で統一する。
  • •採番単位はプロジェクト単位とし、複数spec間で重複しない。

MSG/ERR-ID ルール（必須）

  • •MSG/ERR は MSG-<プレフィックス>-xxxx / ERR-<プレフィックス>-xxxx とする。
  • •<プレフィックス> は REQ と同一の命名方針（プロジェクト名 or 機能短縮名）で統一する。
  • •採番単位はプロジェクト単位とし、複数spec間で重複しない。