Implement CCXT Exchange Builder Factory with TDD methodology

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

@@ -0,0 +1,62 @@
+---
+description: Execute spec tasks using TDD methodology
+allowed-tools: Bash, Read, Write, Edit, MultiEdit, Grep, Glob, LS, WebFetch, WebSearch
+argument-hint: <feature-name> [task-numbers]
+---
+
+# Execute Spec Tasks with TDD
+
+Execute implementation tasks for **$1** using Kent Beck's Test-Driven Development methodology.
+
+## Instructions
+
+### Pre-Execution Validation
+Validate required files exist for feature **$1**:
+- Requirements: `.kiro/specs/$1/requirements.md`
+- Design: `.kiro/specs/$1/design.md`  
+- Tasks: `.kiro/specs/$1/tasks.md`
+- Metadata: `.kiro/specs/$1/spec.json`
+
+### Context Loading
+
+**Core Steering:**
+- Structure: @.kiro/steering/structure.md
+- Tech Stack: @.kiro/steering/tech.md  
+- Product: @.kiro/steering/product.md
+
+**Custom Steering:**
+- Additional `*.md` files in `.kiro/steering/` (excluding structure.md, tech.md, product.md)
+
+**Spec Documents for $1:**
+- Metadata: @.kiro/specs/$1/spec.json
+- Requirements: @.kiro/specs/$1/requirements.md
+- Design: @.kiro/specs/$1/design.md
+- Tasks: @.kiro/specs/$1/tasks.md
+
+### Task Execution
+1. **Feature**: $1  
+2. **Task numbers**: $2 (optional, defaults to all pending tasks)
+3. **Load all context** (steering + spec documents)
+4. **Execute selected tasks** using TDD methodology
+
+### TDD Implementation
+For each selected task:
+
+1. **RED**: Write failing tests first
+2. **GREEN**: Write minimal code to pass tests  
+3. **REFACTOR**: Clean up and improve code structure
+4. **Verify**: 
+   - All tests pass
+   - No regressions in existing tests
+   - Code quality and test coverage maintained
+5. **Mark Complete**: Update checkbox from `- [ ]` to `- [x]` in tasks.md
+
+**Note**: Follow Kent Beck's TDD methodology strictly, implementing only the specific task requirements.
+
+## Implementation Notes
+
+- **Feature**: Use `$1` for feature name
+- **Tasks**: Use `$2` for specific task numbers (optional)
+- **Validation**: Check all required spec files exist
+- **TDD Focus**: Always write tests before implementation
+- **Task Tracking**: Update checkboxes in tasks.md as completed

.claude/commands/kiro/spec-init.md

@@ -0,0 +1,86 @@
+---
+description: Initialize a new specification with detailed project description and requirements
+allowed-tools: Bash, Read, Write, Glob
+argument-hint: <project-description>
+---
+
+# Spec Initialization
+
+Initialize a new specification based on the provided project description:
+
+**Project Description**: $ARGUMENTS
+
+## Task: Initialize Specification Structure
+
+**SCOPE**: This command initializes the directory structure and metadata based on the detailed project description provided.
+
+### 1. Generate Feature Name
+Create a concise, descriptive feature name from the project description ($ARGUMENTS).
+**Check existing `.kiro/specs/` directory to ensure the generated feature name is unique. If a conflict exists, append a number suffix (e.g., feature-name-2).**
+
+### 2. Create Spec Directory
+Create `.kiro/specs/[generated-feature-name]/` directory with:
+- `spec.json` - Metadata and approval tracking
+- `requirements.md` - Lightweight template with project description
+
+**Note**: design.md and tasks.md will be created by their respective commands during the development process.
+
+### 3. Initialize spec.json Metadata
+Create initial metadata with approval tracking:
+```json
+{
+  "feature_name": "[generated-feature-name]",
+  "created_at": "current_timestamp",
+  "updated_at": "current_timestamp",
+  "language": "en",
+  "phase": "initialized",
+  "approvals": {
+    "requirements": {
+      "generated": false,
+      "approved": false
+    },
+    "design": {
+      "generated": false,
+      "approved": false
+    },
+    "tasks": {
+      "generated": false,
+      "approved": false
+    }
+  },
+  "ready_for_implementation": false
+}
+```
+
+### 4. Create Requirements Template
+Create requirements.md with project description:
+```markdown
+# Requirements Document
+
+## Project Description (Input)
+$ARGUMENTS
+
+## Requirements
+<!-- Will be generated in /kiro:spec-requirements phase -->
+```
+
+### 5. Update CLAUDE.md Reference
+Add the new spec to the active specifications list with the generated feature name and a brief description.
+
+## Next Steps After Initialization
+
+Follow the strict spec-driven development workflow:
+1. **`/kiro:spec-requirements <feature-name>`** - Create and generate requirements.md
+2. **`/kiro:spec-design <feature-name>`** - Create and generate design.md (requires approved requirements)
+3. **`/kiro:spec-tasks <feature-name>`** - Create and generate tasks.md (requires approved design)
+
+**Important**: Each phase creates its respective file and requires approval before proceeding to the next phase.
+
+## Output Format
+
+After initialization, provide:
+1. Generated feature name and rationale
+2. Brief project summary
+3. Created spec.json path
+4. **Clear next step**: `/kiro:spec-requirements <feature-name>`
+5. Explanation that only spec.json was created, following stage-by-stage development principles

.claude/commands/kiro/spec-requirements.md

@@ -0,0 +1,130 @@
+---
+description: Generate comprehensive requirements for a specification
+allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch
+argument-hint: <feature-name>
+---
+
+# Requirements Generation
+
+Generate comprehensive requirements for feature: **$1**
+
+## Context Validation
+
+### Steering Context
+- Architecture context: @.kiro/steering/structure.md
+- Technical constraints: @.kiro/steering/tech.md
+- Product context: @.kiro/steering/product.md
+- Custom steering: Load all "Always" mode custom steering files from .kiro/steering/
+
+### Existing Spec Context
+- Current spec directory: !`bash -c 'ls -la .kiro/specs/$1/'`
+- Current requirements: `.kiro/specs/$1/requirements.md`
+- Spec metadata: `.kiro/specs/$1/spec.json`
+
+## Task: Generate Initial Requirements
+
+### 1. Read Existing Requirements Template
+Read the existing requirements.md file created by spec-init to extract the project description.
+
+### 2. Generate Complete Requirements
+Generate an initial set of requirements in EARS format based on the project description, then iterate with the user to refine them until they are complete and accurate.
+
+Don't focus on implementation details in this phase. Instead, just focus on writing requirements which will later be turned into a design.
+
+### Requirements Generation Guidelines
+1. **Focus on Core Functionality**: Start with the essential features from the user's idea
+2. **Use EARS Format**: All acceptance criteria must use proper EARS syntax
+3. **No Sequential Questions**: Generate initial version first, then iterate based on user feedback
+4. **Keep It Manageable**: Create a solid foundation that can be expanded through user review
+5. **Choose an appropriate subject**: For software projects, use the concrete system/service name (e.g., "Checkout Service") instead of a generic subject. For non-software, choose a responsible subject (e.g., process/workflow, team/role, artifact/document, campaign, protocol).
+
+### 3. EARS Format Requirements
+
+**EARS (Easy Approach to Requirements Syntax)** is the recommended format for acceptance criteria:
+
+**Primary EARS Patterns:**
+- WHEN [event/condition] THEN [system/subject] SHALL [response]
+- IF [precondition/state] THEN [system/subject] SHALL [response]
+- WHILE [ongoing condition] THE [system/subject] SHALL [continuous behavior]
+- WHERE [location/context/trigger] THE [system/subject] SHALL [contextual behavior]
+
+**Combined Patterns:**
+- WHEN [event] AND [additional condition] THEN [system/subject] SHALL [response]
+- IF [condition] AND [additional condition] THEN [system/subject] SHALL [response]
+
+### 4. Requirements Document Structure
+Update requirements.md with complete content in the language specified in spec.json (check `.kiro/specs/$1/spec.json` for "language" field):
+
+```markdown
+# Requirements Document
+
+## Introduction
+[Clear introduction summarizing the feature and its business value]
+
+## Requirements
+
+### Requirement 1: [Major Objective Area]
+**Objective:** As a [role/stakeholder], I want [feature/capability/outcome], so that [benefit]
+
+#### Acceptance Criteria
+This section should have EARS requirements
+
+1. WHEN [event] THEN [system/subject] SHALL [response]
+2. IF [precondition] THEN [system/subject] SHALL [response]
+3. WHILE [ongoing condition] THE [system/subject] SHALL [continuous behavior]
+4. WHERE [location/context/trigger] THE [system/subject] SHALL [contextual behavior]
+
+### Requirement 2: [Next Major Objective Area]
+**Objective:** As a [role/stakeholder], I want [feature/capability/outcome], so that [benefit]
+
+1. WHEN [event] THEN [system/subject] SHALL [response]
+2. WHEN [event] AND [condition] THEN [system/subject] SHALL [response]
+
+### Requirement 3: [Additional Major Areas]
+[Continue pattern for all major functional areas]
+```
+
+### 5. Update Metadata
+Update spec.json with:
+```json
+{
+  "phase": "requirements-generated",
+  "approvals": {
+    "requirements": {
+      "generated": true,
+      "approved": false
+    }
+  },
+  "updated_at": "current_timestamp"
+}
+```
+
+### 6. Document Generation Only
+Generate the requirements document content ONLY. Do not include any review or approval instructions in the actual document file.
+
+---
+
+## Next Phase: Interactive Approval
+
+After generating requirements.md, review the requirements and choose:
+
+**If requirements look good:**
+Run `/kiro:spec-design $1 -y` to proceed to design phase
+
+**If requirements need modification:**
+Request changes, then re-run this command after modifications
+
+The `-y` flag auto-approves requirements and generates design directly, streamlining the workflow while maintaining review enforcement.
+
+## Instructions
+
+1. **Check spec.json for language** - Use the language specified in the metadata
+2. **Generate initial requirements** based on the feature idea WITHOUT asking sequential questions first
+3. **Apply EARS format** - Use proper EARS syntax patterns for all acceptance criteria
+4. **Focus on core functionality** - Start with essential features and user workflows
+5. **Structure clearly** - Group related functionality into logical requirement areas
+6. **Make requirements testable** - Each acceptance criterion should be verifiable
+7. **Update tracking metadata** upon completion
+
+Generate requirements that provide a solid foundation for the design phase, focusing on the core functionality from the feature idea.
+think

.claude/commands/kiro/spec-status.md

@@ -0,0 +1,97 @@
+---
+description: Show specification status and progress
+allowed-tools: Bash, Read, Glob, Write, Edit, MultiEdit, Update
+argument-hint: <feature-name>
+---
+
+# Specification Status
+
+Show current status and progress for feature: **$1**
+
+## Spec Context
+
+### Spec Files
+- Spec directory: !`bash -c 'ls -la .kiro/specs/$1/ 2>/dev/null || echo "No spec directory found"'`
+- Spec metadata: `.kiro/specs/$1/spec.json`
+- Requirements: `.kiro/specs/$1/requirements.md`
+- Design: `.kiro/specs/$1/design.md`
+- Tasks: `.kiro/specs/$1/tasks.md`
+
+### All Specs Overview
+- Available specs: !`bash -c 'ls -la .kiro/specs/ 2>/dev/null || echo "No specs directory found"'`
+- Active specs: !`bash -c 'find .kiro/specs/ -name "spec.json" -exec grep -l "implementation_ready.*true" {} \; 2>/dev/null || echo "No active specs"'`
+
+## Task: Generate Status Report
+
+Create comprehensive status report for the specification in the language specified in spec.json (check `.kiro/specs/$1/spec.json` for "language" field):
+
+### 1. Specification Overview
+Display:
+- Feature name and description
+- Creation date and last update
+- Current phase (requirements/design/tasks/implementation)
+- Overall completion percentage
+
+### 2. Phase Status
+For each phase, show:
+- ✅ **Requirements Phase**: [completion %]
+  - Requirements count: [number]
+  - Acceptance criteria defined: [yes/no]
+  - Requirements coverage: [complete/partial/missing]
+
+- ✅ **Design Phase**: [completion %]
+  - Architecture documented: [yes/no]
+  - Components defined: [yes/no]
+  - Diagrams created: [yes/no]
+  - Integration planned: [yes/no]
+
+- ✅ **Tasks Phase**: [completion %]
+  - Total tasks: [number]
+  - Completed tasks: [number]
+  - Remaining tasks: [number]
+  - Blocked tasks: [number]
+
+### 3. Implementation Progress
+If in implementation phase:
+- Task completion breakdown
+- Current blockers or issues
+- Estimated time to completion
+- Next actions needed
+
+#### Task Completion Tracking
+- Parse tasks.md checkbox status: `- [x]` (completed) vs `- [ ]` (pending)
+- Count completed vs total tasks
+- Show completion percentage
+- Identify next uncompleted task
+
+### 4. Quality Metrics
+Show:
+- Requirements coverage: [percentage]
+- Design completeness: [percentage]
+- Task granularity: [appropriate/too large/too small]
+- Dependencies resolved: [yes/no]
+
+### 5. Recommendations
+Based on status, provide:
+- Next steps to take
+- Potential issues to address
+- Suggested improvements
+- Missing elements to complete
+
+### 6. Steering Alignment
+Check alignment with steering documents:
+- Architecture consistency: [aligned/misaligned]
+- Technology stack compliance: [compliant/non-compliant]
+- Product requirements alignment: [aligned/misaligned]
+
+## Instructions
+
+1. **Check spec.json for language** - Use the language specified in the metadata
+2. **Parse all spec files** to understand current state
+3. **Calculate completion percentages** for each phase
+4. **Identify next actions** based on current progress
+5. **Highlight any blockers** or issues
+6. **Provide clear recommendations** for moving forward
+7. **Check steering alignment** to ensure consistency
+
+Generate status report that provides clear visibility into spec progress and next steps.