cursor-sdd 1.0.11 → 1.0.14

package/new/rules/tasks-generation.md

@@ -0,0 +1,131 @@
+# タスク生成ルール
+
+## コア原則
+
+### 1. 自然言語による記述
+コード構造ではなく、機能と成果に焦点を当てる。
+
+**記述すべき内容**:
+- 達成すべき機能
+- ビジネスロジックと振る舞い
+- 機能とケイパビリティ
+- ドメイン言語と概念
+- データの関係性とワークフロー
+
+**避けるべき内容**:
+- ファイルパスとディレクトリ構造
+- 関数/メソッド名とシグネチャ
+- 型定義とインターフェース
+- クラス名とAPIコントラクト
+- 具体的なデータ構造
+
+**理由**: 実装詳細（ファイル、メソッド、型）は design.md で定義する。タスクは実行すべき機能的な作業を記述する。
+
+### 2. タスクの統合と進行
+
+**すべてのタスクは必ず**:
+- 前のタスクの出力を基にする（孤立したコードを作らない）
+- システム全体に接続する（宙ぶらりんの機能を作らない）
+- 段階的に進行する（複雑さの大きな飛躍を避ける）
+- シーケンスの早い段階でコア機能を検証する
+- design.md で定義されたアーキテクチャ境界を尊重する（アーキテクチャパターン & 境界マップ）
+- design.md に記載されたインターフェースコントラクトを遵守する
+- メジャータスクのサマリーは控えめに使用し、作業が子タスクで完全にカバーされている場合は詳細項目を省略する
+
+**最後に統合タスク**を配置し、すべてを接続する。
+
+### 3. 柔軟なタスクサイズ
+
+**ガイドライン**:
+- **メジャータスク**: 論理的に必要な数のサブタスク（凝集性でグループ化）
+- **サブタスク**: 各1〜3時間、サブタスクごとに3〜10の詳細
+- 細かすぎず、広すぎないバランス
+
+**任意の数字に合わせない** - 論理的なグループ化で構造を決定する。
+
+### 4. 要件マッピング
+
+**各タスク詳細セクションの末尾に**:
+- `_Requirements: X.X, Y.Y_` として**数値の要件IDのみ**をリスト（カンマ区切り）。説明文、括弧、翻訳、自由形式のラベルは付けない。
+- 横断的な要件については、関連するすべての要件IDをリストする。すべての要件には requirements.md に数値IDが必要。IDがない場合は、タスク生成前に requirements.md を修正する。
+- 必要に応じて design.md のコンポーネント/インターフェースを参照（例: `_Contracts: AuthService API`）
+
+### 5. コードのみにフォーカス
+
+**含めるもの**:
+- コーディングタスク（実装）
+- テストタスク（ユニット、統合、E2E）
+- 技術セットアップタスク（インフラ、設定）
+
+**除外するもの**:
+- デプロイタスク
+- ドキュメントタスク
+- ユーザーテスト
+- マーケティング/ビジネス活動
+
+### オプションのテストカバレッジタスク
+
+- 設計が既に機能カバレッジを保証しており、迅速なMVPデリバリーが優先される場合、純粋なテスト指向のフォローアップ作業（例: ベースラインレンダリング/ユニットテスト）は `- [ ]*` チェックボックス形式を使用して**オプション**としてマークする。
+- オプションマーカーは、サブタスクが詳細項目で requirements.md の受け入れ基準を直接参照している場合のみ適用する。
+- 実装作業や統合上重要な検証をオプションとしてマークしない - `*` はMVP後に再検討できる補助的/延期可能なテストカバレッジに限定する。
+
+## タスク階層ルール
+
+### 最大2レベル
+- **レベル1**: メジャータスク（1, 2, 3, 4...）
+- **レベル2**: サブタスク（1.1, 1.2, 2.1, 2.2...）
+- **より深いネストは不可**（1.1.1 は不可）
+- メジャータスクに実行可能な項目が1つしか含まれない場合、構造を折りたたんでサブタスクをメジャーレベルに昇格させる（例: `1.1` を `1.` に置き換える）
+- メジャータスクが純粋にコンテナとして存在する場合、チェックボックスの説明を簡潔に保ち、詳細項目の重複を避ける - 詳細はサブタスクに記載する。
+
+### 連番
+- メジャータスクは必ず増分: 1, 2, 3, 4, 5...
+- サブタスクはメジャータスクごとにリセット: 1.1, 1.2, 次に 2.1, 2.2...
+- メジャータスク番号を繰り返さない
+
+### 並列分析（デフォルト）
+- 明示的に無効化されない限り（例: `--sequential` フラグ）、並列分析は有効と想定する。
+- **すべて**の条件が満たされた場合に並行実行可能なタスクを特定する:
+  - 他の未完了タスクへのデータ依存がない
+  - ファイルやリソースの競合がない
+  - 他タスクからの事前レビュー/承認が不要
+- 特定された並列タスクがアーキテクチャパターン & 境界マップで定義された別々の境界内で動作することを検証する。
+- design.md のAPI/イベントコントラクトが競合を引き起こす形で重複していないことを確認する。
+- 並列実行可能な各タスクのタスク番号の直後に `(P)` を付ける:
+  - 例: `- [ ] 2.1 (P) バックグラウンドワーカーを構築`
+  - 適切な場合、メジャータスクとサブタスクの両方に適用する。
+- シーケンシャルモードが要求された場合、`(P)` マーカーは完全に省略する。
+- 並列タスクを論理的にグループ化し（可能な限り同じ親の下）、順序に関する注意事項を詳細項目で強調する。
+- タスクが似ているように見えても `(P)` を妨げる依存関係を明示的に記載する。
+
+### チェックボックス形式
+```markdown
+- [ ] 1. メジャータスクの説明
+- [ ] 1.1 サブタスクの説明
+  - 詳細項目1
+  - 詳細項目2
+  - _Requirements: X.X_
+
+- [ ] 1.2 サブタスクの説明
+  - 詳細項目...
+  - _Requirements: Y.Y_
+
+- [ ] 1.3 サブタスクの説明
+  - 詳細項目...
+  - _Requirements: Z.Z, W.W_
+
+- [ ] 2. 次のメジャータスク（1ではない！）
+- [ ] 2.1 サブタスク...
+```
+
+## 要件カバレッジ
+
+**必須チェック**:
+- requirements.md のすべての要件がカバーされている必要がある
+- すべての要件IDとタスクマッピングを相互参照
+- ギャップが見つかった場合: 要件または設計フェーズに戻る
+- 対応するタスクがない要件があってはならない
+
+`N.M` 形式の数値要件IDを使用する。`N` は requirements.md のトップレベル要件番号（例: Requirement 1 → 1.1, 1.2; Requirement 2 → 2.1, 2.2）、`M` はその要件グループ内のローカルインデックス。
+
+意図的に延期した要件は根拠とともに文書化する。

package/new/rules/tasks-parallel-analysis.md

@@ -0,0 +1,34 @@
+# 並列タスク分析ルール
+
+## 目的
+`tasks.md` 生成時に、安全に並列実行できる実装タスクを特定するための一貫した方法を提供する。
+
+## タスクを並列実行可能と判断する条件
+以下の**すべて**が真の場合のみ、タスクを並列実行可能とマークする：
+
+1. **データ依存関係がない**: 未完了タスクへの依存がない
+2. **ファイル・リソース競合がない**: 共有される可変リソースに触れない
+3. **事前レビュー/承認が不要**: 他タスクからのレビューや承認を事前に必要としない
+4. **環境/セットアップ完了済み**: タスクに必要な環境・セットアップが既に満たされているか、タスク自体に含まれている
+
+## マーキング規則
+- 該当するタスクには、数字識別子の直後に `(P)` を付ける
+  - 例: `- [ ] 2.1 (P) メール用バックグラウンドワーカーを構築`
+- 適切な場合、メジャータスクとサブタスクの両方に `(P)` を適用する
+- 逐次実行が要求された場合（例: `--sequential` フラグ）、`(P)` マーカーは完全に省略する
+- チェックボックスの括弧の**外側**に `(P)` を置き、完了状態との混同を避ける
+
+## グループ化と順序のガイドライン
+- 同じテーマの作業に属する場合、並列タスクを同じ親の下にグループ化する
+- 明らかな前提条件や注意事項は詳細項目に記載する（例: 「1.2のスキーママイグレーションが必要」）
+- 2つのタスクが似ているが並列安全でない場合、ブロッキング依存関係を明示的に記載する
+- コンテナのみのメジャータスク（自身の実行可能な詳細項目を持たないもの）に `(P)` をマークするのは避け、サブタスクレベルで並列実行を評価する
+
+## 品質チェックリスト
+タスクに `(P)` をマークする前に、以下を確認する：
+
+- このタスクを同時実行してもマージやデプロイの競合が発生しないことを確認
+- 共有状態の期待値を詳細項目に記載
+- 実装が独立してテスト可能であることを確認
+
+いずれかのチェックが失敗した場合、タスクに `(P)` を**マークせず**、タスク詳細で依存関係を説明する。

package/new/templates/specs/design.md

@@ -0,0 +1,275 @@
+# 設計ドキュメントテンプレート
+
+---
+**目的**: 実装者が異なる場合でも一貫した実装を保証するために、十分な詳細を提供し、解釈のズレを防ぐ。
+
+**アプローチ**:
+- 実装の判断に直接影響する必須セクションを含める
+- 実装エラーの防止に重要でない限り、オプションセクションは省略
+- 機能の複雑さに応じた詳細レベル
+- 長い文章よりも図表やテーブルを使用
+
+**警告**: 1000行に近づくと機能の複雑さが過度であり、設計の簡素化が必要な可能性がある。
+---
+
+セクションの順序は、明確さが向上する場合に変更可能（例：要件トレーサビリティを前方に配置、データモデルをアーキテクチャの近くに移動）。各セクション内では **概要 → スコープ → 決定事項 → 影響/リスク** の流れを維持し、レビュアーが一貫してスキャンできるようにする。
+
+## 概要
+2-3段落以内
+**目的**: この機能は[対象ユーザー]に[具体的な価値]を提供する。
+**ユーザー**: [対象ユーザーグループ]が[特定のワークフロー]でこれを利用する。
+**影響**（該当する場合）: 現在の[システム状態]を[具体的な変更]によって変更する。
+
+### ゴール
+- 主要目標1
+- 主要目標2
+- 成功基準
+
+### 非ゴール
+- 明示的に除外する機能
+- 現在のスコープ外の将来の検討事項
+- 延期する連携ポイント
+
+## アーキテクチャ
+
+> 詳細な調査ノートは`research.md`を参照（背景情報のみ）。レビュアーのために設計ドキュメントを自己完結型に保ち、すべての決定事項と契約をここに記載する。
+> 重要な決定事項はテキストで記述し、図で構造の詳細を伝える—同じ情報を文章で繰り返さない。
+
+### 既存アーキテクチャ分析（該当する場合）
+既存システムを変更する場合：
+- 現在のアーキテクチャパターンと制約
+- 尊重すべき既存のドメイン境界
+- 維持すべき連携ポイント
+- 対処または回避する技術的負債
+
+### アーキテクチャパターン＆境界マップ
+**推奨**: 選択したアーキテクチャパターンとシステム境界を示すMermaid図を含める（複雑な機能では必須、単純な追加ではオプション）
+
+**アーキテクチャ統合**:
+- 選択パターン: [名前と簡潔な理由]
+- ドメイン/機能境界: [競合を避けるための責任分離方法]
+- 維持する既存パターン: [主要パターンのリスト]
+- 新コンポーネントの理由: [各コンポーネントが必要な理由]
+- ステアリング準拠: [維持する原則]
+
+### 技術スタック
+
+| レイヤー | 選択 / バージョン | 機能での役割 | 備考 |
+|---------|-----------------|-------------|------|
+| フロントエンド / CLI | | | |
+| バックエンド / サービス | | | |
+| データ / ストレージ | | | |
+| メッセージング / イベント | | | |
+| インフラ / ランタイム | | | |
+
+> 理由は簡潔に。より深い内容（トレードオフ、ベンチマーク）が必要な場合は、短い要約と参照セクションおよび`research.md`の調査ノートへのポインタを追加。
+
+## システムフロー
+
+非自明なフローを説明するために必要な図のみを提供。純粋なMermaid構文を使用。一般的なパターン：
+- シーケンス（複数パーティのインタラクション）
+- プロセス/状態（分岐ロジックまたはライフサイクル）
+- データ/イベントフロー（パイプライン、非同期メッセージング）
+
+単純なCRUD変更ではこのセクション全体をスキップ。
+> フローレベルの決定（例：ゲート条件、リトライ）は図の後に簡潔に記述し、各ステップを繰り返さない。
+
+## 要件トレーサビリティ
+
+要件が複数のドメインにまたがる複雑な機能やコンプライアンス重視の機能に使用。単純な1:1マッピングはコンポーネント概要テーブルに依存可能。
+
+各要件ID（例：`2.1`）を実現する設計要素にマッピング。
+
+| 要件 | 概要 | コンポーネント | インターフェース | フロー |
+|------|------|--------------|----------------|--------|
+| 1.1 | | | | |
+| 1.2 | | | | |
+
+> 単一のコンポーネントが横断的な関心事なしに単一の要件を満たす場合のみ、このセクションを省略。
+
+## コンポーネントとインターフェース
+
+コンポーネント別の詳細に入る前のクイックリファレンス。
+
+- 概要はテーブルまたはコンパクトなリスト形式。テーブル例：
+  | コンポーネント | ドメイン/レイヤー | 意図 | 要件カバレッジ | 主要な依存関係 (P0/P1) | 契約 |
+  |-|-|-|-|-|-|
+  | ExampleComponent | UI | XYZを表示 | 1, 2 | GameProvider (P0), MapPanel (P1) | Service, State |
+- 新しい境界を導入するコンポーネント（例：ロジックフック、外部連携、永続化）のみが完全な詳細ブロックを必要とする。単純なプレゼンテーションコンポーネントは概要行と短い実装ノートで十分。
+
+ドメインまたはアーキテクチャレイヤーごとに詳細ブロックをグループ化。各詳細コンポーネントについて、要件IDを`2.1, 2.3`としてリスト（「要件」は省略）。複数のUIコンポーネントが同じ契約を共有する場合、コードブロックを重複させずに基本インターフェース/props定義を参照。
+
+### [ドメイン / レイヤー]
+
+#### [コンポーネント名]
+
+| フィールド | 詳細 |
+|----------|------|
+| 意図 | 責任の1行説明 |
+| 要件 | 2.1, 2.3 |
+| オーナー / レビュアー | （オプション） |
+
+**責任と制約**
+- 主な責任
+- ドメイン境界とトランザクションスコープ
+- データ所有権 / 不変条件
+
+**依存関係**
+- インバウンド: コンポーネント/サービス名 — 目的 (重要度)
+- アウトバウンド: コンポーネント/サービス名 — 目的 (重要度)
+- 外部: サービス/ライブラリ — 目的 (重要度)
+
+外部依存関係の調査結果をここに要約。より深い調査（APIシグネチャ、レート制限、移行ノート）は`research.md`に記載。
+
+**契約**: Service [ ] / API [ ] / Event [ ] / Batch [ ] / State [ ]  ← 該当するもののみチェック。
+
+##### サービスインターフェース
+```typescript
+interface [ComponentName]Service {
+  methodName(input: InputType): Result<OutputType, ErrorType>;
+}
+```
+- 事前条件:
+- 事後条件:
+- 不変条件:
+
+##### API契約
+| メソッド | エンドポイント | リクエスト | レスポンス | エラー |
+|---------|--------------|-----------|----------|--------|
+| POST | /api/resource | CreateRequest | Resource | 400, 409, 500 |
+
+##### イベント契約
+- 発行イベント:
+- 購読イベント:
+- 順序 / 配信保証:
+
+##### バッチ / ジョブ契約
+- トリガー:
+- 入力 / 検証:
+- 出力 / 宛先:
+- 冪等性 & 復旧:
+
+##### 状態管理
+- 状態モデル:
+- 永続化 & 一貫性:
+- 並行性戦略:
+
+**実装ノート**
+- 統合:
+- 検証:
+- リスク:
+
+## データモデル
+
+この機能で変更されるデータ環境の部分に焦点を当てる。
+
+### ドメインモデル
+- 集約とトランザクション境界
+- エンティティ、値オブジェクト、ドメインイベント
+- ビジネスルール & 不変条件
+- 複雑な関係のオプションMermaid図
+
+### 論理データモデル
+
+**構造定義**:
+- エンティティ関係とカーディナリティ
+- 属性とその型
+- 自然キーと識別子
+- 参照整合性ルール
+
+**一貫性 & 整合性**:
+- トランザクション境界
+- カスケードルール
+- 時間的側面（バージョニング、監査）
+
+### 物理データモデル
+**含める場合**: 実装で特定のストレージ設計決定が必要な場合
+
+**リレーショナルデータベースの場合**:
+- データ型を含むテーブル定義
+- 主キー/外部キーと制約
+- インデックスとパフォーマンス最適化
+- スケールのためのパーティショニング戦略
+
+**ドキュメントストアの場合**:
+- コレクション構造
+- 埋め込み vs 参照の決定
+- シャーディングキー設計
+- インデックス定義
+
+**イベントストアの場合**:
+- イベントスキーマ定義
+- ストリーム集約戦略
+- スナップショットポリシー
+- プロジェクション定義
+
+**Key-Value/ワイドカラムストアの場合**:
+- キー設計パターン
+- カラムファミリーまたは値構造
+- TTLとコンパクション戦略
+
+### データ契約 & 連携
+
+**APIデータ転送**
+- リクエスト/レスポンススキーマ
+- バリデーションルール
+- シリアライゼーション形式（JSON、Protobufなど）
+
+**イベントスキーマ**
+- 発行イベント構造
+- スキーマバージョニング戦略
+- 後方/前方互換性ルール
+
+**クロスサービスデータ管理**
+- 分散トランザクションパターン（Saga、2PC）
+- データ同期戦略
+- 結果整合性の処理
+
+この機能に関連しないサブセクションはスキップ。
+
+## エラーハンドリング
+
+### エラー戦略
+各エラータイプの具体的なエラーハンドリングパターンと復旧メカニズム。
+
+### エラーカテゴリとレスポンス
+**ユーザーエラー** (4xx): 無効な入力 → フィールドレベル検証; 未認証 → 認証ガイダンス; 未検出 → ナビゲーションヘルプ
+**システムエラー** (5xx): インフラ障害 → グレースフルデグラデーション; タイムアウト → サーキットブレーカー; 枯渇 → レート制限
+**ビジネスロジックエラー** (422): ルール違反 → 条件説明; 状態競合 → 遷移ガイダンス
+
+**プロセスフロー可視化**（複雑なビジネスロジックが存在する場合）:
+複雑なビジネスワークフローを伴うエラーシナリオのみMermaidフローチャートを含める。
+
+### モニタリング
+エラー追跡、ロギング、ヘルスモニタリングの実装。
+
+## テスト戦略
+
+### デフォルトセクション（ドメインに合わせて名前/セクションを調整）
+- ユニットテスト: コア機能/モジュールから3〜5項目（例：認証メソッド、サブスクリプションロジック）
+- 統合テスト: 3〜5のクロスコンポーネントフロー（例：Webhookハンドリング、通知）
+- E2E/UIテスト（該当する場合）: 3〜5の重要なユーザーパス（例：フォーム、ダッシュボード）
+- パフォーマンス/負荷テスト（該当する場合）: 3〜4項目（例：並行性、大量操作）
+
+## オプションセクション（関連する場合に含める）
+
+### セキュリティ考慮事項
+_認証、機密データ、外部連携、またはユーザー権限を扱う機能に使用。この機能に固有の決定のみを記載。ベースラインコントロールはステアリングドキュメントに委ねる。_
+- 脅威モデリング、セキュリティコントロール、コンプライアンス要件
+- 認証・認可パターン
+- データ保護とプライバシーの考慮事項
+
+### パフォーマンス & スケーラビリティ
+_パフォーマンス目標、高負荷、またはスケーリングの懸念がある場合に使用。機能固有の目標やトレードオフのみを記録し、一般的なプラクティスはステアリングドキュメントに依存。_
+- 目標メトリクスと測定戦略
+- スケーリングアプローチ（水平/垂直）
+- キャッシュ戦略と最適化技術
+
+### 移行戦略
+スキーマ/データ移動が必要な場合、移行フェーズを示すMermaidフローチャートを含める。
+- フェーズ分割、ロールバックトリガー、検証チェックポイント
+
+## 参考資料（オプション）
+- メイン本文に情報を残すと可読性が損なわれる場合のみこのセクションを作成（例：非常に長いTypeScript定義、ベンダーオプションマトリックス、網羅的なスキーマテーブル）。意思決定のコンテキストはメインセクションに残し、設計を自己完結型に保つ。
+- 大きなスニペットをインラインで含めず、メインテキストから参考資料へのリンクを張る。
+- 背景調査ノートと比較は引き続き`research.md`に記載するが、その結論はメイン設計に要約する必要がある。

package/new/templates/specs/init.json

@@ -0,0 +1,29 @@
+{
+  "project_name": "{{PROJECT_NAME}}",
+  "feature_name": "{{FEATURE_NAME}}",
+  "feature_key": "{{FEATURE_KEY}}",
+  "feature_path": "{{FEATURE_PATH}}",
+  "mode": "{{INIT_MODE}}",
+  "project_summary": "{{PROJECT_DESCRIPTION}}",
+  "created_at": "{{TIMESTAMP}}",
+  "updated_at": "{{TIMESTAMP}}",
+  "language": "ja",
+  "phase": "initialized",
+  "approvals": {
+    "requirements": {
+      "generated": false,
+      "approved": false
+    },
+    "design": {
+      "generated": false,
+      "approved": false
+    },
+    "tasks": {
+      "generated": false,
+      "approved": false
+    }
+  },
+  "ready_for_implementation": false
+}
+
+

package/new/templates/specs/requirements-init.md

@@ -0,0 +1,8 @@
+# 要件ドキュメント
+
+## プロジェクト説明（入力）
+{{PROJECT_DESCRIPTION}}
+
+## 要件
+<!-- /kiro:spec-requirements フェーズで生成 -->
+

package/new/templates/specs/requirements.md

@@ -0,0 +1,26 @@
+# 要件ドキュメント
+
+## はじめに
+{{INTRODUCTION}}
+
+## 要件
+
+### 要件 1: {{REQUIREMENT_AREA_1}}
+<!-- 要件の見出しには必ず数字のIDを先頭に付ける（例：「要件 1: ...」、「1. 概要」、「2 機能: ...」）。「要件 A」のようなアルファベットIDは許可されていない。 -->
+**目的:** {{ROLE}}として、{{CAPABILITY}}したい。それにより{{BENEFIT}}を得られる。
+
+#### 受け入れ基準
+1. [イベント]が発生した場合、[システム]は[レスポンス/アクション]を行う
+2. [トリガー]の場合、[システム]は[レスポンス/アクション]を行う
+3. [前提条件]の間、[システム]は[レスポンス/アクション]を行う
+4. [機能が含まれる]場合、[システム]は[レスポンス/アクション]を行う
+5. [システム]は[レスポンス/アクション]を行う
+
+### 要件 2: {{REQUIREMENT_AREA_2}}
+**目的:** {{ROLE}}として、{{CAPABILITY}}したい。それにより{{BENEFIT}}を得られる。
+
+#### 受け入れ基準
+1. [イベント]が発生した場合、[システム]は[レスポンス/アクション]を行う
+2. [イベント]かつ[条件]の場合、[システム]は[レスポンス/アクション]を行う
+
+<!-- 追加の要件は同じパターンに従う -->

package/new/templates/specs/research.md

@@ -0,0 +1,61 @@
+# 調査 & 設計決定テンプレート
+
+---
+**目的**: 技術設計に情報を提供する発見結果、アーキテクチャ調査、および根拠を記録する。
+
+**使い方**:
+- 発見フェーズ中に調査活動と結果を記録。
+- `design.md`には詳細すぎる設計決定のトレードオフを文書化。
+- 将来の監査や再利用のための参照と証拠を提供。
+---
+
+## 概要
+- **機能**: `<feature-name>`
+- **発見スコープ**: 新機能 / 拡張 / 単純な追加 / 複雑な連携
+- **主な発見事項**:
+  - 発見1
+  - 発見2
+  - 発見3
+
+## 調査ログ
+注目すべき調査ステップとその結果を文書化。読みやすさのためにトピックごとにグループ化。
+
+### [トピックまたは質問]
+- **コンテキスト**: この調査のきっかけは何か？
+- **参照したソース**: リンク、ドキュメント、APIリファレンス、ベンチマーク
+- **発見事項**: 洞察を要約した簡潔な箇条書き
+- **影響**: これがアーキテクチャ、契約、または実装にどう影響するか
+
+_各主要トピックについてサブセクションを繰り返す。_
+
+## アーキテクチャパターン評価
+検討した候補パターンまたはアプローチをリスト。必要に応じてテーブル形式を使用。
+
+| オプション | 説明 | 強み | リスク / 制限 | 備考 |
+|----------|------|------|--------------|------|
+| ヘキサゴナル | コアドメイン周りのポート & アダプター抽象化 | 明確な境界、テスト可能なコア | アダプターレイヤーの構築が必要 | 既存のステアリング原則Xに合致 |
+
+## 設計決定
+`design.md`に影響を与える主要な決定を記録。重要なトレードオフのある選択に焦点を当てる。
+
+### 決定: `<タイトル>`
+- **コンテキスト**: 決定を促した問題または要件
+- **検討した代替案**:
+  1. オプションA — 短い説明
+  2. オプションB — 短い説明
+- **選択したアプローチ**: 何を選択し、どう機能するか
+- **根拠**: このアプローチが現在のプロジェクトコンテキストに適する理由
+- **トレードオフ**: メリット vs 妥協点
+- **フォローアップ**: 実装またはテスト中に確認すべき事項
+
+_各決定についてサブセクションを繰り返す。_
+
+## リスク & 軽減策
+- リスク1 — 提案する軽減策
+- リスク2 — 提案する軽減策
+- リスク3 — 提案する軽減策
+
+## 参考文献
+正規のリンクと引用を提供（公式ドキュメント、標準、ADR、内部ガイドライン）。
+- [タイトル](https://example.com) — 関連性の簡単なメモ
+- ...

package/new/templates/specs/tasks.md

@@ -0,0 +1,21 @@
+# 実装計画
+
+## タスク形式テンプレート
+
+作業分解に適したパターンを使用：
+
+### メジャータスクのみ
+- [ ] {{NUMBER}}. {{TASK_DESCRIPTION}}{{PARALLEL_MARK}}
+  - {{DETAIL_ITEM_1}} *（必要な場合のみ詳細を含める。タスクが単独で成立する場合は箇条書きを省略。）*
+  - _要件: {{REQUIREMENT_IDS}}_
+
+### メジャー + サブタスク構造
+- [ ] {{MAJOR_NUMBER}}. {{MAJOR_TASK_SUMMARY}}
+- [ ] {{MAJOR_NUMBER}}.{{SUB_NUMBER}} {{SUB_TASK_DESCRIPTION}}{{SUB_PARALLEL_MARK}}
+  - {{DETAIL_ITEM_1}}
+  - {{DETAIL_ITEM_2}}
+  - _要件: {{REQUIREMENT_IDS}}_ *（IDのみ。説明や括弧を追加しない。）*
+
+> **並列マーカー**: 並列実行可能なタスクにのみ` (P)`を付加。`--sequential`モードで実行する場合はマーカーを省略。
+>
+> **オプションのテストカバレッジ**: 受け入れ基準に関連する延期可能なテスト作業のサブタスクの場合、チェックボックスを`- [ ]*`としてマークし、詳細の箇条書きで参照要件を説明。

package/package.json

@@ -1,19 +1,17 @@
 {
   "name": "cursor-sdd",
-  "version": "1.0.11",
+  "version": "1.0.14",
   "description": "Cursor SDD (Spec-Driven Development) - AI-powered spec templates, rules and commands for Cursor IDE",
   "bin": {
-    "cursor-sdd": "./bin/setup.ts"
+    "cursor-sdd": "bin/setup.ts"
   },
   "files": [
     "bin",
-    "templates",
-    "rules",
-    "commands",
+    "new",
     "assign"
   ],
   "scripts": {
-    "postinstall": "tsx bin/setup.ts --auto"
+    "setup": "tsx bin/setup.ts"
   },
   "keywords": [
     "cursor",