@sk8metal/michi-cli 0.0.9 → 0.2.0

package/templates/claude/commands/kiro/kiro-spec-impl.md

@@ -0,0 +1,253 @@
+# kiro:spec-impl - Spec Implementation Command
+
+## Overview
+
+This command implements the specifications defined in `tasks.md` following TDD (Test-Driven Development) practices with automatic JIRA integration.
+
+**Key Features:**
+
+- Automatic JIRA info detection from `spec.json`
+- Updates both Epic AND first Story status
+- Creates PR and adds JIRA comments automatically
+
+## Arguments
+
+- `$ARGUMENTS`: Feature name (e.g., "user-auth")
+
+**Note:** JIRA ticket keys are automatically detected from `.kiro/specs/{feature}/spec.json`. No need to specify them manually.
+
+## Pre-requisites
+
+1. `.kiro/specs/{feature}/tasks.md` must exist
+2. `.kiro/specs/{feature}/spec.json` must contain JIRA info (run `michi jira:sync` first)
+3. Environment variables must be configured:
+   - `ATLASSIAN_URL`: JIRA instance URL
+   - `ATLASSIAN_EMAIL`: JIRA user email
+   - `ATLASSIAN_API_TOKEN`: JIRA API token
+   - `GITHUB_TOKEN`: GitHub API token
+   - `GITHUB_REPO`: GitHub repository (owner/repo format)
+
+## Execution Flow
+
+### 1. Parse Arguments
+
+```
+Input: $ARGUMENTS
+Expected format: "<feature-name>"
+Example: "user-auth"
+```
+
+Extract:
+
+- `FEATURE_NAME`: Feature name from arguments
+
+### 2. JIRA Info Detection (Automatic)
+
+Read JIRA information from `.kiro/specs/$FEATURE_NAME/spec.json`:
+
+```json
+{
+  "jira": {
+    "epicKey": "PROJ-123",
+    "storyKeys": ["PROJ-124", "PROJ-125"],
+    "epicUrl": "https://..."
+  }
+}
+```
+
+**If JIRA info is missing:**
+
+- Ask user: "JIRA info not found. Skip JIRA integration? (y/n)"
+- If yes: Continue without JIRA integration
+- If no: Stop and suggest running `michi jira:sync $FEATURE_NAME` first
+
+### 3. Start Processing (JIRA Status Update)
+
+**Automatically move Epic AND first Story to "In Progress":**
+
+This is handled internally. The workflow will:
+
+1. Transition Epic to "In Progress"
+2. Transition first Story to "In Progress"
+
+### 4. Implementation Phase (TDD)
+
+Read the tasks from `.kiro/specs/$FEATURE_NAME/tasks.md` and implement each Story following TDD:
+
+For each Story in tasks.md:
+
+1. **Read Story Requirements**
+   - Parse the Story section from tasks.md
+   - Identify acceptance criteria and subtasks
+
+2. **Write Tests First (Red)**
+   - Create test files based on acceptance criteria
+   - Run tests to verify they fail
+
+3. **Implement Code (Green)**
+   - Write minimal code to pass tests
+   - Follow the existing code patterns in the project
+
+4. **Refactor (Blue)**
+   - Clean up code while keeping tests green
+   - Apply project coding standards
+
+5. **Commit Changes**
+   - Create atomic commits for each Story
+   - Use conventional commit format: `feat($FEATURE_NAME): Story title`
+
+### 5. Code Review Phase (Automatic)
+
+**Automatically review the implemented code:**
+
+For each Story implementation:
+
+1. **Design Review (/michi:design-review)** - **Recommended for UI Components**
+   - **推奨**: UI/フロントエンドコードを実装した場合、`/michi:design-review` コマンドの使用を検討してください
+   - デザイン品質のレビュー（アクセシビリティ、レスポンシブ、UX）
+   - CSS、React、Vue、HTML、Tailwind の変更時に実行
+
+   ```bash
+   /michi:design-review
+   ```
+
+2. **Code Review (/review)**
+   - Execute `/review` command automatically
+   - Analyze the implementation for code quality issues
+   - Check for best practices and potential bugs
+
+3. **Fix Issues if Found**
+   - If review identifies issues, automatically fix them
+   - Commit the fixes
+   - Re-run `/review` to verify fixes
+   - Repeat until `/review` passes without critical issues
+
+4. **Security Review (/security-review)**
+   - Execute `/security-review` command automatically
+   - Scan for security vulnerabilities
+   - Check for common security issues (SQL injection, XSS, etc.)
+
+5. **Fix Security Issues if Found**
+   - If security issues are identified, automatically fix them
+   - Commit the security fixes
+   - Re-run `/security-review` to verify fixes
+   - Repeat until `/security-review` passes without critical issues
+
+**Review Loop:**
+- Maximum iterations: 3 per review type
+- If issues persist after 3 iterations, report to user and ask for manual intervention
+
+### 6. PR Creation Confirmation
+
+**Ask user before creating PR:**
+
+After all reviews pass successfully, ask the user:
+
+```
+✅ All reviews completed successfully!
+   - Code Review: PASSED
+   - Security Review: PASSED
+
+Would you like to create a Pull Request now? (y/n)
+```
+
+- **If yes**: Proceed to End Processing (Step 7)
+- **If no**: Stop workflow, save current state
+  - User can manually create PR later using:
+    - `jj git push --bookmark <branch-name>`
+    - `gh pr create --head <branch-name> --base main`
+
+### 7. End Processing (PR Creation & JIRA Update)
+
+**Automatically complete the workflow:**
+
+This is handled internally. The workflow will:
+
+1. Push the branch to remote
+2. Create a Pull Request on GitHub
+3. Move Epic AND first Story to "Ready for Review"
+4. Add PR link as a comment on the Epic
+
+## Usage Examples
+
+```
+/kiro:spec-impl user-auth
+```
+
+```
+/kiro:spec-impl payment-gateway
+```
+
+## Workflow Comparison
+
+### Before (3 steps with manual JIRA keys)
+
+```bash
+michi spec-impl:start user-auth PROJ-123
+/kiro:spec-impl user-auth PROJ-123
+michi spec-impl:complete user-auth PROJ-123
+```
+
+### After (1 command with auto-detection)
+
+```
+/kiro:spec-impl user-auth
+# JIRA info auto-detected from spec.json
+# Epic + first Story -> "In Progress"
+# TDD implementation
+# Automatic code review (/review)
+#   - Fix issues if found
+#   - Re-review until passed
+# Automatic security review (/security-review)
+#   - Fix security issues if found
+#   - Re-review until passed
+# Ask user: "Create PR now? (y/n)"
+#   - If yes:
+#     - PR creation
+#     - Epic + first Story -> "Ready for Review"
+#     - PR link commented on JIRA
+#   - If no:
+#     - Save state, exit workflow
+```
+
+## JIRA Status Mapping
+
+Default status names (customizable in `.michi/config.json`):
+
+| Phase | Default Status   | Targets            |
+| ----- | ---------------- | ------------------ |
+| Start | In Progress      | Epic + First Story |
+| End   | Ready for Review | Epic + First Story |
+
+To customize, add to `.michi/config.json`:
+
+```json
+{
+  "jira": {
+    "statusMapping": {
+      "inProgress": "In Progress",
+      "readyForReview": "Ready for Review"
+    }
+  }
+}
+```
+
+## Error Handling
+
+- **JIRA info not found**: Interactive prompt to skip JIRA integration
+- **JIRA transition fails**: Check available transitions for the current status
+- **Review fails (max iterations exceeded)**: Report issues to user and ask for manual intervention
+- **Security review fails (max iterations exceeded)**: Report vulnerabilities to user and ask for manual intervention
+- **User declines PR creation**: Save current state, workflow stops (user can create PR manually later)
+- **PR creation fails**: Ensure the branch is pushed to remote
+- **JIRA comment fails**: The PR URL is still returned for manual update
+
+## Notes
+
+- JIRA info is automatically detected from `spec.json` (populated by `michi jira:sync`)
+- Both Epic AND first Story are updated together
+- The branch name defaults to `feature/{feature-name}`
+- Individual JIRA operations can still be done via `michi jira:transition` and `michi jira:comment`
+- Code reviews (`/review` and `/security-review`) are executed automatically after implementation
+- Review loop has a maximum of 3 iterations per review type to prevent infinite loops
+- User can decline PR creation and manually create it later if needed

package/templates/claude/commands/kiro/kiro-spec-tasks.md

@@ -0,0 +1,368 @@
+---
+name: /kiro:spec-tasks
+description: Generate tasks.md from design specification in Michi workflow format
+---
+
+# Generate Tasks from Design Specification
+
+**Important**: Generate output in the language specified in `{{KIRO_DIR}}/project.json`.
+
+## Overview
+
+This command generates a detailed task breakdown (`tasks.md`) from the design specification (`design.md`) following the **Michi Workflow Format**.
+
+**Critical**: The generated tasks.md MUST follow the Michi Phase structure (Phase 0.1-5, A, B) with Story headers. DO NOT generate AI-DLC checkbox format (`- [ ] 1.`, `- [ ] 1.1`).
+
+## Usage
+
+```
+/kiro:spec-tasks
+```
+
+## Input Files
+
+1. `{{KIRO_DIR}}/specs/{{FEATURE_NAME}}/design.md` - Design specification
+2. `{{KIRO_DIR}}/specs/{{FEATURE_NAME}}/requirements.md` - Requirements specification
+3. `{{KIRO_DIR}}/project.json` - Project metadata
+
+## Output File
+
+`{{KIRO_DIR}}/specs/{{FEATURE_NAME}}/tasks.md`
+
+## Required Format: Michi Workflow Structure
+
+### Header Section
+
+```markdown
+# Task Breakdown: {{FEATURE_NAME}}
+
+## Project Information
+
+- **Feature Name**: {{FEATURE_NAME}}
+- **Start Date**: YYYY-MM-DD (Day of week) Day 1
+- **End Date**: YYYY-MM-DD (Day of week)
+- **Total Business Days**: X business days (excluding weekends)
+- **Total Effort Estimate**: X person-days
+- **Holidays**: Excludes Saturdays and Sundays
+- **Note**: This task breakdown is calculated in business days (excluding weekends and holidays)
+```
+
+### Phase Structure (Required)
+
+The tasks.md MUST include these phases in order:
+
+1. **Phase 0.1: Requirements**
+2. **Phase 0.2: Design**
+3. **Phase 0.3: Test Type Selection** (optional)
+4. **Phase 0.4: Test Specification** (optional)
+5. **Phase 1: Environment Setup** (optional)
+6. **Phase 2: TDD Implementation** (required - main development phase)
+7. **Phase A: PR Pre-merge Tests** (optional - CI/CD automated)
+8. **Phase 3: Additional QA** (optional)
+9. **Phase B: Release Preparation Tests** (optional)
+10. **Phase 4: Release Preparation**
+11. **Phase 5: Release**
+
+### Phase Header Format
+
+Each phase MUST use this header format:
+
+```markdown
+## Phase X.Y: Phase Name (Label)
+
+**Period**: Day X-Y
+**Effort**: X person-days
+**Status**: Not Started
+```
+
+### Story Header Format
+
+Each story within a phase MUST use this format:
+
+```markdown
+### Story X.Y.Z: Story Title
+
+- **Assignee**: @Role
+- **Effort**: X person-days
+- **Description**: What this story accomplishes
+- **Deliverables**:
+  - Deliverable 1
+  - Deliverable 2
+- **Acceptance Criteria**:
+  - [ ] Criterion 1
+  - [ ] Criterion 2
+- **Tasks**:
+  - [ ] Task X.Y.Z.1: Task description
+  - [ ] Task X.Y.Z.2: Task description
+- **Dependencies**: Story X.Y.W (if applicable)
+```
+
+## Detailed Phase Guidelines
+
+### Phase 0.1: Requirements
+
+```markdown
+## Phase 0.1: Requirements (Requirements)
+
+**Period**: Day 1
+**Effort**: 0.5 person-days
+**Status**: Not Started
+
+### Story 0.1.1: Requirements Document Creation
+
+- **Assignee**: @PM
+- **Effort**: 0.5 person-days
+- **Description**: Create feature requirements document
+- **Deliverables**:
+  - `.kiro/specs/{{FEATURE_NAME}}/requirements.md`
+  - Confluence page (Requirements)
+- **Acceptance Criteria**:
+  - [ ] Functional requirements defined
+  - [ ] Non-functional requirements defined
+  - [ ] Use cases documented
+  - [ ] PM approved
+```
+
+### Phase 0.2: Design
+
+```markdown
+## Phase 0.2: Design (Design)
+
+**Period**: Day 1-2
+**Effort**: 0.5-1.0 person-days
+**Status**: Not Started
+
+### Story 0.2.1: Basic Design
+
+- **Assignee**: @Architect
+- **Effort**: 0.5-1.0 person-days
+- **Description**: Architecture design, API design, class design
+- **Deliverables**:
+  - `.kiro/specs/{{FEATURE_NAME}}/design.md`
+  - Confluence page (Design Document)
+- **Acceptance Criteria**:
+  - [ ] System architecture diagram created
+  - [ ] Layer structure defined
+  - [ ] API specifications detailed
+  - [ ] Class design completed
+  - [ ] Architect approved
+```
+
+### Phase 2: TDD Implementation (Main Development)
+
+This is the most detailed phase. Break down into multiple stories based on the design.md:
+
+```markdown
+## Phase 2: TDD Implementation (Implementation)
+
+**Period**: Day X-Y
+**Effort**: X person-days
+**Status**: Not Started
+
+### Story 2.1: Project Setup
+
+- **Assignee**: @Developer
+- **Effort**: 0.5 person-days
+- **Description**: Project setup and dependency configuration
+- **Tasks**:
+  - [ ] Task 2.1.1: Create project
+  - [ ] Task 2.1.2: Add dependencies
+  - [ ] Task 2.1.3: Create configuration files
+  - [ ] Task 2.1.4: Create package structure
+  - [ ] Task 2.1.5: Verify build
+- **Deliverables**:
+  - Project configuration files
+  - Package structure
+- **Acceptance Criteria**:
+  - [ ] Project builds successfully
+  - [ ] Application starts
+  - [ ] Package structure matches design
+
+### Story 2.2: [Feature Component] Implementation
+
+- **Assignee**: @Developer
+- **Effort**: X person-days
+- **Description**: Implement [component] with TDD approach
+- **Tasks**:
+  - [ ] Task 2.2.1: Write failing tests (RED)
+  - [ ] Task 2.2.2: Implement minimum code (GREEN)
+  - [ ] Task 2.2.3: Refactor (REFACTOR)
+  - [ ] Task 2.2.4: Integration tests
+- **Acceptance Criteria**:
+  - [ ] All unit tests pass
+  - [ ] Code coverage >= 95%
+  - [ ] Design patterns followed
+
+(Continue with Story 2.3, 2.4, etc. based on design.md components)
+```
+
+### Phase 4: Release Preparation
+
+```markdown
+## Phase 4: Release Preparation (Release Preparation)
+
+**Period**: Day Y-Z
+**Effort**: X person-days
+**Status**: Not Started
+
+### Story 4.1: Production Environment Setup
+
+- **Assignee**: @InfraEngineer
+- **Effort**: X person-days
+- **Description**: Production infrastructure setup and configuration
+- **Acceptance Criteria**:
+  - [ ] Server provisioned
+  - [ ] Database configured
+  - [ ] SSL certificate configured
+  - [ ] Monitoring configured
+
+### Story 4.2: Release Documentation
+
+- **Assignee**: @PM
+- **Effort**: X person-days
+- **Description**: Release notes, manual, operation procedures
+- **Acceptance Criteria**:
+  - [ ] Release notes created
+  - [ ] User manual created
+  - [ ] Operation procedures created
+```
+
+### Phase 5: Release
+
+```markdown
+## Phase 5: Release (Release)
+
+**Period**: Day Z
+**Effort**: X person-days
+**Status**: Not Started
+
+### Story 5.1: Staging Deployment
+
+- **Assignee**: @InfraEngineer
+- **Effort**: X person-days
+- **Description**: Deploy to staging and final verification
+- **Acceptance Criteria**:
+  - [ ] Staging deployment successful
+  - [ ] Smoke tests pass
+  - [ ] Final verification completed
+
+### Story 5.2: Production Release
+
+- **Assignee**: @InfraEngineer, @PM
+- **Effort**: X person-days
+- **Description**: Production release execution
+- **Acceptance Criteria**:
+  - [ ] Production deployment successful
+  - [ ] Smoke tests pass
+  - [ ] Monitoring verified
+  - [ ] Stakeholders notified
+```
+
+## Timeline Section
+
+Include a timeline at the end:
+
+```markdown
+## Timeline (Business Days)
+
+**Assumption**: Calculated in business days (excluding weekends)
+
+### Week 1: Specification Phase
+
+Day 1 (Mon):
+
+- Story 0.1.1: Requirements Document Creation
+- Story 0.2.1: Basic Design (start)
+
+Day 2-3 (Tue-Wed):
+
+- Story 0.2.1: Basic Design (complete)
+- Technical review and PM approval
+
+### Week 2-N: Implementation Phase
+
+(Continue based on project scope)
+```
+
+## Estimate Summary Section
+
+```markdown
+## Estimate Summary
+
+| Phase                        | Story Points | Effort (days) | Stories |
+| ---------------------------- | ------------ | ------------- | ------- |
+| Phase 0.1: Requirements      | X SP         | X days        | X       |
+| Phase 0.2: Design            | X SP         | X days        | X       |
+| Phase 2: TDD Implementation  | X SP         | X days        | X       |
+| Phase 4: Release Preparation | X SP         | X days        | X       |
+| Phase 5: Release             | X SP         | X days        | X       |
+| **Total**                    | **X SP**     | **X days**    | **X**   |
+
+**Conversion Rate**: 1 SP ≈ 0.5 person-days
+```
+
+## JIRA Labels Section
+
+```markdown
+## JIRA Labels
+
+Each story is automatically assigned the following labels:
+
+- `requirements` - Phase 0.1: Requirements
+- `design` - Phase 0.2: Design
+- `test-type-selection` - Phase 0.3: Test Type Selection
+- `test-spec` - Phase 0.4: Test Specification
+- `environment-setup` - Phase 1: Environment Setup
+- `implementation` / `tdd-implementation` - Phase 2: TDD Implementation
+- `phase-a` / `pr-tests` - Phase A: PR Pre-merge Tests
+- `additional-qa` / `testing` - Phase 3: Additional QA
+- `phase-b` / `release-tests` - Phase B: Release Preparation Tests
+- `release-prep` / `release-preparation` - Phase 4: Release Preparation
+- `release` - Phase 5: Release
+```
+
+## Important Notes
+
+1. **DO NOT** use AI-DLC checkbox format (`- [ ] 1.`, `- [ ] 1.1`)
+2. **MUST** use Phase headers (`## Phase X.Y:`)
+3. **MUST** use Story headers (`### Story X.Y.Z:`)
+4. **MUST** include day numbering (Day 1, Day 2, etc.)
+5. **MUST** include effort estimates in person-days
+6. **MUST** include acceptance criteria with checkboxes
+7. Break down Phase 2 stories based on the components in design.md
+8. Ensure each Story has clear dependencies documented
+
+## Recommended: E2E-First Planning
+
+**推奨**: タスク分割を行う前に、`/michi:e2e-plan` コマンドの使用を検討してください。
+
+E2Eファースト方式でタスクを計画することで、以下のメリットがあります：
+- ミニマム動作確認可能な単位を優先
+- 早期フィードバックの獲得
+- リスクの早期発見
+
+```bash
+/michi:e2e-plan
+```
+
+## Execution Steps
+
+1. Read `{{KIRO_DIR}}/specs/{{FEATURE_NAME}}/design.md`
+2. Read `{{KIRO_DIR}}/specs/{{FEATURE_NAME}}/requirements.md`
+3. **（推奨）** `/michi:e2e-plan` コマンドでE2Eファースト計画を作成
+4. Analyze design components and create Story breakdown
+5. Generate `tasks.md` following the Michi Workflow Format above
+6. Save to `{{KIRO_DIR}}/specs/{{FEATURE_NAME}}/tasks.md`
+
+## Validation Checklist
+
+Before finalizing, verify:
+
+- [ ] Phase headers exist (Phase 0.1, 0.2, 2, 4, 5 at minimum)
+- [ ] Story headers follow format (`### Story X.Y.Z:`)
+- [ ] Day numbering is present
+- [ ] Effort estimates are included
+- [ ] Acceptance criteria use checkboxes `- [ ]`
+- [ ] No AI-DLC format (`- [ ] 1.`, `- [ ] 1.1`) is used
+- [ ] Timeline section is included
+- [ ] Estimate summary table is included

package/templates/claude/commands/michi/design-review.md

@@ -0,0 +1,66 @@
+---
+name: /michi:design-review
+description: UIコンポーネントのデザイン品質をレビューする
+---
+
+# デザインレビュー
+
+このコマンドは、UIコンポーネントやフロントエンドコードのデザイン品質をレビューします。
+
+## サブエージェント呼び出し
+
+**重要**: このコマンドは `design-reviewer` サブエージェントを使用します。
+
+design-reviewer サブエージェントを使用して、以下のデザイン品質をレビューしてください。
+
+## レビュー観点
+
+### 1. アクセシビリティ（a11y）
+- WCAG 2.1 ガイドラインへの準拠
+- キーボード操作のサポート
+- スクリーンリーダー対応
+- カラーコントラスト比の確認
+- フォーカスインジケーターの視認性
+
+### 2. レスポンシブデザイン
+- モバイル、タブレット、デスクトップでの表示確認
+- ブレークポイントの適切性
+- フレキシブルレイアウトの実装
+- タッチターゲットのサイズ（最小44x44px）
+
+### 3. デザインシステムとの整合性
+- カラーパレットの使用
+- タイポグラフィの統一
+- スペーシングの一貫性
+- コンポーネントの再利用
+
+### 4. UXベストプラクティス
+- ユーザーフィードバックの適切性
+- エラーメッセージの明確性
+- ローディング状態の表示
+- 操作の直感性
+
+## 参照スキル
+
+スキル `design-review` のガイドラインに従ってレビューを実施してください。
+
+## 使用例
+
+```
+/michi:design-review
+```
+
+コマンド実行後、現在のプロジェクトのUIコンポーネントをレビューし、改善提案を行います。
+
+## 出力
+
+レビュー結果は以下の形式で出力されます：
+
+1. **レビューサマリー**: 全体的な評価
+2. **問題点**: 発見された問題のリスト（優先度付き）
+3. **改善提案**: 具体的な改善策
+4. **参考資料**: 関連するベストプラクティスへのリンク
+
+## 言語設定
+
+出力言語は {{KIRO_DIR}}/project.json の設定に従います。