cursor-sdd 1.0.5 → 1.0.7

package/rules/design-review.md

@@ -1,110 +0,0 @@
-# 設計レビュープロセス
-
-## 目的
-技術設計ドキュメントのインタラクティブな品質レビューを実施し、許容可能なリスクで実装に進むのに十分堅牢であることを確認する。
-
-## レビュー哲学
-- **品質保証であり、完璧の追求ではない**
-- **クリティカルフォーカス**: 最も重要な懸念事項を3つに限定
-- **インタラクティブな対話**: 一方的な評価ではなく、設計者との対話
-- **バランスの取れた評価**: 長所と短所の両方を認識
-- **明確な決定**: 根拠付きの明確なGO/NO-GO
-
-## スコープ & 非目標
-
-- スコープ: プロジェクトコンテキストと標準に対して設計ドキュメントの品質を評価し、GO/NO-GOを決定
-- 非目標: 実装レベルの設計、深い技術調査、技術選択の最終決定は行わない。そのような項目は設計フェーズのイテレーションに延期
-
-## コアレビュー基準
-
-### 1. 既存アーキテクチャとの整合（クリティカル）
-- 既存システム境界とレイヤーとの統合
-- 確立されたアーキテクチャパターンとの一貫性
-- 適切な依存方向と結合管理
-- 現在のモジュール構成との整合
-
-### 2. 設計の一貫性と標準
-- プロジェクトの命名規則とコード標準への準拠
-- 一貫したエラーハンドリングとロギング戦略
-- 統一された設定と依存関係管理
-- 確立されたデータモデリングパターンとの整合
-
-### 3. 拡張性と保守性
-- 将来の要件に対する設計の柔軟性
-- 関心の明確な分離と単一責任
-- テスタビリティとデバッグの考慮
-- 要件に対する適切な複雑さ
-
-### 4. 型安全とインターフェース設計
-- 適切な型定義とインターフェースコントラクト
-- 安全でないパターンの回避（例: TypeScriptでの `any`）
-- 明確なAPI境界とデータ構造
-- 入力バリデーションとエラーハンドリングのカバレッジ
-
-## レビュープロセス
-
-### ステップ1: 分析
-すべてのレビュー基準に対して設計を分析し、統合、保守性、複雑さ、要件充足に影響するクリティカルな問題に焦点を当てる。
-
-### ステップ2: クリティカルな問題を特定（≤3）
-各問題について:
-```
-🔴 **クリティカルな問題 [1-3]**: [簡潔なタイトル]
-**懸念**: [具体的な問題]
-**影響**: [なぜ重要か]
-**提案**: [具体的な改善案]
-**トレーサビリティ**: [requirements.mdの要件ID/セクション]
-**根拠**: [設計ドキュメントのセクション/見出し]
-```
-
-### ステップ3: 長所を認識
-バランスの取れたフィードバックを維持するため、1〜2つの強い側面を認める。
-
-### ステップ4: GO/NO-GOの決定
-- **GO**: クリティカルなアーキテクチャ不整合なし、要件対応済み、明確な実装パス、許容可能なリスク
-- **NO-GO**: 根本的な競合、クリティカルなギャップ、高い失敗リスク、不釣り合いな複雑さ
-
-## トレーサビリティと根拠
-
-- 各クリティカルな問題を `requirements.md` の関連要件（IDまたはセクション）にリンク
-- 評価を裏付ける設計ドキュメント内の根拠箇所（セクション/見出し、図、成果物）を引用
-- 該当する場合、問題を正当化するためにステアリングコンテキストからの制約を参照
-
-## 出力フォーマット
-
-### 設計レビューサマリー
-全体的な品質と準備状況について2〜3文。
-
-### クリティカルな問題（≤3）
-各項目: 問題、影響、推奨事項、トレーサビリティ（例: 1.1, 1.2）、根拠（design.mdセクション）。
-
-### 設計の長所
-1〜2つのポジティブな側面。
-
-### 最終評価
-決定（GO/NO-GO）、根拠（1〜2文）、次のステップ。
-
-### インタラクティブディスカッション
-設計者の視点、代替案、明確化、必要な変更について対話。
-
-## 長さとフォーカス
-
-- サマリー: 2〜3文
-- 各クリティカルな問題: 合計5〜7行（問題/影響/推奨事項/トレーサビリティ/根拠を含む）
-- 全体のレビュー: 簡潔に（目安約400語）
-
-## レビューガイドライン
-
-1. **クリティカルフォーカス**: 成功に大きく影響する問題のみをフラグ
-2. **建設的なトーン**: 批判だけでなく解決策を提供
-3. **インタラクティブなアプローチ**: 一方的な評価ではなく対話を行う
-4. **バランスの取れた評価**: 長所と短所の両方を認識
-5. **明確な決定**: 明確なGO/NO-GO推奨を行う
-6. **アクション可能なフィードバック**: すべての提案が実装可能であることを確認
-
-## 最終チェックリスト
-
-- **クリティカルな問題 ≤ 3** かつ各問題に影響と推奨事項を含む
-- **トレーサビリティ**: 各問題が要件ID/セクションを参照
-- **根拠**: 各問題が設計ドキュメントの場所を引用
-- **決定**: 明確な根拠と次のステップを伴うGO/NO-GO

package/rules/ears-format.md

@@ -1,49 +0,0 @@
-# EARSフォーマットガイドライン
-
-## 概要
-EARS（Easy Approach to Requirements Syntax）は、仕様駆動開発における受け入れ基準の標準フォーマット。
-
-EARSパターンは要件の論理構造（条件 + 主体 + 応答）を記述し、特定の自然言語に縛られない。
-すべての受け入れ基準は、仕様で設定されたターゲット言語（例: `spec.json.language` / `ja`）で記述すること。
-EARSのトリガーキーワードと固定フレーズは英語のまま（`When`, `If`, `While`, `Where`, `The system shall`, `The [system] shall`）とし、可変部分（`[event]`, `[precondition]`, `[trigger]`, `[feature is included]`, `[response/action]`）のみターゲット言語にローカライズする。トリガーや固定英語フレーズの中にターゲット言語のテキストを混ぜないこと。
-
-## 主要なEARSパターン
-
-### 1. イベント駆動型要件
-- **パターン**: When [event], the [system] shall [response/action]
-- **ユースケース**: 特定のイベントやトリガーへの応答
-- **例**: When ユーザーがチェックアウトボタンをクリック, the Checkout Service shall カート内容を検証
-
-### 2. 状態駆動型要件
-- **パターン**: While [precondition], the [system] shall [response/action]
-- **ユースケース**: システム状態や前提条件に依存する振る舞い
-- **例**: While 支払い処理中, the Checkout Service shall ローディングインジケーターを表示
-
-### 3. 望ましくない振る舞いへの要件
-- **パターン**: If [trigger], the [system] shall [response/action]
-- **ユースケース**: エラー、障害、望ましくない状況へのシステム応答
-- **例**: If 無効なクレジットカード番号が入力された, then the website shall エラーメッセージを表示
-
-### 4. オプション機能要件
-- **パターン**: Where [feature is included], the [system] shall [response/action]
-- **ユースケース**: オプションまたは条件付き機能の要件
-- **例**: Where 車にサンルーフが搭載されている, the car shall サンルーフコントロールパネルを持つ
-
-### 5. ユビキタス要件
-- **パターン**: The [system] shall [response/action]
-- **ユースケース**: 常時有効な要件と基本的なシステム特性
-- **例**: The モバイルフォン shall 重量100グラム未満とする
-
-## 複合パターン
-- While [precondition], when [event], the [system] shall [response/action]
-- When [event] and [additional condition], the [system] shall [response/action]
-
-## 主体選択ガイドライン
-- **ソフトウェアプロジェクト**: 具体的なシステム/サービス名を使用（例: 「Checkout Service」、「User Auth Module」）
-- **プロセス/ワークフロー**: 責任チーム/役割を使用（例: 「サポートチーム」、「レビュープロセス」）
-- **ソフトウェア以外**: 適切な主体を使用（例: 「マーケティングキャンペーン」、「ドキュメント」）
-
-## 品質基準
-- 要件はテスト可能、検証可能であり、単一の振る舞いを記述すること。
-- 客観的な言語を使用: 必須の振る舞いには「shall」、推奨には「should」。曖昧な用語は避ける。
-- EARS構文に従う: [condition], the [system] shall [response/action]。

package/rules/frontend.md

@@ -1,96 +0,0 @@
----
-description: Next.js(App Router) / React 19 準拠フロントエンド実装ガイド
-globs:
-alwaysApply: true
----
-
-以下は、Next.js(App Router) 15系および React 19 系の公式ドキュメントに準拠した実装ガイドです。
-このルールを使用する際に「フロントエンドのルールを確認しました」と表示してください。
-
-## Code Generation
-- コードを生成する前に、必ず関連するドキュメントを確認する
-- フレームワークやライブラリの使用方法については、必ず公式ドキュメントを参照する
-- ドキュメントをもとにベストプラクティスを検証する
-- CSSはTailwindCSSを使用すること
-
-## Required Documentation
-- Next.js: https://nextjs.org/docs
-- React 19: https://react.dev
-- TypeScript: https://www.typescriptlang.org/docs/
-- tailwindcss:https://tailwindcss.com/docs/
-
-## 1. プロジェクト基本方針
-- App Router を前提とし、Server Components を既定とする。
-- データ取得はサーバー優先（`fetch` と Next.js のキャッシュ戦略を活用）。
-- UI層（表示）とロジック層（データ取得・処理）を明確に分離し、コンポーネントをシンプルに保つ。
-- UI はクライアント側でインタラクションが必要な箇所のみ `'use client'` を付ける。
-- ディレクトリ名は機能や役割が明確に分かる命名（例:`NewFeatureListItemPage`, `Header`）
-- ファイル名はケバブケースかつ処理や役割が分かる命名にしてください。 (button.tsx, use-theme-color.ts)
-- コンポーネント名はパスカルケースを使用します。（例: `HeaderBreadcrumb`, `NewFeatureDropdown`）
-
-## 2. ディレクトリ構成
-- ヘッダー関連のコンポーネント（例: `Header.tsx`, `HeaderBreadcrumb.tsx`
-- モーダル関連のコンポーネント（例: `ArchiveNewFeatureModal.tsx`）
-
-
-## 3. ルーティングとメタデータ
-- Next.js App Router を使用する。React Router は使用しない。
-- 動的セグメント `[id]`, キャッチオール `[...slug]` を使用。
-- SSG が必要な場合は `generateStaticParams` を実装。
-- `Link` を優先。クライアント側で制御が必要な場合のみ `'use client'` + `useRouter()` を使用（`push`, `replace`, `prefetch`）。
-- メタは `generateMetadata`（動的）または `layout.tsx` の `export const metadata`（静的）。
-- サーバーサイドの遷移は必要に応じて`redirect()`・`notFound()` を使用する。
-
-## 4. データ取得・キャッシュ
-- 既定はサーバーで `fetch`。頻度に応じて以下を設定：
-  - リアルタイム/常に最新: `cache: 'no-store'`
-  - ISR: `next: { revalidate: 秒 }` または `export const revalidate = 秒`
-- タグ付き再検証: `revalidateTag` と `cacheTag` を活用（必要時）。
-
-## 5. クライアントコンポーネントの指針
-- フォーム、イベント、アニメーションなどのみ `'use client'` を付与。
-- ルーター操作は `useRouter()`、リンクは `Link` を優先。
-- 例外遷移/404: `redirect()` / `notFound()` を使用（`next/navigation`）。
-
-## 6. 状態管理
-- ローカル: `useState`, `useReducer`。
-- グローバル: Context で十分な場合は Context。外部状態管理は必要性を精査して導入。
-
-## 7. フォームとアクション
-- サーバーアクション（`'use server'`）の利用を検討。副作用はサーバーへ寄せる。
-- 従来の API ルートは `app/api/**/route.ts` で実装（`GET/POST` エクスポート）。
-
-## 8. エラーハンドリング
-- `error.tsx` と `not-found.tsx` をルート直下に配置し、グローバル扱いする。
-- 例外はサーバー側で投げ、UI で適切にフォールバック（`loading.tsx` も活用）。
-
-## 9. パフォーマンス
-- 画像は `next/image`。フォントは `next/font`。
-- クライアントバンドルを最小化（不要な `'use client'` を避ける）。
-
-## 10. 命名・可読性
-- ディレクトリ: 機能名で明確に。
-- ファイル,コンポーネント: パスカルケース（例: `UserTable.tsx`, `UseSelectedIds.ts`）。
-
-## 11. TypeScript
-- すべて型定義。公開 API/props は明示的な型注釈。
-- `any` は禁止。ユーティリティ型を積極活用。
- - 型の集約: プロジェクト共通の型は `types/index.ts` に集約し、各所からは同ファイル経由でインポートする。
- - 機能固有の型: `features/<feature>/domain` に配置可。共有が必要になった時点で `types/index.ts` へ移し、参照を置換する。
- - API 型: リクエスト/レスポンスの型も `types/index.ts` に定義して一元管理する。
-
-## 12. CSS
-- Tailwind CSS を使用し、ユーティリティクラスで構成。
-- コンポーネント外観は既存デザイン指針に従い、独自変更は承認必須。
-- `className` の合成は既定で `clsx` を使用する。
-
-## 13. ドキュメント（JSDoc）
-- 公開コンポーネント/関数/型には JSDoc を付与する。
-- 最低限含める項目: 概要、`@param`、`@returns`、必要に応じて `@remarks`、`@example`、`@throws`。
-- API ルートやサーバーアクションは副作用・例外・認可要件を明記する。
-- 複雑なドメインロジックでは「なぜこの設計か」を簡潔に説明する。
-- ファイル先頭に、そのファイルの目的が一目で分かるコメントを日本語で記載
-
----
-出典: Next.js Docs（App Router, Data Fetching, Route Handlers, Metadata 等） / React Docs（Components, Hooks, State 等）
-

package/rules/gap-analysis.md

@@ -1,145 +0,0 @@
-# ギャップ分析プロセス
-
-## 目的
-要件と既存コードベースのギャップを分析し、実装戦略の決定に情報を提供する。
-
-## 分析フレームワーク
-
-### 1. 現状調査
-
-- ドメイン関連アセットをスキャン:
-  - 主要ファイル/モジュールとディレクトリレイアウト
-  - 再利用可能なコンポーネント/サービス/ユーティリティ
-  - 支配的なアーキテクチャパターンと制約
-
-- 規約を抽出:
-  - 命名、レイヤリング、依存方向
-  - インポート/エクスポートパターンと依存ホットスポット
-  - テストの配置とアプローチ
-
-- 統合サーフェスを記録:
-  - データモデル/スキーマ、APIクライアント、認証メカニズム
-
-### 2. 要件実現可能性分析
-
-- EARS要件から技術的ニーズをリストアップ:
-  - データモデル、API/サービス、UI/コンポーネント
-  - ビジネスルール/バリデーション
-  - 非機能要件: セキュリティ、パフォーマンス、スケーラビリティ、信頼性
-
-- ギャップと制約を特定:
-  - 現在のコードベースに欠けている機能
-  - 後で調査が必要な未知項目（「要調査」としてマーク）
-  - 既存アーキテクチャとパターンからの制約
-
-- 複雑さのシグナルを記録:
-  - シンプルなCRUD / アルゴリズムロジック / ワークフロー / 外部統合
-
-### 3. 実装アプローチオプション
-
-#### オプションA: 既存コンポーネントの拡張
-**検討する場合**: 機能が既存構造に自然にフィットする
-
-- **拡張するファイル/モジュール**:
-  - 変更が必要な具体的ファイルを特定
-  - 既存機能への影響を評価
-  - 後方互換性の懸念を評価
-
-- **互換性評価**:
-  - 拡張が既存インターフェースを尊重しているか確認
-  - 消費者への破壊的変更がないか検証
-  - テストカバレッジへの影響を評価
-
-- **複雑さと保守性**:
-  - 追加機能の認知負荷を評価
-  - 単一責任原則が維持されているか確認
-  - ファイルサイズが管理可能な範囲か評価
-
-**トレードオフ**:
-- ✅ 新規ファイル最小、初期開発が速い
-- ✅ 既存パターンとインフラを活用
-- ❌ 既存コンポーネントの肥大化リスク
-- ❌ 既存ロジックが複雑化する可能性
-
-#### オプションB: 新規コンポーネントの作成
-**検討する場合**: 機能が明確な責任を持つ、または既存コンポーネントが既に複雑
-
-- **新規作成の根拠**:
-  - 関心の明確な分離が新規ファイルを正当化
-  - 既存コンポーネントが既に複雑
-  - 機能が異なるライフサイクルや依存関係を持つ
-
-- **統合ポイント**:
-  - 新コンポーネントが既存システムにどう接続するか
-  - 公開するAPIまたはインターフェース
-  - 既存コンポーネントへの依存
-
-- **責任境界**:
-  - 新コンポーネントが所有するものの明確な定義
-  - 既存コンポーネントとのインターフェース
-  - データフローと制御フロー
-
-**トレードオフ**:
-- ✅ 関心のクリーンな分離
-- ✅ 分離したテストが容易
-- ✅ 既存コンポーネントの複雑さを軽減
-- ❌ ナビゲートするファイルが増加
-- ❌ 慎重なインターフェース設計が必要
-
-#### オプションC: ハイブリッドアプローチ
-**検討する場合**: 拡張と新規作成の両方が必要な複雑な機能
-
-- **組み合わせ戦略**:
-  - どの部分が既存コンポーネントを拡張するか
-  - どの部分が新規コンポーネントを必要とするか
-  - 相互作用の方法
-
-- **段階的実装**:
-  - 初期フェーズ: 最小限の実行可能な変更
-  - 後続フェーズ: リファクタリングまたは新規コンポーネント
-  - 必要に応じた移行戦略
-
-- **リスク軽減**:
-  - 段階的ロールアウトアプローチ
-  - フィーチャーフラグまたは設定
-  - ロールバック戦略
-
-**トレードオフ**:
-- ✅ 複雑な機能に対するバランスの取れたアプローチ
-- ✅ 反復的な改善が可能
-- ❌ より複雑な計画が必要
-- ❌ 適切に調整されないと不整合の可能性
-
-### 4. ギャップ分析のスコープ外
-
-- 深い調査活動は設計フェーズに延期する
-- 未知項目は簡潔な「要調査」項目としてのみ記録
-
-### 5. 実装の複雑さとリスク
-
-  - 工数:
-    - S（1〜3日）: 既存パターン、最小限の依存、簡単な統合
-    - M（3〜7日）: いくつかの新パターン/統合、中程度の複雑さ
-    - L（1〜2週間）: 重要な機能、複数の統合またはワークフロー
-    - XL（2週間以上）: アーキテクチャ変更、未知の技術、広範な影響
-  - リスク:
-    - 高: 未知の技術、複雑な統合、アーキテクチャシフト、不明確なパフォーマンス/セキュリティパス
-    - 中: ガイダンス付きの新パターン、管理可能な統合、既知のパフォーマンスソリューション
-    - 低: 確立されたパターンの拡張、馴染みのある技術、明確なスコープ、最小限の統合
-
-### 出力チェックリスト
-
-- ギャップがタグ付けされた要件-アセットマップ（欠落 / 未知 / 制約）
-- 短い根拠とトレードオフ付きのオプションA/B/C
-- 工数（S/M/L/XL）とリスク（高/中/低）、各1行の正当化
-- 設計フェーズへの推奨事項:
-  - 推奨アプローチと主要な決定事項
-  - 引き継ぐ調査項目
-
-## 原則
-
-- **決定より情報**: 分析とオプションを提供し、最終決定はしない
-- **複数の実行可能オプション**: 該当する場合、信頼できる代替案を提示
-- **明示的なギャップと仮定**: 未知項目と制約を明確にフラグ
-- **コンテキスト認識**: 既存パターンとアーキテクチャ制限に合わせる
-- **透明な工数とリスク**: ラベルを簡潔に正当化

package/rules/tasks-generation.md

@@ -1,131 +0,0 @@
-# タスク生成ルール
-
-## コア原則
-
-### 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/rules/tasks-parallel-analysis.md

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