name: tri-ssd-orchestrator description: > Tri-SSD（三層スライス仕様駆動）のワークフローを統括する。 AI/LLMコードエージェントを前提とした仕様駆動開発フレームワーク。 三層モデル（L1 ビジョン・要求、L2 技術基盤、L3 機能仕様）を通じて、 要件から実装までのトレーサビリティを確保しながらAIと人間の共同作業を効率化する。 【重要】実装中に得た知見は即座に適切なレイヤーに蓄積する: 問題解決・設計判断→L3、技術情報・ルール→L2、要件変更→L1提案。 使用タイミング: (1) 新規プロジェクトの仕様・要件定義を作成したい、 (2) 既存プロジェクトにTri-SSDを導入したい、 (3) 既存ドキュメントをL1形式に変換したい、 (4) 要件や技術スタックを追加・変更したい、 (5) L1/L2/L3ドキュメントを生成・更新したい、 (6) 仕様からコード・テストを生成したい、 (7) 進捗確認・整合性チェック・レビュー・昇格をしたい、 (8) 実装中の知見をドキュメントに反映したい。 トリガー: 「仕様」「要件定義」「要件追加」「設計」「技術スタック」「技術選定」 「L1」「L2」「L3」「フェーズ」「ルール」「仕様書」「技術基盤」 「コード生成」「整合性チェック」「進捗確認」「Tri-SSD」「導入」「知見」「メモ」。

Tri-SSD (Tri-Layer Slice Spec Driven)

AI/LLMコードエージェント向けの仕様駆動開発フレームワーク。

Instructions

When this skill is invoked:

1. Determine user's current stage in Tri-SSD workflow
2. Check existing docs/ directory structure with Glob
3. Recommend the appropriate next command
4. Execute the command if user agrees

作業中の知見蓄積（常時適用）:

• 問題を解決したら → 即座にL3の実装メモに追記
• 技術的発見があったら → L2（rules.md/foundation.md）への追記を提案
• 要件の曖昧さ・矛盾を発見したら → L1への変更を提案
• 外部サービスの設定情報が判明したら → L2 foundation.mdに追記

Do NOT:

• Skip layers (e.g., generating L3 without L1/L2)
• Generate code without reviewed L3
• Load all Tri-SSD documents at once (context cost)
• 知見を「覚えておく」だけで終わらせる（必ずドキュメントに書く）

三層モデル

L3フォルダ構造

L3ファイルはフェーズごとのサブフォルダに配置:

docs/l3_features/
├── PH-xxx-001_phase-name/
│   ├── F-xxx-001_feature.md
│   └── F-xxx-002_feature.md
└── PH-xxx-002_phase-name/
    └── F-xxx-003_feature.md

利用可能なコマンド

推奨フロー

1. /init-tri-ssd → ディレクトリ作成
2. /draft-l1 → 要件定義
3. /draft-l2 → 技術選定
4. /gen-phases → フェーズ計画
5. /draft-rules → 実装ルール
6. /gen-l3 → 機能仕様
7. /gen-code → 実装
8. /review → 昇格

フェーズ共通原則

• 判断理由を残す: コード例より「なぜそうしたか」を重視
• 知見を即時蓄積: 作業中に得た知見はその場で適切なドキュメントへ追記（昇格時まで待たない）
• 過剰設計を避ける: 今必要なものだけ（YAGNI）

知見の蓄積ルール（重要）

作業中に得た知見は、以下の判断基準で即座に適切なレイヤーへ蓄積する。

蓄積のタイミング

問題発生 → 解決 → 【即座にL3に追記】
技術的発見 → 【即座にL2への追記を提案/実行】
要件の問題発見 → 【即座にL1への変更を提案】

L3 実装メモの構成

## 7. 実装メモ（任意だが推奨）

### 7.1 設計判断理由
- なぜこの設計にしたか

### 7.2 関連コードへのリンク
- 生成したファイルパス

### 7.3 技術的負債/注意点
- 暫定対応、既知の問題、将来の改善点

フェーズ別ガイド

L1: ビジョン・要求

目的: 「何を作るか」を明確にする

• ユーザーの曖昧な要望を具体化する質問を投げる
• 矛盾する要件は早期に指摘して解決
• 技術的実現性は L2 で検討（ここでは制約しない）

L2: 技術基盤

目的: 「どう作るか」の土台を固める

• L1 の要件を満たす技術選定を行い、選定理由を foundation.md に残す
• rules.md は最小限から始める（実装で育てる）
• 「なぜこの技術か」「なぜこの構成か」を説明できる状態にする

L3: 機能仕様

目的: 実装可能な粒度まで詳細化する

• 1機能 = 1ファイルの原則を守る
• 受け入れ条件はテスト可能な形で書く
• 設計判断の理由を残す

実装

目的: L3 に沿ってコードを生成し、知見をドキュメントに蓄積する

• L3 から逸脱しない（勝手な機能追加禁止）
• テストが通るまで完了としない
• 問題解決時は即座にL3に追記（「覚えておく」は禁止）

実装中の知見蓄積フロー

1. 問題発生
   ↓
2. 原因調査・解決
   ↓
3. 【必須】L3 実装メモに追記
   - 何が問題だったか
   - どう解決したか
   - なぜその解決策を選んだか
   ↓
4. 【判断】汎用的な知見か？
   ├─ Yes → L2 rules.md/foundation.md への追記を提案
   └─ No  → L3のみで完結
   ↓
5. 【判断】要件に影響する発見か？
   ├─ Yes → L1 への変更を提案（ユーザー確認）
   └─ No  → 次の作業へ

昇格（/review）

目的: 品質確認とドキュメント反映

• セッション中の知見を整理し、適切なドキュメントへの反映を提案
• 「なぜこのルールが必要か」を含めて提案
• 反映不要なもの（一時的な回避策等）は除外

Examples

新規プロジェクトで仕様を書きたい: → /init-tri-ssd でディレクトリ作成後、/draft-l1 で要件定義から開始

既存プロジェクトにTri-SSDを導入したい: → /init-tri-ssd 後、既存コードを分析して /draft-l1 で要件を逆算

L3機能を実装したい: → まず /check で L3 の doc_status を確認。reviewed なら /gen-code、draft なら /review を先に実行

進捗を確認したい: → /check で全体の整合性と各ドキュメントのステータスを確認

実装中に問題を解決した: → 解決後、即座にL3の実装メモ（7.3 技術的負債/注意点）に追記。汎用的なルールならL2 rules.mdにも追記提案

外部APIの仕様が判明した: → L2 foundation.mdの技術スタックセクションに設定情報を追記

要件の矛盾や曖昧さを発見した: → L1への変更を提案し、ユーザー確認後に更新

Limitations

• Tri-SSD固有のワークフローのみ対応（汎用的なコード生成は対象外）
• L3単位での実装を前提（複数L3の同時実装は非推奨）
• 既存コードの自動分析によるL1/L2生成は不完全（人間のレビュー必須）

現在の状態確認

/check で整合性チェックと進捗確認が可能。