@careerchain/stdd 0.1.0

package/assets/.claude/skills/software-architecture/SKILL.md

@@ -0,0 +1,260 @@
+---
+name: software-architecture
+description: |-
+  Clean Architecture・DDD ベースのソフトウェア設計ガイドライン。Library-First アプローチ、命名規則、アンチパターン回避を提供する。
+when_to_use: |-
+  「アーキテクチャ」「設計」「Clean Architecture」「DDD」「ドメイン駆動設計」「リファクタリング」「コード品質」「命名規則」「責務分離」に関する作業のとき。
+allowed-tools: Read, Edit, Grep, Glob
+---
+
+# ソフトウェアアーキテクチャ
+
+Clean ArchitectureとDDD（ドメイン駆動設計）の原則に基づく、対象プロジェクトの設計ガイドライン。
+
+## Domain層の実装パターン
+
+対象プロジェクトのデータフローは以下の4層構造に従う:
+
+```
+DB型（database.types.ts） → Entity型（models/） → Service（service/） → Server Actions（app/*/actions.ts）
+                              ↓
+                         Repository（repository/）
+```
+
+### 1. Entity層（models/）
+
+**型定義とクラスの併用パターン**: 型で構造定義、クラスでビジネスロジックを実装する。
+
+```typescript
+// domain/models/opportunity/index.ts
+
+// 構造定義（Type）
+export type OpportunityEntity = {
+  id: string;
+  title: string;
+  salary_min: number;
+  salary_max: number | null;
+  deleted_at: string | null;
+};
+
+// ロジック実装（Class）
+export class Opportunity {
+  public readonly id: string;
+  public readonly salaryMin: number;
+
+  constructor(entity: OpportunityEntity) {
+    this.id = entity.id;
+    this.salaryMin = entity.salary_min;
+  }
+
+  isHighPay(): boolean {
+    return this.salaryMin >= 1000000;
+  }
+
+  isDeleted(): boolean {
+    return this.deletedAt !== null;
+  }
+
+  // Entity型 → UI型への変換
+  toJob(): Job {
+    return {
+      id: this.id,
+      salary: this.formatSalary(),
+      highPay: this.isHighPay(),
+    };
+  }
+}
+```
+
+**判断基準**: ビジネスルールが含まれる場合はClass、単純なデータ構造ならTypeのみで十分。
+
+### 2. Repository層（repository/）
+
+**Interface + 実装クラスパターン**: テスト時のモック差し替えを可能にする。
+
+```typescript
+// domain/repository/saved-agent/index.ts
+
+export interface ISavedAgentRepository {
+  create(userId: string, agentId: string): Promise<SavedAgent>;
+  findByUserAndAgent(
+    userId: string,
+    agentId: string,
+  ): Promise<SavedAgent | null>;
+  softDeleteByUserAndAgent(
+    userId: string,
+    agentId: string,
+  ): Promise<SavedAgent | null>;
+}
+
+export class SavedAgentRepository implements ISavedAgentRepository {
+  private admin = createSupabaseAdmin();
+
+  async create(userId: string, agentId: string): Promise<SavedAgent> {
+    const { data, error } = await this.admin
+      .from('saved_agents')
+      .insert({ user_id: userId, agent_id: agentId })
+      .select()
+      .single();
+
+    if (error?.code === '23505') {
+      throw new Error('既に保存済みです');
+    }
+    if (error) throw error;
+    return SavedAgent.fromDatabase(data);
+  }
+}
+```
+
+**パフォーマンス最適化の定石**:
+
+| 手法       | 実装例                                                       |
+| ---------- | ------------------------------------------------------------ |
+| N+1回避    | 一括取得後にMapで結合: `new Map(agents.map(a => [a.id, a]))` |
+| 計数最適化 | `.select('*', { count: 'exact', head: true })`               |
+| 並列化     | `Promise.all([countQuery, dataQuery])`                       |
+| 論理削除   | `.is('deleted_at', null)` を常に付与                         |
+
+### 3. Service層（service/）
+
+**Repository間の連携とビジネスロジックの集約場所**。
+
+```typescript
+// domain/service/saved-agent/index.ts
+export class SavedAgentService {
+  private repository: ISavedAgentRepository;
+
+  constructor(repo?: ISavedAgentRepository) {
+    this.repository = repo || new SavedAgentRepository();
+  }
+
+  async toggle(userId: string, agentId: string): Promise<{ isSaved: boolean }> {
+    const existing = await this.repository.findByUserAndAgent(userId, agentId);
+
+    if (existing && !existing.isDeleted()) {
+      await this.repository.softDeleteByUserAndAgent(userId, agentId);
+      return { isSaved: false };
+    }
+
+    if (existing && existing.isDeleted()) {
+      await this.repository.restore(userId, agentId);
+      return { isSaved: true };
+    }
+
+    await this.repository.create(userId, agentId);
+    return { isSaved: true };
+  }
+}
+```
+
+**Service層の役割判断**:
+
+- ビジネスロジックがない場合: Repositoryを直接呼んでもよい（不要な委譲層は作らない）
+- 複数Repositoryの連携が必要な場合: Serviceで集約する
+- 型変換（Entity → UI型）: Entity自身の`toXxx()`メソッド、またはServiceで実装
+
+### 4. Server Actions
+
+**APIルートよりServer Actionsを優先**する。戻り値は `{ success, error?, data? }` 形式で統一。
+
+```typescript
+// app/feature/actions.ts
+'use server';
+
+export async function approveCertification(id: string) {
+  try {
+    const certification = await certificationRepository.getById(id);
+    if (!certification) {
+      return { success: false, error: '証明書が見つかりません' };
+    }
+
+    if (!certification.canApprove()) {
+      return { success: false, error: '承認できない状態です' };
+    }
+
+    const approved = certification.approve();
+    await certificationRepository.update(approved);
+    await sendApprovalNotification(certification.userId);
+
+    return { success: true };
+  } catch (error) {
+    console.error('Approval error:', error);
+    return { success: false, error: '承認処理中にエラーが発生しました' };
+  }
+}
+```
+
+## コードスタイルルール
+
+### 基本原則
+
+- **Early return**: ネストを減らすため、ガード節で早期リターンする
+- **Arrow functions**: function宣言よりアロー関数を優先
+- **関数の長さ**: 50行を超えたら分割を検討
+- **ファイルの長さ**: 200行を超えたら分割を検討
+- **ネストの深さ**: 最大3レベル
+- **コード重複回避**: 再利用可能な関数・モジュールに切り出す
+
+### Library-Firstアプローチ
+
+カスタムコードを書く前に、既存のライブラリ・サービスを検討する。すべてのカスタムコードは保守・テスト・ドキュメントのコストを伴うため、ライブラリで解決できるならそちらを優先する。
+
+**カスタムコードが正当化される場合**:
+
+- ドメイン固有のビジネスロジック
+- パフォーマンスクリティカルな処理
+- 既存ライブラリが要件を満たさない場合
+
+### 命名規則
+
+| 対象              | ルール                             | 例                            |
+| ----------------- | ---------------------------------- | ----------------------------- |
+| Entity型          | `XxxEntity`                        | `UserEntity`, `ProjectEntity` |
+| Repository        | `IXxxRepository` / `XxxRepository` | `IProjectRepository`          |
+| Service           | `XxxService`                       | `OpportunityService`          |
+| Server Action関数 | camelCase + 動詞                   | `createProject`, `updateUser` |
+| ファイル/フォルダ | kebab-case                         | `saved-agent/index.ts`        |
+
+**避けるべき名前**: `utils`, `helpers`, `common`, `shared`, `misc`
+→ ドメイン固有の名前を使う: `SalaryFormatter`, `CertificationValidator`
+
+### アンチパターン
+
+| アンチパターン               | 代わりに                                     |
+| ---------------------------- | -------------------------------------------- |
+| `utils.ts`に雑多な関数を集約 | ドメインごとにモジュール分割                 |
+| Repositoryにビジネスロジック | Service層に分離                              |
+| UIコンポーネント内でDB操作   | Server Actions経由                           |
+| 使用箇所1つで抽象化          | Rule of Three: 3箇所以上で重複してから抽象化 |
+| `as`型キャスト               | 型注釈、`satisfies`、明示的マッピング関数    |
+| `!`非nullアサーション        | `assert()`で明示チェック                     |
+
+> コーディング規約の詳細は `.claude/docs/coding-conventions.md`（存在する場合）を参照
+
+## 設計判断のガイドライン
+
+### サーバーコンポーネント vs クライアントコンポーネント
+
+| 基準             | サーバーコンポーネント | クライアントコンポーネント   |
+| ---------------- | ---------------------- | ---------------------------- |
+| データ取得       | DB直接アクセス可能     | Server Actions経由           |
+| インタラクション | なし                   | フォーム、モーダル、状態管理 |
+| SEO              | 対応                   | 非対応                       |
+
+**原則**: デフォルトはサーバーコンポーネント。`'use client'`はインタラクションが必要な場合のみ。
+
+### 責務の配置判断
+
+```
+Q1. 単純なCRUD操作？ → Repository
+Q2. 複数Entity間のロジック？ → Service
+Q3. Entity自身の状態チェック/変換？ → Entity（Model）のメソッド
+Q4. UI操作のエントリーポイント？ → Server Action
+Q5. 表示のための計算/整形？ → コンポーネント or Entity.toXxx()
+```
+
+## When NOT to Use This Skill
+
+- **UI実装のみ**: `implementing-ui` skillを使用
+- **DBマイグレーション**: `migrating-supabase` skillを使用
+- **テスト作成**: `e2e-testing` skillを使用

package/assets/.claude/skills/starting-new-with-stdd/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: starting-new-with-stdd
+description: |-
+  新規（コードがまだ無い）プロジェクトを STDD で立ち上げる作業を、Claude セッションで段階的に駆動する。立ち上げガイドに従い、アプリ骨組み生成→common ティアの前方設計→最初の feature→フォーマット策定→feature ループ→通常運用への移行までを、既存スキル（documenting-specifications / generating-wireframes / tailoring-spec-format / documenting-plans / auto-implement / verifying-consistency）を順に呼びながら進める。進捗は立ち上げPLANで保持し、セッションを跨いで再開できる。既に稼働しているコードへの導入は introducing-stdd を使う。
+when_to_use: |-
+  新規（コードがまだ無い）プロジェクトの立ち上げを進める／再開するとき。「新規プロジェクトをstddで立ち上げる」「立ち上げの続き」「greenfield stdd」など、新規フローと確定している場合。新規/既存が未確定の最初の入口は setup-stdd（ルーター）が判定して本スキルへ委譲する。
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+---
+
+# STDD 立ち上げドライバー（新規プロジェクト）
+
+新規プロジェクトの STDD 立ち上げを、セッションで 1 ステップずつ進めるための**薄い駆動役**。
+自前の実装ロジックは持たず、各ステップで**既存スキルを順に呼び**、人間判断ポイントで停止し、進捗を**立ち上げPLAN**に記録する。
+
+> 「なぜ」「各ステップで何を判断するか」は [`guide-for-new-project.md`](../../../packages/core/docs/guide-for-new-project.md) を参照。
+> 本スキルはその operational な実行役。既存（稼働中）プロジェクトへの導入は [`introducing-stdd`](../introducing-stdd/SKILL.md)。
+
+## 設計方針（重要）
+
+- **agent オーケストレーションはしない**。Claude がメインセッションで手順を進める軽量ドライバー。
+- 立ち上げは判断主体のため、**人間を常にループに入れる**（アーキ判断・フォーマット策定・粒度は必ず確認）。
+- 状態は立ち上げPLAN（`docs/common/plans/stdd-bootstrap.md`）にのみ持つ。本スキルはステートレス。
+- 新規は**最初から順行**（Spec → Test → 実装）。`reverse-engineering-*`（遡行）は使わない。
+
+---
+
+## 起動時の動作
+
+### 1. 立ち上げPLAN の有無を確認
+
+```
+docs/common/plans/stdd-bootstrap.md
+```
+
+- **無い場合 → 初回**: 下記「初回フロー」を実行し、立ち上げPLAN を作成する。
+- **ある場合 → 再開**: 立ち上げPLAN を読み、最初の未チェック項目（`- [ ]`）を「次にやること」として提示し、該当ステップを実行する。
+
+### 2. 設定確認
+
+`.stdd.config.yml` を読み、`apps[]` / `commands` / `docs.layout`（`common_requirements` / `common_architecture` 含む）を把握する。
+`npx @careerchain/stdd init` で導入済みなら揃っている。無ければ step 0 を案内する。
+
+---
+
+## ステップ実行表
+
+各ステップは「呼ぶスキル」と「停止して人間に確認すること」を持つ。
+
+| step | 実行内容 | 呼ぶスキル | ★停止して確認 |
+| ---- | -------- | ---------- | ------------- |
+| 0 | scaffold / `.stdd.config.yml` 点検（common ティア前提） | — | 構成（単一/複数アプリ・パス規約） |
+| 1 | **アプリ骨組みを対話駆動**（stack 固有） | （stack 手順へ委譲。下記「step 1」詳細） | ★ 構成・コマンド疎通 |
+| 2 | **common ティアを前方設計**（docs/common を埋める） | `documenting-specifications` | ★ 目的・アクター・初期アーキ |
+| 3 | 最初の feature を順行 spec 化（P0 コアから 1 本） | `documenting-specifications` → `generating-wireframes` | ★ Spec 粒度・スコープ |
+| 4 | フォーマット策定 → テンプレ特化 | `tailoring-spec-format` | ★★ フォーマット決定 |
+| 5 | feature を順行 STDD でループ | `documenting-plans` → `auto-implement` | ★ 機能ごとの粒度 |
+| 6 | 通常運用へ移行 | `auto-implement`（以降） | 立ち上げ完了の確認 |
+
+各 feature 実装後は `verifying-consistency` で spec ⇔ test ⇔ 実装 の整合を確認する。
+
+---
+
+## 初回フロー（立ち上げPLAN が無いとき）
+
+1. **scaffold 確認**: `npx @careerchain/stdd init` の導入物（`.stdd.config.yml`・`.claude/`・`docs/`）が揃っているか点検。未導入なら `npx @careerchain/stdd init` を案内。
+2. **step 1（アプリ骨組み）**: 下記「step 1」手順で stack 固有の骨組み生成を対話駆動。
+3. **step 2（★人間判断）**: `documenting-specifications` で `docs/common/REQUIREMENTS.md` + `ARCHITECTURE.md` を**前方設計**（仮説として埋める）。
+4. **step 3（★人間判断）**: P0 コア機能を 1 つ選び、順行で feature spec を作る。
+5. **立ち上げPLAN 生成**: `templates/bootstrap-plan.md` を雛形に `docs/common/plans/stdd-bootstrap.md` を作成し、想定 feature を優先順で並べる。
+6. 「次は step 4（フォーマット策定）」を提示して停止。
+
+---
+
+## 再開フロー（立ち上げPLAN があるとき）
+
+1. 立ち上げPLAN を読み、完了済み（`- [x]`）と未着手（`- [ ]`）を把握。
+2. 最初の未着手項目を「次にやること」として 1 つ提示。
+3. ユーザーの了承後、該当ステップのスキルを呼んで実行。
+4. 完了したら立ち上げPLAN の該当項目を `- [x]` に更新し、フォーマット決定があれば「決定ログ」に追記。
+5. 次の未着手を提示して停止（**一度に 1 ステップ**。バッチ全自動にしない）。
+
+---
+
+## step 1: アプリ骨組みの対話駆動（詳細）
+
+新規はアプリ本体がまだ無いので、stack 固有の骨組み（フレームワーク・DB・E2E）を立てる。
+**本スキルは stack 非依存**なので、コマンドの実体は持たず、使用中の stack 手順を SSoT として参照・実行支援する。
+
+### 1-1. stack の特定
+
+`.stdd.config.yml` の `plugins` / `apps[].framework` を読み、骨組み手順の所在を決める。
+
+```
+□ plugins に "nextjs-supabase" / "playwright" → nextjs+supabase+playwright スターター手順
+   （生成元テンプレートの README「次の手順」が SSoT）
+□ それ以外 / 不明 → ユーザーに stack と骨組み手順を確認
+```
+
+### 1-2. 骨組み生成を対話駆動
+
+該当手順のコマンド（例: `create-next-app` / `supabase init` / Playwright 導入）を**1つずつ提示し、ユーザーの確認のもと実行**する。具体コマンドは本スキルに書かず、参照先（テンプレート README / プラグイン guide）の記述に従う。
+
+### 1-3. 設定の実体合わせ（★確認）
+
+```
+□ apps[].path / apps[].port が実体と一致
+□ commands.test / typecheck / build / db_* が実際に動く
+```
+
+> 骨組みが既に用意されている場合は step 1 を飛ばして step 2 へ。
+
+---
+
+## 守ること
+
+- **一度に 1 ステップ**。複数 feature を無確認で連続処理しない。
+- **★ポイントでは必ず停止**してユーザーに聞く（アーキ判断・粒度・フォーマット）。
+- common ティアは**前方設計＝仮説**。作り込みすぎず、feature 開発で検証して更新する。確定しない箇所は `<!-- 未決: ... -->` で残す。
+- 立ち上げPLAN 以外に進捗・履歴を持たない（SSOT 原則。spec 本体に「今回」「変更前」等を書かない）。
+- 遡行スキル（`reverse-engineering-*`）は使わない（新規にはコードが無い）。
+
+---
+
+## When NOT to Use This Skill
+
+- **既に稼働しているコード**への STDD 導入: `introducing-stdd` を使う
+- **単一機能の spec を書く / 実装する**だけ: `documenting-specifications` / `auto-implement` を直接使う
+- **フォーマット策定だけ**やり直したい: `tailoring-spec-format` を直接使う
+
+---
+
+## 参照ファイル
+
+- **立ち上げガイド（なぜ/判断基準）**: [guide-for-new-project.md](../../../packages/core/docs/guide-for-new-project.md)
+- **立ち上げPLAN テンプレート**: [templates/bootstrap-plan.md](templates/bootstrap-plan.md)
+- **common / feature spec 作成**: [documenting-specifications skill](../documenting-specifications/SKILL.md)
+- **ワイヤーフレーム**: [generating-wireframes skill](../generating-wireframes/SKILL.md)
+- **フォーマット策定・テーラリング**: [tailoring-spec-format skill](../tailoring-spec-format/SKILL.md)
+- **PLAN 作成**: [documenting-plans skill](../documenting-plans/SKILL.md)
+- **順行実装**: [auto-implement skill](../auto-implement/SKILL.md)
+- **整合性チェック**: [verifying-consistency skill](../verifying-consistency/SKILL.md)
+- **既存プロジェクトへの導入**: [introducing-stdd skill](../introducing-stdd/SKILL.md)

package/assets/.claude/skills/starting-new-with-stdd/templates/bootstrap-plan.md

@@ -0,0 +1,73 @@
+<!--
+立ち上げPLAN — STDD 新規立ち上げの進捗を保持するプロジェクト単位の生きたチェックリスト。
+
+位置づけ:
+  - feature/session 単位の通常 PLAN とは別。プロジェクト全体の「立ち上げ」進捗を 1 ファイルで追跡する。
+  - starting-new-with-stdd スキルがこのファイルを読み書きしながら立ち上げを駆動する。
+  - 立ち上げが一巡（通常運用へ移行）したら役目を終える。
+  - 既存プロジェクト導入の導入PLAN（stdd-introduction.md）とは排他（新規 or 既存のどちらか）。
+
+配置:
+  docs/common/plans/stdd-bootstrap.md
+
+書き換え方:
+  プレースホルダを実値に置換。feature は想定機能を優先順（P0→P1→P2）で並べる。
+  完了した項目は [ ] → [x] にする。フォーマット決定は「決定ログ」に追記する。
+-->
+
+# STDD 立ち上げPLAN — [サービス名]
+
+> 進捗トラッカー。詳細手順は `starting-new-with-stdd` スキル / `guide-for-new-project.md` を参照。
+> **開始**: [yyyy-mm-dd] / **基準ブランチ**: [main / develop 等]
+
+---
+
+## 進捗
+
+### 基盤
+
+- [ ] step 0: `.stdd.config.yml` 点検（common ティア前提）
+- [ ] step 1: アプリ骨組み生成（stack 固有。`apps[].path` / `commands.*` 疎通確認）
+- [ ] step 2: common ティアを前方設計（`docs/common/REQUIREMENTS.md` + `ARCHITECTURE.md`。仮説）
+- [ ] step 3: 最初の feature を順行 spec 化（[機能名]）
+- [ ] step 4: フォーマット策定 → テンプレ特化（下記「決定ログ」へ）
+
+### feature ループ（step 5）
+
+優先順（P0 → P1 → P2）。各 feature = `documenting-plans` → `auto-implement` → `verifying-consistency`。
+
+- [ ] [機能A]  (P0)
+- [ ] [機能B]  (P0)
+- [ ] [機能C]  (P1)
+- [ ] [機能D]  (P2)
+
+### 移行
+
+- [ ] step 6: feature が回り始めた → 以降は `auto-implement`（通常運用）へ
+
+---
+
+## フォーマット決定ログ（step 4 / 運用中のブラッシュアップ）
+
+このプロジェクト固有に決めた spec フォーマットの方針を記録する。
+
+- 必須 spec ファイル: [REQUIREMENTS / TECH_DESIGN / ...]
+- common ARCHITECTURE に追加した固有セクション: [認証・認可 / RLS / ...]
+- docs.layout パス規約: [docs/<app>/<feature>/...]
+- Priority 基準: [このプロジェクトでの P0/P1/P2 の定義]
+- テスト層の責務分担: [E2E は P0 のみ 等]
+
+---
+
+## 前方設計の未決事項（common ティア）
+
+前方設計で仮置きした・確定していない事項。feature 開発で検証して埋める。
+
+- [ ] [未決事項1]
+- [ ] [未決事項2]
+
+---
+
+## メモ・引き継ぎ
+
+- (セッションを跨ぐ際の注意点・保留事項)

package/assets/.claude/skills/tailoring-spec-format/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: tailoring-spec-format
+description: |-
+  このプロジェクト固有の spec フォーマット / ラインナップを策定し、テンプレートや設定へ反映する。STDD 導入（既存）・立ち上げ（新規）の初期フォーマット策定と、運用中のブラッシュアップの両方を担う。common spec と最初の feature spec を素材に、必須/任意の spec ファイル構成・固有セクション・docs.layout・Priority 基準・テスト層責務・命名を決め、決定を導入PLAN / 立ち上げPLANに記録してテンプレ/設定へ反映する。個別機能の spec 作成は documenting-specifications を使う。
+when_to_use: |-
+  「specフォーマット策定」「テンプレ特化」「テーラリング」「spec構成を決める」「specフォーマットのブラッシュアップ」「STDDをプロジェクトに合わせる」に関する作業のとき。
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+---
+
+# spec フォーマットのテーラリング
+
+STDD のテンプレートを**このプロジェクト固有**に仕立て直す（テーラリング）。
+STDD 導入（既存プロジェクト, step 3-4）・立ち上げ（新規プロジェクト, step 4）の **初期フォーマット策定** と、運用中の **ブラッシュアップ**（step 7）を担う。
+
+> 導入/立ち上げフロー全体は [`guide-for-existing-project.md`](../../../packages/core/docs/guide-for-existing-project.md) / [`guide-for-new-project.md`](../../../packages/core/docs/guide-for-new-project.md)、
+> 駆動役は [`introducing-stdd`](../introducing-stdd/SKILL.md)（既存）/ [`starting-new-with-stdd`](../starting-new-with-stdd/SKILL.md)（新規）を参照。本スキルは単体でも呼べる。
+
+## 設計方針（重要）
+
+- **フォーマットの決定そのものは人間**（ビジネス・チーム判断）。本スキルはそれを**促し・記録し・反映する**手続きに徹する。
+- **agent オーケストレーションはしない**。Claude がメインセッションで決定ポイントを 1 つずつ提示し、人間に決めてもらう。
+- 決定は **導入PLAN / 立ち上げPLAN の「フォーマット決定ログ」** に集約（SSOT）。spec 本体に経緯・履歴を書かない。
+
+## 前提（素材）
+
+- **初期**: `docs/common/`（common spec）と最初の feature spec 1 つが既にある（既存導入なら reverse、新規立ち上げなら順行で作成）。
+- **ブラッシュアップ**: 既に複数の feature spec が運用されている。
+
+---
+
+## 手順
+
+### 1. 素材レビュー
+
+現状を把握する。
+
+```
+□ docs/common/REQUIREMENTS.md / ARCHITECTURE.md（common ティアの構成）
+□ 代表 feature spec（REQUIREMENTS.md / TECH_DESIGN.md）の実物
+□ 現在の .stdd.config.yml（docs.layout / apps / commands）
+□ 利用中のテンプレ（packages/core/templates/ または プロジェクト側コピー）
+□ (step 7 のみ) 運用中の全 feature spec のばらつき・過不足
+```
+
+### 2. 決定ポイントを 1 つずつ提示（★人間が決める）
+
+各項目について **現状 → 選択肢 → 推奨** を提示し、ユーザーに決めてもらう。一度に押し付けない。
+
+| 決定ポイント | 論点 | 反映先 |
+| ------------ | ---- | ------ |
+| **spec ファイル構成** | 必須/任意（REQUIREMENTS / TECH_DESIGN / SCREEN_ITEMS_DEFINITION / wireframes）をどう組むか | プロジェクトのテンプレ・運用ルール |
+| **common 固有セクション** | common ARCHITECTURE に足す横断トピック（認証・認可 / RLS・権限 / 通知 / 監査ログ 等） | `docs/common/ARCHITECTURE.md` |
+| **docs.layout パス規約** | 単一/複数アプリ、`feature_path` の切り方、common の置き場 | `.stdd.config.yml` の `docs.layout` |
+| **Priority 基準** | このプロジェクトでの P0/P1/P2 の具体定義（何を Critical とするか） | テンプレ注記 + 決定ログ |
+| **テスト層の責務分担** | E2E/Integration/Unit の線引き（既存テスト資産に合わせる） | TECH_DESIGN テンプレのテスト戦略節 |
+| **命名・用語** | プロジェクト固有語彙（アクター名・ドメイン用語）、テンプレのプレースホルダ実値化 | テンプレ・common spec |
+
+### 3. 決定を記録
+
+`docs/common/plans/` の PLAN（既存導入: `stdd-introduction.md` / 新規立ち上げ: `stdd-bootstrap.md`）の **「フォーマット決定ログ」** に各決定を追記する。
+PLAN が無い文脈（ブラッシュアップ単体実行など）では、プロジェクトの spec 規約ドキュメント（例: `docs/common/SPEC_CONVENTIONS.md`）に記録してよい。
+
+### 4. テンプレ・設定へ反映（機械的）
+
+決定に従って、**プロジェクト側**の成果物を更新する（STDD core の `packages/core/templates/` 本体は壊さない）。
+
+```
+□ .stdd.config.yml の docs.layout を更新（必要なら common_* を追加/変更）
+□ docs/common/ARCHITECTURE.md に固有セクションを追加
+□ プロジェクト側テンプレ（コピーを持つ場合）の不要セクション削除 / 固有セクション追加 / プレースホルダ実値化
+□ プロジェクト側テンプレを持たない場合は、決定ログに「次に作る feature spec へ適用する方針」として明記
+```
+
+### 5. （step 7 のみ）既存 spec への影響を洗い出す
+
+フォーマットを変えた場合、運用中の feature spec に差分が出る。影響範囲を一覧化してユーザーに提示し、修正は別タスク（必要なら PLAN を切る）として扱う。一括自動修正はしない。
+
+---
+
+## 守ること
+
+- **決定は人間**。skill は選択肢提示・記録・反映に徹する。
+- 一度に全項目を片付けず、**決定ポイントごとに合意**を取る。
+- **STDD core テンプレ（`packages/core/templates/`）を直接編集しない**。反映先はプロジェクト側。
+- 決定は決定ログに集約し、spec 本体に経緯・「変更前/後」を書かない（SSOT）。
+
+---
+
+## When NOT to Use This Skill
+
+- **個別機能の spec を書く**: `documenting-specifications` を使う
+- **既存実装から spec を起こす**: `reverse-engineering-feature-spec` / `reverse-engineering-common-spec` を使う
+- **導入フロー全体を進める**: `introducing-stdd`（本スキルを step 3-4 / 7 で呼ぶ）
+
+---
+
+## 参照ファイル
+
+- **導入ガイド（なぜ/判断基準）**: [guide-for-existing-project.md](../../../packages/core/docs/guide-for-existing-project.md) §step 3-4
+- **導入ドライバー**: [introducing-stdd skill](../introducing-stdd/SKILL.md)
+- **spec テンプレ**: `packages/core/templates/`（feature） / `packages/core/templates/common/`（common）
+- **spec 作成スキル**: [documenting-specifications skill](../documenting-specifications/SKILL.md)
+- **設定スキーマ**: `packages/core/schema/.stdd.config.schema.json`

package/assets/.claude/skills/verifying-consistency/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: verifying-consistency
+description: |-
+  Spec（REQUIREMENTS.md / TECH_DESIGN.md）⇔ テスト ⇔ 実装 の整合性を機能単位でチェックする。ブランチ分岐点からの差分を抽出し、要件・設計・テスト・実装の不整合（機能漏れ、テスト漏れ、設計と実装の乖離など）を検出する。
+when_to_use: |-
+  「整合性チェック」「verify consistency」「Spec準拠確認」「テスト漏れ確認」「STDD整合性」「要件と実装の乖離」「Specと実装の差分」など、STDD に基づく品質確認の依頼があったとき。
+allowed-tools: Read, Grep, Glob, Bash
+---
+
+# Spec・テスト・実装の整合性チェック
+
+このセッション/ブランチで作成・修正した機能について、Spec・テスト・実装の整合性を確認する。
+
+## 1. 対象ファイルの特定
+
+### ブランチ分岐点からの差分を特定
+
+`.stdd.config.yml` の `project.primary_branch`（PR/統合先ブランチ）を読み、その分岐点からの差分を特定する。
+
+```bash
+# <primary_branch> は .stdd.config.yml の project.primary_branch（例: main / develop）
+git fetch origin <primary_branch>
+git log --oneline origin/<primary_branch>...HEAD
+git diff origin/<primary_branch>...HEAD --name-only
+```
+
+以下を特定:
+
+- **Specドキュメント**: `docs/` 配下の `REQUIREMENTS.md`, `TECH_DESIGN.md`
+- **テスト**: `*.test.ts`, `*.test.tsx`, `e2e/tests/**/*.spec.ts`
+- **実装**: `app/`, `components/`, `lib/`, `actions/`, `domain/` 配下のファイル
+
+## 2. 整合性チェック項目
+
+### A. REQUIREMENTS.md ⇔ 実装
+
+- [ ] REQUIREMENTS.md の User Journey が実装で網羅されているか
+- [ ] REQUIREMENTS.md の画面仕様（ボタン、フォーム、表示項目）が実装と一致しているか
+- [ ] REQUIREMENTS.md に記載された機能要件が全て実装されているか
+
+### B. TECH_DESIGN.md ⇔ 実装
+
+- [ ] TECH_DESIGN.md の「Technical Implementation」セクションの設計方針に従っているか
+- [ ] TECH_DESIGN.md の「Decision」セクションの決定事項が実装に反映されているか
+- [ ] TECH_DESIGN.md に記載されたファイル構成と実際のファイル構成が一致しているか
+
+### C. TECH_DESIGN.md ⇔ テスト
+
+- [ ] TECH_DESIGN.md に記載されたテスト総数と、実際のテストケース数が一致しているか
+- [ ] TECH_DESIGN.md の「Test Strategy」セクションに記載された全テストケースが実装されているか
+- [ ] 実装されたテストで、TECH_DESIGN.md に記載されていないものがないか
+
+### D. テスト ⇔ 実装
+
+- [ ] テストが実装を正しく検証しているか（実装の変更でテストが壊れていないか）
+- [ ] テストのモック設定が実装の実際の動作と一致しているか
+
+## 3. 出力形式
+
+以下の形式で結果を報告:
+
+```
+## 整合性チェック結果
+
+### 対象機能: [機能名]
+
+### チェック結果サマリ
+| 項目 | 状態 | 備考 |
+|------|------|------|
+| REQUIREMENTS.md ⇔ 実装 | OK / WARN / NG | |
+| TECH_DESIGN.md ⇔ 実装 | OK / WARN / NG | |
+| TECH_DESIGN.md ⇔ テスト | OK / WARN / NG | |
+| テスト ⇔ 実装 | OK / WARN / NG | |
+
+### 検出された不整合
+1. [不整合の内容]
+   - 期待: [Specの記載内容]
+   - 実際: [テスト/実装の内容]
+   - 推奨アクション: [修正方法]
+
+### 推奨事項
+- [改善提案があれば記載]
+```
+
+## 4. 注意事項
+
+- Specドキュメントが存在しない場合は、その旨を報告
+- 軽微な不整合（コメントの差異など）は WARN として報告
+- 重大な不整合（機能の欠落、テスト漏れなど）は NG として報告
+- 不整合が見つかった場合、修正の優先度も提示