cursor-sdd 1.0.0 → 1.0.1

package/README.md

@@ -84,3 +84,4 @@ Cursor IDE で以下のコマンドが使えるようになります：
 
 MIT
 
+# cursor-sdd-package

package/commands/design.md

@@ -27,6 +27,8 @@ argument-hint: <feature-name:$1> [-y:$2]
 - `.cursor/templates/specs/design.md` からドキュメント構造
 - `.cursor/rules/design-principles.md` から設計原則
 - `.cursor/templates/specs/research.md` から発見ログ構造
+- **`package.json`（プロジェクトルートに存在する場合）**: 既存の依存関係とバージョンを把握
+- `.cursor/rules/frontend.md`（存在する場合）からフロントエンド設計原則
 
 **要件承認の検証**:
 - `-y` フラグが提供された場合（$2 == "-y"）: spec.json で要件を自動承認
@@ -42,7 +44,13 @@ argument-hint: <feature-name:$1> [-y:$2]
    - **シンプルな追加**（CRUD/UI）→ 最小限または発見なし
    - **複雑な統合** → 包括的な分析が必要
 
-2. **適切な発見プロセスの実行**:
+2. **既存パッケージの優先確認**（package.json が存在する場合）:
+   - **優先原則**: 既にインストール済みのパッケージで要件を満たせる場合は、新規追加より既存を活用
+   - dependencies / devDependencies を確認し、使用可能なライブラリをリストアップ
+   - 既存パッケージのバージョンと互換性を検証
+   - 不足している機能がある場合のみ、追加パッケージを検討
+
+3. **適切な発見プロセスの実行**:
    
    **複雑/新機能の場合**:
    - `.cursor/rules/design-discovery-full.md` を読み込んで実行
@@ -60,7 +68,7 @@ argument-hint: <feature-name:$1> [-y:$2]
    **シンプルな追加の場合**:
    - 正式な発見をスキップ、クイックパターンチェックのみ
 
-3. **発見結果をステップ3用に保持**:
+4. **発見結果をステップ3用に保持**:
    - 外部APIの契約と制約
    - 根拠を伴う技術的決定
    - 従うまたは拡張する既存パターン
@@ -68,8 +76,12 @@ argument-hint: <feature-name:$1> [-y:$2]
    - 特定されたリスクと緩和戦略
    - 潜在的なアーキテクチャパターンと境界オプション（詳細を `research.md` に記録）
    - 将来のタスク用の並列化考慮事項（依存関係を `research.md` にキャプチャ）
+   - **パッケージ選定結果**:
+     - 既存パッケージの活用リスト（package.json から）
+     - 追加推奨パッケージ（理由・用途を明記）
+     - 不要または代替可能な既存パッケージ（あれば）
 
-4. **発見結果をリサーチログに永続化**:
+5. **発見結果をリサーチログに永続化**:
    - 共有テンプレートを使用して `.cursor/$1/research.md` を作成または更新
    - 発見スコープと主要な発見をサマリーセクションに記録
    - リサーチログトピックに調査、ソース、影響を記録
@@ -127,7 +139,10 @@ spec.json で指定された言語で簡潔なサマリーを提供:
 1. **ステータス**: `.cursor/$1/design.md` に設計ドキュメント生成完了を確認
 2. **発見タイプ**: どの発見プロセスが実行されたか（full/light/minimal）
 3. **主要な発見**: 設計を形作った2-3の重要な洞察
-4. **次のアクション**: 承認ワークフローのガイダンス（安全性とフォールバック参照）
+4. **パッケージ選定サマリー**:
+   - 既存パッケージで活用するもの
+   - 追加推奨パッケージ（あれば理由と共に）
+5. **次のアクション**: 承認ワークフローのガイダンス（安全性とフォールバック参照）
 
 **フォーマット**: 簡潔なMarkdown（200語以内）- これはコマンド出力であり、設計ドキュメント自体ではない
 

package/commands/impl.md

@@ -24,6 +24,7 @@ argument-hint: <feature-name:$1> [task-numbers:$2]
 
 **必要なすべてのコンテキストを読み込み**:
 - `.cursor/$1/spec.json`、`requirements.md`、`design.md`、`tasks.md`
+- `.cursor/rules/frontend.md`（存在する場合）からフロントエンド実装ルール
 
 **承認の検証**:
 - spec.json でタスクが承認されていることを確認（されていない場合は停止、安全性とフォールバック参照）

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cursor-sdd",
-  "version": "1.0.0",
+  "version": "1.0.1",
   "description": "Cursor SDD (Spec-Driven Development) - AI-powered spec templates, rules and commands for Cursor IDE",
   "bin": {
     "cursor-sdd": "./bin/setup.js"

package/rules/frontend.md

@@ -0,0 +1,96 @@
+---
+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 等）
+