Open10

SpecKitとSuperClaudeは併用できるのか？

AI
検証
Claude
Claude Code
speckit
sinanosinano

/specifyを実行してみる。

とりあえずお題はTODOアプリ？と思ったが、解釈の幅が狭い要求じゃないとテストにならないので、最近作ったアプリ「Suvy」にする。

要求はこれでいく。

低温調理の適切な加熱時間をAppIntents経由で調べられるexpo+ReactNativeアプリ。Siri経由で低温調理の加熱時間を調べられるようになれば、料理中にスマホを触らなくて済むようになるから。
出てきたファイル
# Feature Specification: Sous Vide Cooking Time Assistant

**Feature Branch**: `001-appintents-expo-reactnative`  
**Created**: 2025-09-09  
**Status**: Draft  
**Input**: User description: "低温調理の適切な加熱時間をAppIntents経由で調べられるexpo+ReactNativeアプリ。Siri経由で低温調理の加熱時間を調べられるようになれば、料理中にスマホを触らなくて済むようになるから。"

## Execution Flow (main)
  1. Parse user description from Input
    → If empty: ERROR "No feature description provided"
  2. Extract key concepts from description
    → Identify: actors, actions, data, constraints
  3. For each unclear aspect:
    → Mark with [NEEDS CLARIFICATION: specific question]
  4. Fill User Scenarios & Testing section
    → If no clear user flow: ERROR "Cannot determine user scenarios"
  5. Generate Functional Requirements
    → Each requirement must be testable
    → Mark ambiguous requirements
  6. Identify Key Entities (if data involved)
  7. Run Review Checklist
    → If any [NEEDS CLARIFICATION]: WARN "Spec has uncertainties"
    → If implementation details found: ERROR "Remove tech details"
  8. Return: SUCCESS (spec ready for planning)

---

## ⚡ Quick Guidelines
- ✅ Focus on WHAT users need and WHY
- ❌ Avoid HOW to implement (no tech stack, APIs, code structure)
- 👥 Written for business stakeholders, not developers

### Section Requirements
- **Mandatory sections**: Must be completed for every feature
- **Optional sections**: Include only when relevant to the feature
- When a section doesn't apply, remove it entirely (don't leave as "N/A")

### For AI Generation
When creating this spec from a user prompt:
1. **Mark all ambiguities**: Use [NEEDS CLARIFICATION: specific question] for any assumption you'd need to make
2. **Don't guess**: If the prompt doesn't specify something (e.g., "login system" without auth method), mark it
3. **Think like a tester**: Every vague requirement should fail the "testable and unambiguous" checklist item
4. **Common underspecified areas**:
   - User types and permissions
   - Data retention/deletion policies  
   - Performance targets and scale
   - Error handling behaviors
   - Integration requirements
   - Security/compliance needs

---

## User Scenarios & Testing *(mandatory)*

### Primary User Story
A home cook preparing sous vide meals needs to quickly check the appropriate cooking time and temperature for their ingredients while their hands are occupied or dirty. They can ask their voice assistant "What's the cooking time for medium-rare beef at 55°C?" and receive an immediate spoken response without touching their device, allowing them to continue food preparation seamlessly.

### Acceptance Scenarios
1. **Given** the app is installed and voice assistant is enabled, **When** user asks "What's the cooking time for chicken breast?", **Then** the system responds with the recommended time and temperature for sous vide chicken breast
2. **Given** user specifies a food type and desired doneness, **When** they ask "How long for medium-rare steak?", **Then** the system provides the specific time and temperature for that doneness level
3. **Given** user asks while cooking, **When** they say "Sous vide salmon time", **Then** the system responds with cooking time without requiring app to be open
4. **Given** user asks about an uncommon ingredient, **When** the ingredient is in the database, **Then** the system provides accurate cooking guidance
5. **Given** user asks in their preferred language, **When** language is [NEEDS CLARIFICATION: which languages should be supported?], **Then** the system responds in the same language

### Edge Cases
- What happens when user asks about an ingredient not in the database?
- How does system handle ambiguous requests like "meat" without specific type?
- What response is given when user asks for unsafe cooking temperatures?
- How does system respond when network connection is unavailable?
- What happens if multiple cooking methods exist for the same ingredient?

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST provide cooking times for common sous vide ingredients
- **FR-002**: System MUST provide temperature recommendations alongside cooking times
- **FR-003**: System MUST respond to voice queries without requiring visual interaction
- **FR-004**: System MUST support different doneness levels (rare, medium-rare, medium, medium-well, well-done) where applicable
- **FR-005**: System MUST work offline for [NEEDS CLARIFICATION: should basic data be available offline?]
- **FR-006**: System MUST include safety warnings for [NEEDS CLARIFICATION: what safety information is critical - minimum temperatures, food safety guidelines?]
- **FR-007**: System MUST support queries for [NEEDS CLARIFICATION: how many different food types - 50? 100? 500?]
- **FR-008**: System MUST handle thickness/weight variations for [NEEDS CLARIFICATION: should it adjust times based on portion size?]
- **FR-009**: System MUST provide responses within [NEEDS CLARIFICATION: what is acceptable response time - 2 seconds? 5 seconds?]
- **FR-010**: System MUST update its database [NEEDS CLARIFICATION: how often should new recipes/times be added?]

### Key Entities *(include if feature involves data)*
- **Food Item**: Represents an ingredient that can be cooked sous vide, including its name, category (meat, vegetable, seafood), and standard preparation methods
- **Cooking Profile**: Contains time and temperature combinations for a specific food item, including variations for different doneness levels and portion sizes
- **Safety Guideline**: Critical food safety information associated with specific ingredients or temperature ranges
- **User Query**: Voice request from user containing food type, optional modifiers (doneness, size), and context

---

## Review & Acceptance Checklist
*GATE: Automated checks run during main() execution*

### Content Quality
- [ ] No implementation details (languages, frameworks, APIs)
- [ ] Focused on user value and business needs
- [ ] Written for non-technical stakeholders
- [ ] All mandatory sections completed

### Requirement Completeness
- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous  
- [ ] Success criteria are measurable
- [ ] Scope is clearly bounded
- [ ] Dependencies and assumptions identified

---

## Execution Status
*Updated by main() during processing*

- [x] User description parsed
- [x] Key concepts extracted
- [x] Ambiguities marked
- [x] User scenarios defined
- [x] Requirements generated
- [x] Entities identified
- [ ] Review checklist passed (contains NEEDS CLARIFICATION items)

---
sinanosinano

SuperClaude入りの方で同じ/specifyを実行しているけど、普通に動いてそう。

問題はSuperClaudeを入れていることによってSpecの質が上がるのかどうか。

sinanosinano

こんな出来になった

出てきたファイル
# Feature Specification: Sous Vide Cooking Time Assistant with Voice Control

**Feature Branch**: `001-appintents-expo-reactnative`  
**Created**: 2025-09-09  
**Status**: Draft  
**Input**: User description: "低温調理の適切な加熱時間をAppIntents経由で調べられるexpo+ReactNativeアプリ。Siri経由で低温調理の加熱時間を調べられるようになれば、料理中にスマホを触らなくて済むようになるから。"

## Execution Flow (main)
  1. Parse user description from Input
    → If empty: ERROR "No feature description provided"
  2. Extract key concepts from description
    → Identify: actors, actions, data, constraints
  3. For each unclear aspect:
    → Mark with [NEEDS CLARIFICATION: specific question]
  4. Fill User Scenarios & Testing section
    → If no clear user flow: ERROR "Cannot determine user scenarios"
  5. Generate Functional Requirements
    → Each requirement must be testable
    → Mark ambiguous requirements
  6. Identify Key Entities (if data involved)
  7. Run Review Checklist
    → If any [NEEDS CLARIFICATION]: WARN "Spec has uncertainties"
    → If implementation details found: ERROR "Remove tech details"
  8. Return: SUCCESS (spec ready for planning)

---

## ⚡ Quick Guidelines
- ✅ Focus on WHAT users need and WHY
- ❌ Avoid HOW to implement (no tech stack, APIs, code structure)
- 👥 Written for business stakeholders, not developers

### Section Requirements
- **Mandatory sections**: Must be completed for every feature
- **Optional sections**: Include only when relevant to the feature
- When a section doesn't apply, remove it entirely (don't leave as "N/A")

### For AI Generation
When creating this spec from a user prompt:
1. **Mark all ambiguities**: Use [NEEDS CLARIFICATION: specific question] for any assumption you'd need to make
2. **Don't guess**: If the prompt doesn't specify something (e.g., "login system" without auth method), mark it
3. **Think like a tester**: Every vague requirement should fail the "testable and unambiguous" checklist item
4. **Common underspecified areas**:
   - User types and permissions
   - Data retention/deletion policies  
   - Performance targets and scale
   - Error handling behaviors
   - Integration requirements
   - Security/compliance needs

---

## User Scenarios & Testing *(mandatory)*

### Primary User Story
As a home chef preparing sous vide dishes, I want to ask for cooking times and temperatures using voice commands while my hands are occupied with food preparation, so that I can maintain hygiene and efficiency in the kitchen without touching my phone.

### Acceptance Scenarios
1. **Given** a user is preparing beef steak for sous vide cooking, **When** they ask via voice "What's the cooking time for medium-rare beef steak?", **Then** the app responds with the appropriate time and temperature (e.g., "135°F for 1-4 hours depending on thickness")

2. **Given** a user is cooking and asks about chicken breast, **When** they use voice command "How long should I cook chicken breast sous vide?", **Then** the app provides safe cooking parameters (e.g., "140°F for 1.5-4 hours")

3. **Given** a user asks about an unknown food item, **When** they say "What's the sous vide time for [NEEDS CLARIFICATION: handling of unsupported ingredients]?", **Then** the app responds appropriately

4. **Given** the app is accessed for the first time, **When** a user tries to use voice commands, **Then** [NEEDS CLARIFICATION: onboarding/permission flow for voice access]

### Edge Cases
- What happens when the user asks in a noisy kitchen environment?
- How does system handle ambiguous food descriptions (e.g., "meat" without specifying type)?
- What happens when multiple cooking options exist for the same ingredient?
- How does the app respond when offline or when voice recognition fails?
- What happens if the user asks for unsafe cooking parameters?

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST provide cooking times and temperatures for common sous vide ingredients
- **FR-002**: System MUST be accessible via voice commands without requiring physical interaction with the device
- **FR-003**: System MUST provide responses in [NEEDS CLARIFICATION: language preference - Japanese only, multilingual support?]
- **FR-004**: System MUST include safety warnings for minimum safe cooking temperatures
- **FR-005**: Users MUST be able to query cooking information hands-free while cooking
- **FR-006**: System MUST handle [NEEDS CLARIFICATION: number of supported ingredients - core set, expandable database?]
- **FR-007**: System MUST provide cooking time ranges based on [NEEDS CLARIFICATION: thickness/weight parameters, or fixed times?]
- **FR-008**: Voice responses MUST be [NEEDS CLARIFICATION: audio response, visual display, or both?]
- **FR-009**: System MUST work with [NEEDS CLARIFICATION: iOS only via Siri, or cross-platform voice assistants?]
- **FR-010**: App MUST function [NEEDS CLARIFICATION: offline capability required, or online-only acceptable?]

### Key Entities *(include if feature involves data)*
- **Food Item**: Represents an ingredient that can be cooked sous vide (name, category, safe temperature range, cooking time range)
- **Cooking Profile**: Represents a specific cooking configuration (food item, desired doneness, temperature, time range)
- **Voice Query**: Represents a user's voice request (query text, recognized food item, requested information type)
- **Cooking Response**: Represents the app's answer (temperature, time range, safety notes, alternatives if applicable)

---

## Review & Acceptance Checklist
*GATE: Automated checks run during main() execution*

### Content Quality
- [x] No implementation details (languages, frameworks, APIs)
- [x] Focused on user value and business needs
- [x] Written for non-technical stakeholders
- [x] All mandatory sections completed

### Requirement Completeness
- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous  
- [ ] Success criteria are measurable
- [x] Scope is clearly bounded
- [ ] Dependencies and assumptions identified

---

## Execution Status
*Updated by main() during processing*

- [x] User description parsed
- [x] Key concepts extracted
- [x] Ambiguities marked
- [x] User scenarios defined
- [x] Requirements generated
- [x] Entities identified
- [ ] Review checklist passed (contains NEEDS CLARIFICATION markers)

---

## Areas Requiring Clarification

1. **Language Support**: Should the app support Japanese only or multiple languages?
2. **Platform Scope**: iOS-only with Siri, or should it support other voice assistants?
3. **Database Size**: Core set of common ingredients or comprehensive database?
4. **Offline Functionality**: Must work offline or online-only acceptable?
5. **Response Format**: Voice-only responses or include visual display?
6. **Cooking Parameters**: Fixed times or variable based on thickness/weight?
7. **Unsupported Items**: How to handle requests for items not in the database?
8. **Initial Setup**: What permissions and onboarding are needed for voice control?
9. **Safety Features**: Level of food safety warnings and liability considerations?
10. **Update Mechanism**: How will cooking data be updated or expanded?
sinanosinano

英語わかんないからあれだけど、そんなに違いなさそう。

Gemini2.5 proにジャッジしてもらう
プロンプトは、両方のspec.mdを貼り付けてこれらの仕様書はどちらの方が出来がいいと思う？

1回目のジャッジ
結論から言うと、**`spec-superclaude.md` の方が優れた仕様書です。**

どちらのドキュメントも提供されたテンプレートに忠実に従っており、高品質ですが、`spec-superclaude.md` はビジネスの意思決定をより効果的に促す工夫がされています。

---

## 比較評価

| 評価項目 | spec-vanilla.md | spec-superclaude.md | 勝者 |
| :--- | :--- | :--- | :--- |
| **ユーザー視点の解像度** | 良好 | **優れている** | `superclaude` |
| **要求事項の明確さ** | 良好 | 良好 | 引き分け |
| **網羅性（エッジケース）** | 良好 | **優れている** | `superclaude` |
| **次のアクションへの繋がり** | 良好 | **圧倒的に優れている** | `superclaude` |

---

## `spec-superclaude.md` が優れている理由

### 1. ユーザー視点の解像度が高い
`spec-vanilla.md` のユーザーストーリーも的確ですが、`spec-superclaude.md` は「**As a [ペルソナ], I want [やりたいこと], so that [得られる価値]**」という形式で書かれており、「なぜ」この機能が必要なのか（衛生面と効率性の向上）がより明確です。

また、エッジケースとして「騒がしいキッチン環境」を想定している点は、実際の利用シーンへの想像力が行き届いている証拠です。

### 2. 「確認事項の要約」が追加されている
これが最も決定的な違いです。 `spec-superclaude.md` の末尾には **`## Areas Requiring Clarification`** というセクションが追加されています。


これは、ドキュメント内に散らばっている `[NEEDS CLARIFICATION]` の項目を一覧にまとめたものです。これにより、プロジェクトマネージャーやビジネス担当者は、次に何を議論し、何を決定すれば開発に進めるのかを一目で把握できます。

仕様書は「書くこと」が目的ではなく、「次のアクションを決めること」が目的です。この要約があることで、ドキュメントが単なる成果物ではなく、**意思決定を促進するツール**として機能しています。

### 3. 初回利用時の体験（オンボーディング）に言及している
`spec-superclaude.md` は、受入シナリオで「初回利用時の音声アクセスの許可フロー」について言及しています。これはユーザー体験全体を考えている証拠であり、`spec-vanilla.md` には見られない重要な視点です。

## まとめ

`spec-vanilla.md` は、与えられた指示に正確に従った**良い仕様書**です。

しかし、`spec-superclaude.md` は、単に指示に従うだけでなく、**「このドキュメントが次にどう使われるか」**までを考慮し、要約を追加することで、プロジェクトを前進させるための実用性を格段に高めています。この「一歩先を読む」工夫が、`spec-superclaude.md` を**より優れた仕様書**にしています。
2回目のジャッジ（もちろん1回目とは別スレッド）
間違いなく、`spec-superclaude.md`の方が優れた仕様書です。

両方のドキュメントは同じテンプレートから作られていますが、`spec-superclaude.md`はより厳密で、体系的、そしてビジネスの意思決定者にとって実用的です。単に情報をリストアップするだけでなく、次に何をすべきかを明確に示しています。

---

## 比較分析

以下に、両方の仕様書を項目別に比較した詳細な分析を示します。

| 評価項目 | spec-vanilla.md | spec-superclaude.md | 勝者 | 理由 |
| :--- | :--- | :--- | :--- | :--- |
| **ユーザー・ストーリー** | 具体的だが、ユーザーの根本的な動機（Why）が弱い。 | 「As a... I want to... so that...」の形式に沿っており、「衛生と効率を維持するため」という**明確なビジネス価値**を提示している。 | 🏆 **SuperClaude** | なぜこの機能が必要なのか（Why）が明確に定義されているため。 |
| **受け入れシナリオ** | シナリオは妥当だが、形式が少し緩い。初回起動時や未対応項目についての言及がない。 | 厳密な**Gherkin形式**（Given/When/Then）で記述されており、テスト可能性が非常に高い。初回起動時の権限確認や未対応食材の処理といった重要なシナリオを網羅している。 | 🏆 **SuperClaude** | より網羅的で、テストケースとして直接利用できる品質だから。 |
| **エッジケース** | 重要なエッジケース（DBにない食材、オフラインなど）を挙げている。 | 「騒がしいキッチン環境」や「音声認識の失敗」など、**ユーザーの実際の利用状況**をより深く想定した、具体的で現実的なケースを含んでいる。 | 🏆 **SuperClaude** | ユーザーの利用環境まで踏み込んだ、より実践的なリスク分析ができているため。 |
| **機能要件** | 要件は適切だが、パフォーマンス（応答時間）やDB更新頻度など、非機能要件に近い項目も含まれている。 | 各要件が明確で、`[NEEDS CLARIFICATION]`で示した**不明確点と直接リンク**している（例：FR-007と厚みの関係）。プラットフォーム（iOSのみか否か）や応答形式（音声か画面か）など、スコープを決定づける重要な問いを立てている。 | 🏆 **SuperClaude** | 要件が具体的で、解消すべき疑問点と直接結びついているため、議論を進めやすいから。 |
| **不明確点の整理** | 各項目に`[NEEDS CLARIFICATION]`が点在している。 | 文書全体に散らばる不明確点を、最後に**「Areas Requiring Clarification」として集約**している。これにより、次の会議で何を議論すべきかが一目瞭然になる。 | 🏆 **SuperClaude** | ドキュメントを**次のアクションに繋げるための工夫**が秀逸だから。 |

---

## 結論

`spec-vanilla.md`も良い仕様書ですが、`spec-superclaude.md`は一段上のレベルにあります。

その最大の理由は、**仕様書を「作るため」でなく、「次のステップ（計画や意思決定）に進めるため」のツールとして仕上げている**点です。特に、最後に不明確点をリストとしてまとめることで、プロジェクトマネージャーやビジネス担当者はこのドキュメントを受け取った瞬間に何をすべきかを正確に把握できます。

技術的な詳細を排除し、ビジネス価値に焦点を当て、テスト可能な要件を定義し、議論すべき点を明確にするという、優れた仕様書の目的を`spec-superclaude.md`は完璧に満たしています。

圧倒的にSuperClaudeありの方がいいらしい！👏

sinanosinano

でもChatGPT-5(無課金)が言うにはそんなに違いないっぽい。

両方の仕様書を読み比べると、次のような特徴が見えました。

---

### ✅ **Vanilla版 (spec-vanilla.md) の強み**

* **整理されたフォーマット**
  実行フローやガイドラインがきちんとまとまっており、「何を書くべきか」が明確。
* **ユーザーストーリーが具体的**
  料理中の利用シーンが自然に描写されていて、読み手がイメージしやすい。
* **要求仕様が網羅的**
  doneness（焼き加減）やオフライン対応、安全性など、多方面に触れている。
* **テスト観点が強い**
  「曖昧なら \[NEEDS CLARIFICATION] で残す」ルールが徹底されており、仕様としての堅実さがある。

---

### ✅ **SuperClaude版 (spec-superclaude.md) の強み**

* **英語的に自然で読みやすい**
  主語・目的語の関係がはっきりしていて、ステークホルダーがすぐ理解できる。
* **Acceptance Scenariosが実際的**
  例としてステーキやチキンの温度・時間が具体値で出ている（135°F / 140°Fなど）。
  → 実際のユーザー体験が想像しやすい。
* **追加の明確化ポイントを列挙**
  「言語サポート」「対応プラットフォーム」「更新頻度」など、ビジネス判断が必要な論点をリストアップしている。
* **コンテンツ品質チェックが厳密**
  実装詳細を避け、ステークホルダー向けに徹している点で一歩リード。

---

### ⚖️ **比較まとめ**

* **仕様の正確さ・網羅性** → Vanilla版がやや優勢。
* **読みやすさ・実際の利用シーン想像力** → SuperClaude版が優勢。
* **ビジネス判断材料の提示** → SuperClaude版が明確。
* **テスト仕様としての使いやすさ** → Vanilla版がしっかりしている。

---

### 💡 結論

* **開発チームやQA用** → **Vanilla版**の方が出来がいい。
* **経営層やステークホルダー説明用** → **SuperClaude版**の方が出来がいい。

用途に応じて使い分けるのがベストです。

---

どちらか1本に統合するなら、**Vanilla版の骨格 + SuperClaude版のシナリオと明確化リスト**を組み合わせると最強になります。

👉 統合版を私がまとめ直すと便利そうですが、作ってみますか？
sinanosinano

Claudeも絶対SuperClaudeらしい
Chat-GPT5は内部のルーティングでそんなにちゃんと考えない奴が実行されてうまく判断できなかった感じかな？

両方の仕様書を比較すると、**spec-superclaude.md**の方が明らかに優れていると思います。

主な理由：

## spec-superclaude.mdの優位点

**1. より具体的で実用的なユーザーストーリー**
- 「手が汚れている調理中の衛生面」という具体的な課題を明記
- 実際の使用例（「135°F for 1-4 hours depending on thickness」）を含む

**2. より包括的で実践的なエッジケース**
- 騒がしいキッチン環境での音声認識
- 初回使用時の権限設定
- オフライン時の動作

**3. 明確に整理された課題認識**
- 「Areas Requiring Clarification」セクションで未解決事項を10項目に体系化
- 各項目が具体的で開発チームが対応しやすい

**4. より詳細な機能要件**
- 安全性に関する要件（FR-004）
- レスポンス形式の選択肢検討（FR-008）
- プラットフォーム対応の明確化（FR-009）

## spec-vanilla.mdの問題点

- エッジケースが表面的（「uncommon ingredient」程度）
- 曖昧性の指摘が散発的で整理されていない
- ユーザーストーリーが一般的すぎる
- 実装に必要な判断材料が不足

**spec-superclaude.md**は、開発チームが実際に作業を開始する前に必要な検討事項を漏れなく洗い出しており、より実用的で完成度の高い仕様書だと評価します。
sinanosinano

結論：SpecKitとSuperClaudeは併用できる（事実(?)）し、一緒に使ったほうが生成されるSpecの出来が良くなる！（感想）