soba-cli 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: f625e2d4087669f271d845b639c3742d85a34cd02db4b4c80e491e1df047065f
+  data.tar.gz: c387463adbc03c35def3dd15123ba05f74271c3ef7e2a3885d4627d1f7532c49
+SHA512:
+  metadata.gz: a5298526b1759939245ddf44becd057a969ae8577e5ce239f3ee5ec40897628759916b78728bdc9bbcbf2fce7c5876aa6d30ebdbd3fd3226c6703b72ac297f16
+  data.tar.gz: d0a69bd5c2ed520041e3b9c83fb0b68795762b21c59a285f88e84b76c44417380279954a2e7b3670ad1e7614a527476d5a654033fb37e22e5c8026c64955659e

data/.claude/commands/osoba/add-backlog.md

@@ -0,0 +1,173 @@
+---
+allowed-tools: TodoWrite, TodoRead, Bash, Read, Grep, Glob, LS
+description: "Create implementation plan"
+---
+
+## Overview
+
+You are a skilled Product Owner.  
+Your task is to analyze the user's requirements and create backlog items represented as GitHub Issues.
+
+---
+
+## Prerequisites
+
+### Documents
+
+Refer to the following document indexes (Document System format):
+
+- Business: `@docs/business/INDEX.md`
+- Development: `@docs/development/INDEX.md`
+- Operations: `@docs/operations/INDEX.md`
+
+### Qualities of a Good Backlog Item
+
+Backlog items should follow the INVEST principle:
+
+- **I**ndependent  
+- **N**egotiable  
+- **V**aluable  
+- **E**stimable  
+- **S**mall  
+- **T**estable  
+
+Each item should represent a meaningful business unit and ideally be completable within 2 days.
+
+### Backlog Splitting Methods
+
+| Method                        | Description                                  | Example |
+|------------------------------|----------------------------------------------|---------|
+| Workflow step                | Split based on business or user workflows    | "Purchase" → "Add to cart", "Enter info", "Payment" |
+| Data type                    | Split based on types of data handled         | "Report" → "Sales", "Access", "Satisfaction" |
+| Platform                     | Split by platform or environment             | "Notification" → "PC", "Mobile", "App" |
+| Usage pattern / use case     | Split by concrete usage scenarios            | "Comment" → "Post", "Edit", "Delete" |
+| System layer                 | Split by implementation layer                | "Favorites" → "UI", "DB", "API" |
+| Conditions / rules           | Split based on conditions or exceptions      | "Discount" → "Standard", "First-time", "Coupon" |
+
+---
+
+## Rules
+
+1. **Do not modify the codebase**
+2. **Clarify vague requirements first**
+3. **Split items into units of roughly 2 days of work**
+4. **Do not create Issues without explicit user approval**
+5. **Use the backlog template format for Issues**
+6. **Ignore backward compatibility unless explicitly required**
+
+---
+
+## Instructions
+
+### High-Level Workflow
+
+1. Analyze requirements  
+2. Design backlog items  
+3. Propose the items to the user  
+4. Obtain approval and make revisions  
+5. Create GitHub Issues and report
+
+---
+
+### Detailed Steps
+
+1. **Initialize the working directory**  
+   Run the following command to reset the output directory:  
+   ```bash
+   mkdir -p ./.tmp/requirements
+   ```
+
+2. **Analyze requirements and design backlog**  
+   - Clarify the requirements  
+   - Split them into appropriately sized backlog items (2-day units)  
+   - For each item, write down goals, acceptance criteria, and technical considerations  
+   - Save each item to `./.tmp/requirements/req-[slug].md` using the backlog template
+
+3. **Present your proposal to the user**  
+   - Explain the rationale for splitting and prioritization  
+   - Summarize each item using bullet points
+
+4. **Obtain explicit approval**  
+   - Continue communication until approval is explicitly given  
+   - Do not proceed unless the user says something like "OK" or "Please go ahead"
+
+5. **Create GitHub Issues**  
+   - Write an issue title that follows Conventional Commits style  
+   - Run `gh issue create` with `--body-file ./.tmp/requirements/req-[slug].md`  
+   - Report the created issue number and URL
+
+---
+
+## Backlog Template
+
+```
+## ユーザーストーリー
+
+（例）[ECサイト利用者]として、[商品をカートに入れたい]。なぜなら[購入したい商品をまとめて決済したい]から。
+
+## 背景・目的
+
+この機能は以下の課題・目的を解決するために必要です。
+
+- (この機能が必要な背景や目的を記述する)
+
+## 受け入れ条件（完了の定義）
+
+- [ ] (具体的な完了条件1)
+- [ ] (具体的な完了条件2)
+- [ ] (具体的な完了条件3)
+
+## 技術的考慮事項
+
+- (技術的に考慮すべき点1)
+- (技術的に考慮すべき点2)
+
+## 依存関係・ブロッカー
+
+- (依存しているIssueや外部要因など)
+- (依存しているIssueや外部要因など)
+
+## 関連資料・Issue
+
+- (関連するドキュメントやIssueや資料)
+- (関連するドキュメントやIssueや資料)
+```
+
+## Backlog Example
+
+```
+## ユーザーストーリー
+
+ログイン済みのユーザーとして、お気に入りボタンを使って商品を保存したい。なぜなら、あとで比較・購入しやすくなるから。
+
+## 背景・目的
+
+- ユーザーが購入を即決せずに検討することが多いため、再訪時の利便性を高めたい  
+- 商品ページの離脱率が高く、検討中のユーザーを取りこぼしている可能性がある
+
+## 受け入れ条件（完了の定義）
+
+- [ ] 商品カードまたは詳細ページに「♡」ボタンが表示されている  
+- [ ] ボタンを押すと商品がお気に入りリストに追加される  
+- [ ] 再度押すとお気に入りから削除される  
+- [ ] ログインユーザーごとにお気に入りが保持される  
+- [ ] お気に入り一覧ページが存在し、追加した商品が表示される
+
+## 技術的考慮事項
+
+- ログインユーザーのIDに紐づくお気に入りテーブルを新設  
+- フロントエンドはVueでリアクティブに状態変更を反映する  
+- バックエンドはAPI経由で追加／削除／取得を非同期処理  
+- テストはお気に入り追加／削除／一覧表示のパターンをカバー
+
+## 依存関係・ブロッカー
+
+- #100 ユーザー認証の安定化  
+- #102 商品一覧コンポーネントの再設計
+
+## 関連資料・Issue
+
+- デザインFigma: https://figma.com/file/abc1234/favorite-feature  
+- 要件定義: `@docs/business/favorite-feature.md`  
+- 関連Issue: #90, #103
+```

data/.claude/commands/osoba/implement.md

@@ -0,0 +1,151 @@
+---
+allowed-tools: TodoRead, TodoWrite, Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS
+description: "Implementation work using TDD"
+---
+
+## Overview
+
+You are a skilled developer responsible for safely and reliably implementing this Issue.  
+In this phase, you will modify or add code based on the implementation plan, run tests, and finally create a Pull Request for review.
+
+---
+
+## Prerequisites
+
+### Documents
+
+Refer to the following documentation:
+
+- **Coding Standards**: @docs/development/coding-standards.md
+- **Testing Strategy**: @docs/development/testing-strategy.md
+- **Other Development Documents**: @docs/development/INDEX.md
+
+### Expected state of the Issue
+
+- A comment contains the implementation plan
+- Acceptance criteria are clearly described
+
+---
+
+## Rules
+
+1. Always review the implementation plan and follow it carefully
+2. Follow TDD; if you can't write tests first, reconsider your design
+3. Respect the existing design and architecture (do not change it arbitrarily)
+4. When implementation is complete, submit a Pull Request for review
+5. PRs must include the purpose, changes made, test details, and linked Issue
+6. If the current directory is under `.git/osoba/`, this is a dedicated codebase created using git worktree, so you must not reference or edit any parent directories
+7. **Code Collective Ownership**: Take responsibility for the entire codebase and proactively fix issues even if they seem unrelated to your changes
+8. **Time Constraints**: Do not fear time constraints or context compression. Work calmly and thoroughly, prioritizing quality above speed  
+
+### Implementation Style Principles
+
+- **Follow the DRY (Don't Repeat Yourself) principle**  
+  Avoid repeating logic, knowledge, or structure
+
+- **Follow the YAGNI (You Aren’t Gonna Need It) principle**  
+  Don't add code for features that "might be needed someday"
+
+- **Use mocks only when necessary**  
+  Only mock external integrations (e.g., APIs, email)
+
+- **Use FactoryBot for test data**  
+  Maintain structured and flexible test fixtures
+
+- **Keep controllers skinny, models fat, and views simple**  
+  Concentrate business logic in models and keep controllers/views minimal
+
+---
+
+## Instructions
+
+### Workflow (Overview)
+
+1. Review the implementation plan and Issue  
+2. Write test cases first  
+3. Implement in small commits  
+4. Run tests and verify functionality  
+5. Run full test suite before PR creation
+6. Create a PR template as `./.tmp/pull-request-<issue number>.md`  
+7. Create the Pull Request  
+8. Leave a comment on the Issue  
+9. Update Issue labels (remove "status:implementing", add "status:review-requested")  
+
+---
+
+## Detailed Steps
+
+1. **Review the implementation plan and Issue**
+   - Run `gh issue view <issue number>` to confirm requirements  
+   - Run `gh issue view <issue number> --comments` to review the implementation plan  
+   - If unclear, ask questions or request clarification
+
+2. **Write test cases first**
+   - Prepare tests based on the test strategy in the plan  
+   - Follow Red → Green → Refactor
+
+3. **Start implementation**
+   - Commit frequently with meaningful messages
+
+4. **Run tests and verify**
+   - Run `yarn test`, `rspec`, or your project's standard method # timeout 600000ms
+   - Perform manual UI/API testing if applicable
+
+5. **Run full test suite (MANDATORY)**
+   - **⚠️ CRITICAL: All tests in the entire codebase must pass - this is an absolute requirement for acceptance**
+   - Run `bin/rails spec` (NO ARGUMENTS - full test suite) to ensure all tests pass # timeout 600000ms
+   - Fix any failures before proceeding, even if they seem unrelated to your changes
+   - **ABSOLUTE REQUIREMENT**: Never create a PR without running the full test suite
+   - **IMPORTANT**: Execute `bin/rails spec` without any arguments to test the entire codebase
+
+6. **Create the PR template**
+   - Write `./.tmp/pull-request-123.md` based on the template shown below
+
+7. **Create the Pull Request**
+   - Title example: `feat: Add favorite feature for products (#123)`  
+   - Use `--body-file ./.tmp/pull-request-123.md` to populate the PR body  
+   - Example using `gh`:
+
+     ```bash
+     gh pr create \\
+       --title "feat: Add favorite feature for products (#123)" \\
+       --body-file ./.tmp/pull-request-123.md \\
+       --base main
+     ```
+
+8. **Leave a comment on the Issue**
+   - Example: "Submitted PR #456. Please review."
+
+9. **Update Issue labels**
+   - Remove "status:implementing" label
+   - Add "status:review-requested" label
+   - Example using `gh`:
+   
+     ```bash
+     gh issue edit <issue number> \\
+       --remove-label "status:implementing" \\
+       --add-label "status:review-requested"
+     ```
+
+---
+
+## PRテンプレート
+
+```markdown
+## 実装完了
+
+以下のIssueについて、TDDに基づき実装を完了しました。
+
+- Issue: fixes #<ISSUE番号>
+- 対応内容:
+  - <対応した主な機能や修正点1>
+  - <対応した主な機能や修正点2>
+- 実装方式: テスト駆動開発（TDD）に準拠
+- テスト状況:
+  - 単体テスト: ✅ パス ／ ❌ 失敗
+  - 結合テスト: ✅ パス ／ ❌ 失敗
+  - **フルテスト (`bin/rails spec` 引数なし)**: ✅ パス ／ ❌ 失敗
+- 関連PR: #<PR番号>
+
+ご確認のほどよろしくお願いいたします。
+```

data/.claude/commands/osoba/plan.md

@@ -0,0 +1,217 @@
+---
+allowed-tools: TodoWrite, TodoRead, Bash, Read, Grep, Glob, LS
+description: "Create implementation plan"
+---
+
+## Overview
+
+You are a capable software architect.  
+Your task is to create an Implementation Plan (Plan) for a given GitHub Issue, including technical investigation, design decisions, task breakdown, test planning, and risk assessment, and post it as a comment on the Issue.
+
+---
+
+## Prerequisites
+
+### Documents
+
+Please refer to the relevant documents via the following index files (Document System format):
+
+- **Coding Standards**: @docs/development/coding-standards.md
+- **Testing Strategy**: @docs/development/testing-strategy.md
+- **Other Development Documents**: @docs/development/INDEX.md
+
+### Expected State of the Issue
+
+- Acceptance criteria are clearly written in the GitHub Issue  
+
+---
+
+## Rules
+
+1. **Do not modify code; focus solely on creating the plan**
+2. **Design the plan with TDD and testability in mind**
+3. **Follow the existing system architecture**
+4. **Break the plan into step-by-step, executable units**
+5. **Use the predefined template format when writing the plan**
+6. **Update the label to `status:ready` upon completion**
+7. **When researching libraries, use `use context7 mcp` to always refer to the latest official documentation**
+
+---
+
+## Instructions
+
+### High-Level Workflow
+
+1. Confirm the target Issue
+2. Investigate relevant code and architecture
+3. Choose a technical approach
+4. Define task steps and test coverage
+5. Document risks and schedule
+6. Write the plan to a file
+7. Post the plan as a comment to the Issue
+8. Update the Issue label
+
+---
+
+### Detailed Steps
+
+1. **Confirm the target Issue**
+   - Run `gh issue view <issue number>` and check:
+     - Title, background, user story, and acceptance criteria
+   - Run `gh issue view <issue number> --comments` and check:
+     - Additional information, user approval, or clarifications in comments
+
+2. **Investigate codebase and system structure**
+   - Review related source files, config files, and similar past implementations
+   - Identify impact areas and dependencies
+
+3. **Choose a technical approach**
+   - Specify libraries, design patterns, and frameworks to use
+   - Clearly state reasoning and alternatives considered
+
+4. **Break down the implementation into steps**
+   - Ensure each step is testable and small enough for incremental progress
+   - Include notes on related files, side effects, and prerequisites
+
+5. **Describe test strategy, risks, and schedule**
+   - Outline unit, integration, and E2E test plans
+   - List possible technical risks and mitigation strategies
+   - Define estimated duration and key checkpoints
+
+6. **Write the implementation plan to a file**
+   - Use the implementation plan template and save to `./.tmp/plan-[slug].md`
+   - Replace `[slug]` with a kebab-case version of the issue title (e.g., `plan-add-favorite.md`)
+
+7. **Post the plan as a comment**
+   - Run: `gh issue comment <issue number> --body-file ./.tmp/plan-[slug].md`
+
+8. **Update the label**
+   - Run: `gh issue edit <issue number> --remove-label "status:planning" --add-label "status:ready"`
+
+---
+
+## Plan template
+
+```
+# 実行計画: [タイトル]
+
+## 前提知識
+- [関連技術・既存システムの構造]
+- [考慮すべき制約]
+- [参考資料・ドキュメント]
+
+## 要件概要
+- [要件の概要と目的]
+- [機能要件]
+- [非機能要件（例：性能、セキュリティ）]
+- [受け入れ条件]
+
+## 設計方針
+- [使用する技術や設計パターン]
+- [構成方針や判断理由]
+- [考慮したアーキテクチャ上のポイント]
+
+## 実装ステップ
+1. [ステップ1]
+   - [具体的な作業内容]
+   - [関係するファイルや関数など]
+2. [ステップ2]
+   - [同上]
+
+## テスト計画
+- ユニットテスト：
+  - [テスト対象]
+  - [テストケース（正常系／異常系）]
+- 結合・システムテスト：
+  - [検証すべきユーザーフローやパターン]
+- テストデータ：
+  - [準備すべき入力データや事前状態の例]
+
+## リスクと対策
+- [想定されるリスク1]
+  - [対策案]
+- [想定されるリスク2]
+  - [対策案]
+
+## タイムライン
+- 実装期間の目安: [開始日] 〜 [終了日]
+- 各ステップの予想時間（単位: 時間）:
+  - ステップ1: [X時間]
+  - ステップ2: [X時間]
+```
+
+## Plan example
+
+```
+# 実行計画: 商品にお気に入り機能を追加する
+
+## 前提知識
+- Webアプリは Vue 3 + Rails API で構成されている
+- ユーザー認証は Devise Token Auth により実装されている
+- フロントエンドは Pinia により状態管理されている
+- お気に入り状態はユーザー単位で永続化される必要がある
+- `products` テーブルは既に存在し、IDと基本情報を保持している
+
+## 要件概要
+- 商品に「お気に入り」ボタン（ハートアイコン）を追加する
+- ユーザーは任意の商品をお気に入りリストに追加・削除できる
+- お気に入り一覧ページで、自身が登録した商品だけを確認できる
+- 非ログイン状態ではボタンを表示しない
+- パフォーマンス要件：追加・削除は非同期、レスポンス200ms以内
+
+## 設計方針
+- フロントエンドは `<FavoriteButton>` コンポーネントを導入して再利用可能にする
+- バックエンドは `favorites` テーブル（user_id, product_id）を新設し、RESTful APIで操作する
+- フロント側は Pinia でお気に入り状態をキャッシュ保持し、APIとの同期を行う
+- ユーザー認証済みでない場合、ボタンを非表示にする
+
+## 実装ステップ
+1. `favorites` テーブルの追加
+   - migration を作成し、ユニーク制約 (user_id, product_id) を設定
+   - index を追加して高速化
+
+2. APIエンドポイントの作成
+   - `POST /api/favorites`（追加）
+   - `DELETE /api/favorites/:id`（削除）
+   - `GET /api/favorites`（一覧取得）
+
+3. フロントの状態管理構築
+   - Piniaストアでお気に入り状態を保持
+   - 初回ロード時に `/favorites` を取得
+
+4. `<FavoriteButton>` コンポーネントの作成
+   - 状態に応じてアイコン切替（空白ハート↔実心ハート）
+   - ボタンクリックで追加／削除APIを呼び出す
+
+5. 商品カードおよび詳細ページへのボタン配置
+   - `ProductCard.vue` および `ProductDetail.vue` に設置
+
+## テスト計画
+- ユニットテスト：
+  - FavoriteStore（状態切替の確認）
+  - FavoriteButton（UIの状態／クリック挙動）
+
+- 結合・システムテスト：
+  - ログイン → 商品一覧表示 → ハートを押して追加／削除できる
+  - 非ログイン時にはボタンが表示されないこと
+
+- テストデータ：
+  - ユーザー：ログイン済みのダミーユーザー
+  - 商品：product_id = 1〜3 の仮データを用意
+
+## リスクと対策
+- お気に入りの二重登録
+  - 対策：DBにユニークインデックスを設定
+- お気に入りの状態同期ミス
+  - 対策：非同期APIのレスポンスに基づいて状態を確定させる
+
+## タイムライン
+- 実装期間の目安: 2025-07-22 〜 2025-07-24
+- 各ステップの予想時間（単位: 時間）:
+  - ステップ1: 1.5h
+  - ステップ2: 2.0h
+  - ステップ3: 1.5h
+  - ステップ4: 2.0h
+  - ステップ5: 1.0h
+  - テスト＆検証: 1.5h
+```

data/.claude/commands/osoba/review.md

@@ -0,0 +1,133 @@
+---
+allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS
+description: "Review and merge a Pull Request"
+---
+
+# Review Plan
+
+As a QA engineer, your task is to review the Pull Request (PR) associated with the specified Issue and evaluate whether it meets all quality standards.
+
+## Context
+
+- Specification Driven Development: @.claude/osoba/docs/spacification_driven_development.md
+- Target Issue number: $ARGUMENTS
+
+
+## Workflow
+
+### 1. Check the Issue
+
+- Run `GH_PAGER= gh issue view <issue number>` to understand the context and requirements
+- Identify the corresponding PR number
+
+- Run `GH_PAGER= gh issue view <issue number>`  
+  → Confirm the **issue content and requirements**
+
+- Run `GH_PAGER= gh issue view <issue number> --comments`  
+  → Review the **design document and task list**
+
+⚠️ **Note**: When using `--comments`, the issue body may not be displayed correctly.  
+Be sure to run the version *without* `--comments` first to understand the requirements.
+
+### 2. Check the PR
+
+- Run `GH_PAGER= gh pr view <PR number>` to review the purpose, changes, and description of the PR
+- Ensure the implementation satisfies the original requirements
+
+### 3. Check for Conflicts
+
+- Run `GH_PAGER= gh pr view <PR number> --json mergeable,mergeStateStatus` to check merge status
+- If conflicts exist (mergeable=false or mergeStateStatus=CONFLICTING):
+  - The PR needs to be rebased against the base branch
+  - Include this in the review feedback
+
+### 4. Review Code Changes
+
+- Run `GH_PAGER= gh pr diff <PR number>` to check the code diff
+- Evaluate the changes with the following criteria:
+  - Compliance with coding standards
+  - Presence and adequacy of test cases
+  - Security concerns and potential vulnerabilities
+  - Unnecessary diffs (e.g., debug code, commented-out lines)
+
+### 5. Check CI Results (MANDATORY - MUST WAIT FOR COMPLETION)
+
+- **⚠️ CRITICAL: You MUST wait for CI to complete before providing review results**
+- **NEVER provide review results while CI is still running or pending**
+- Run `GH_PAGER= gh pr checks <PR number>` to verify CI status
+  - All checks must ✅ pass
+  - If checks are still running, wait and retry until completed
+  - ⚠️ **Note**: CI can take over 5 minutes to complete. Be patient and ensure all checks are fully finished before proceeding
+  - To wait for CI completion, you can use:
+    ```bash
+    gh pr checks <PR number> --watch # timeout 600000ms
+    ```
+    or repeatedly check status:
+    ```bash
+    while true; do
+      gh pr checks <PR number>
+      sleep 30
+    done # timeout 600000ms
+    ```
+  - **ABSOLUTE REQUIREMENT**: CI completion, merge capability check, and code review ALL must be complete before providing review results
+
+### 6. Post Review Result (ONLY AFTER CI COMPLETION)
+
+- **⚠️ PREREQUISITE**: Only proceed if ALL of the following are complete:
+  1. CI has fully completed (not pending or running)
+  2. Merge capability has been verified
+  3. Code review has been completed
+- **NEVER post review results if CI is not complete**
+- Post the review result using:
+  `GH_PAGER= gh pr comment <PR number> --body "$(cat ./.tmp/review-result-<issue number>.md)"`
+- Use the following template for `./.tmp/review-result-<issue number>.md`:
+
+```markdown
+## Review Result
+
+- Issue: #<issue number>
+- PR: #<PR number>
+
+### ✅ Verdict
+- [ ] Approved (LGTM)
+- [ ] Requires changes
+
+### 🔄 Merge Status
+- [ ] No conflicts - ready to merge
+- [ ] Has conflicts - needs rebase
+
+### 👍 Positive Notes
+- [List of strengths in the implementation]
+
+### 🛠 Suggestions for Improvement
+- [List of specific recommendations]
+
+### 🔍 Additional Notes
+- [Optional remarks if any]
+```
+
+### 7. Update Labels
+
+After posting the review result, update the labels based on the verdict:
+
+#### If Approved (LGTM):
+1. Keep `status:reviewing` label on the Issue (Issue lifecycle ends here)
+2. Remove `status:requires-changes` label from the Pull Request (if exists) and add `status:lgtm` label:
+   ```bash
+   gh pr edit <PR number> --remove-label "status:requires-changes" --add-label "status:lgtm"
+   ```
+
+#### If Requires Changes:
+1. Keep `status:reviewing` label on the Issue (Issue remains in review state)
+2. Add `status:requires-changes` label to the Pull Request:
+   ```bash
+   gh pr edit <PR number> --add-label "status:requires-changes"
+   ```
+
+## Basic Rules
+
+- Ensure compliance with coding conventions
+- Confirm the implementation fully meets the issue requirements
+- Check for any potential security issues
+- All tests and CI checks must pass
+- Review comments must be clear and constructive