@sk8metal/michi-cli 0.13.0 → 0.14.1

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

@@ -1,257 +0,0 @@
-# kiro:spec-impl - Spec Implementation Command
-
-## Development Guidelines
-
-{{DEV_GUIDELINES}}
-
-## 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)~~ **Deprecated (v0.5.0+)**: Repository info is now automatically loaded from `.kiro/project.json`
-
-## 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

@@ -1,370 +0,0 @@
----
-name: /kiro:spec-tasks
-description: Generate tasks.md from design specification in Michi workflow format
----
-
-# Generate Tasks from Design Specification
-
-## Development Guidelines
-
-{{DEV_GUIDELINES}}
-
-## 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/confluence-sync.md

@@ -1,44 +0,0 @@
----
-name: /michi:confluence-sync
-description: Sync specifications to Confluence (Michi-specific feature)
----
-
-# Confluence Sync Command
-
-> **Michi 固有機能**: このコマンドは Michi 独自の機能です。cc-sdd 標準には含まれません。
->
-> 仕様書（requirements.md, design.md）を Confluence に同期し、承認ワークフローを実現します。
-
-## Development Guidelines
-
-{{DEV_GUIDELINES}}
-
-## Usage
-
-```
-/michi:confluence-sync <feature_name>
-```
-
-**Parameters**:
-- `feature_name`: Feature name (e.g., user-auth, payment-api)
-
-## Execution Steps
-
-1. Read specifications from {{KIRO_DIR}}/specs/{{FEATURE_NAME}}/
-2. Load project metadata from {{KIRO_DIR}}/project.json
-3. Sync requirements.md to Confluence
-4. Sync design.md to Confluence
-5. Create/update Confluence pages with proper labels
-6. Link pages to JIRA Epic (if exists)
-
-## Language Handling
-
-- Read language from {{KIRO_DIR}}/project.json
-- Generate all output in the specified language
-- Use Confluence labels from project.json for page organization
-
-## Project Metadata
-
-- Project ID: {{PROJECT_ID}}
-- Kiro directory: {{KIRO_DIR}}
-- Agent directory: {{AGENT_DIR}}