spec-writelisted

# 機能仕様を書く **完了の条件を曖昧さなく書けない機能は、実装へ渡せません**。エージェントが停滞する原因の多くは能力の不足ではなく、完了条件の不在です。 ## 手順 ### 1. 機能 ID を決める `specs/` を見て、次の連番を採ります。`F-001` から始めます。ファイルは `specs/F-NNN/spec.md`。 ### 2. テンプレートから起こす `templates/01-feature-spec.md` を写します。 ### 3. 受入基準を EARS 記法で書く | 型 | 書き方 | 使う場面 | | --- | --- | --- | | ユビキタス | システムは〜しなければならない | 常に成り立つ性質 | | イ���ント駆動 | 〜したとき、システムは〜しなければならない | 契機がある | | 状態駆動 | 〜である間、システムは〜しなければならない | 状態に依存する | | 望ましくない事象 | 〜の場合、システムは〜しなければならない | 異常系 | | 任意機能 | 〜を備える場合、システムは〜しなければならない | 構成で変わる | ### 4. 曖昧語を排除する 次の語は使えません。CI の `spec-lint` が検出し、G-5 を失敗させます。 ``` 適切に / 柔軟に / 可能な限り / など / 必要に応じて / 基本的に 原則として / 速やかに / 十分に / なるべく ``` 「適切にエラーを表示する」は基準になりません。「入力が空の場合、システムは項目名を含むエラーメッセージを当該項目の直下に表示しなければならない」なら基準になります。 ### 5. スコープ外を書く **書かれていない事項は、実装されるか否かが不定になります**。やらないことを明記してください。 ### 6. 検証する ```bash node scripts/gate/spec-lint.mjs specs ``` ## 草案を AI に書かせてよいか 書かせてよいです。ただし**そのまま承認してはなりません**。基準の確定は価値判断であり、価値責任者が行います。 草案を出したあと、次を利用者へ問いかけてください。 - この基準を満たしても、作りたかったものにならない場合はあるか - 書いていない前提はあるか - スコープ外に入れるべきものはあるか ## 完了の条件 - [ ] 受入基準ごとに「条件 + 期待動作」が書けている - [ ] 曖昧語がない(`spec-lint` が通る) - [ ] スコープ外が書かれている - [ ] 価値責任者が承認した(G-2 / G-4) ## 参照 - [附属書B EARS 記法ガイド](https://takenori-kusaka.github.io/process-compass/phase4-process-design/ears-guide/)