Invoking Kimi CLI (via Opencode)

Delegate testing, quality assurance, and code review tasks to Opencode CLI using the Kimi K2.5 model via markdown files for input and output.

Pattern: Markdown File Handoff

Claude Code                         Opencode CLI + Kimi K2.5
    |                                   |
    +-- Write TASK.md ------------------+
    |   (test/review requirements)      |
    |                                   |
    +-- Execute: opencode run -m        |
    |   opencode/kimi-k2.5-free         |
    |   "Read TASK.md..."               |
    |                                   |
    |                                   +-- Reads TASK.md
    |                                   +-- Generates tests/review
    |                                   +-- Writes OUTPUT.md
    |                                   |
    +-- Read OUTPUT.md <----------------+
    |   (tests + findings + results)    |
    v                                   v

Benefits:

• No shell escaping issues
• Full context in structured format
• Explicit output structure
• Supports both Opencode and Together.ai providers
• Excellent for edge case detection

When to Use

• Test generation - Create comprehensive test suites for existing code
• Test coverage analysis - Identify gaps in test coverage
• Edge case detection - Find boundary conditions and edge cases
• QA verification - Validate implementations meet requirements
• Code review - Secondary opinion on code quality and correctness
• Regression testing - Generate regression test scenarios
• Integration testing - Validate component interactions
• Security reviews - Security-focused code analysis

Model Selection

Recommended Models

opencode/kimi-k2.5-free

opencode/kimi-k2.5

togetherai/moonshotai/Kimi-K2.5

togetherai/moonshotai/Kimi-K2-5

Default:

opencode/kimi-k2.5-free

Recommendation: Use

opencode/kimi-k2.5-free

• Identifying edge cases and boundary conditions
• Generating comprehensive test scenarios
• Analyzing code for quality issues
• Providing thorough code reviews

Provider Selection Guide

Choose Opencode (

opencode/kimi-k2.5-free

) when:

• ✅ You want a free tier with generous limits (2,000 req/day)
• ✅ You're already using Opencode for other tasks
• ✅ You prefer integrated billing with Opencode
• ✅ You want simpler setup (no additional API keys)

Choose Together.ai (

togetherai/moonshotai/Kimi-K2.5

) when:

• ✅ You have existing Together.ai credits or API keys
• ✅ You need different rate limits or pricing
• ✅ You prefer Together.ai's infrastructure
• ✅ You're already using Together.ai for other models

Invocation

Standard Pattern (Recommended)

opencode run -m opencode/kimi-k2.5-free \
  "Read TASK.md in the current directory. Follow the testing instructions. Write all results to OUTPUT.md."

Alternative: Together.ai Provider

opencode run -m togetherai/moonshotai/Kimi-K2.5 \
  "Read TASK.md in the current directory. Follow the testing instructions. Write all results to OUTPUT.md."

Interactive Mode (if run command has issues)

# Start opencode TUI with Kimi K2.5 (Opencode)
cd /path/to/project && opencode . -m opencode/kimi-k2.5-free

# Or with Together.ai
cd /path/to/project && opencode . -m togetherai/moonshotai/Kimi-K2.5

Piping Input (Most Reliable)

# Create a prompt file
echo "Generate unit tests for the Calculator class" > prompt.txt
cat prompt.txt | opencode run -m opencode/kimi-k2.5-free

Core Flags Reference

-m, --model

opencode/kimi-k2.5-free

-C, --continue

-s, --session

--prompt

-h, --help

Task File Template (TASK.md)

# Task: [Test Generation / Code Review / QA]

## Objective
[Clear statement of testing/review goal]

### Examples:
- Generate unit tests for user authentication module
- Review payment processing code for security issues
- Create integration tests for API endpoints
- Perform QA verification of search functionality

## Code to Test/Review

### File: src/auth/login.ts
```typescript
// Paste code here

File: src/auth/validate.ts

// Paste supporting code

Requirements

Test Requirements (if generating tests)

• Cover all public methods/functions
• Include happy path scenarios
• Include error/edge cases
• Test boundary conditions
• Mock external dependencies
• Achieve >80% code coverage

Review Criteria (if reviewing code)

Rate findings: CRITICAL | HIGH | MEDIUM | LOW

Security

• Input validation gaps
• Authentication/authorization issues
• Data exposure risks

Reliability

• Error handling coverage
• Race conditions
• Resource leaks

Maintainability

• Testability of code
• Code clarity
• Documentation

Test Framework

• Framework: Jest / Mocha / Vitest / pytest / etc.
• Location:

  tests/

  or

  __tests__/

  directory
• Naming:

  [filename].test.[ext]

  or

  [filename].spec.[ext]

Context

• [Any relevant background, constraints, or requirements]
• [Dependencies or integrations]
• [Performance requirements]
• [Compliance needs]

Output Format

Write to OUTPUT.md:

• Summary of tests generated or review findings
• Test scenarios/cases with descriptions
• File locations for generated tests
• Coverage analysis (if applicable)
• Issues found with severity ratings
• Recommendations for fixes
• Session ID for follow-up

## Output File Template (OUTPUT.md)

Opencode with Kimi K2.5 should produce:

```markdown
# Results: [Task Title]

## Summary
[Brief overview of what was accomplished]

## Generated Tests (if applicable)

### Test Files Created
| File | Description | Coverage |
|------|-------------|----------|
| `tests/auth/login.test.ts` | Unit tests for login | 95% |
| `tests/auth/validate.test.ts` | Validation tests | 88% |

### Test Scenarios

#### Happy Path
1. [Test case description]
   - Input: [example input]
   - Expected: [expected output]

#### Edge Cases
1. [Edge case description]
   - Input: [boundary value]
   - Expected: [expected behavior]

#### Error Cases
1. [Error scenario]
   - Input: [invalid input]
   - Expected: [error handling]

## Review Findings (if applicable)

| Severity | Location | Issue | Recommendation |
|----------|----------|-------|----------------|
| CRITICAL | login.ts:45 | SQL injection | Use parameterized queries |
| HIGH | auth.ts:23 | Missing rate limiting | Add rate limiter |
| MEDIUM | users.ts:78 | No input validation | Add Zod validation |
| LOW | utils.ts:12 | Magic number | Extract constant |

## Code Coverage Analysis
- **Overall:** 87%
- **Critical paths:** 95%
- **Uncovered lines:** [list of uncovered code sections]

## Issues Encountered
- [Any problems and resolutions]

## Recommendations
1. [Priority action items]
2. [Secondary improvements]
3. [Testing best practices to adopt]

## Session
Session ID: `<session_id>` (for follow-up)

Workflow Example

Example 1: Test Generation

1. Claude Code writes TASK.md

# Task: Generate Unit Tests for User Authentication

## Objective
Create comprehensive unit tests for the user authentication module covering login, registration, and password reset.

## Code to Test

### File: src/auth/auth.service.ts
```typescript
export class AuthService {
  async login(email: string, password: string): Promise<AuthResult> {
    const user = await this.userRepo.findByEmail(email);
    if (!user) throw new UnauthorizedError('Invalid credentials');
    
    const valid = await bcrypt.compare(password, user.passwordHash);
    if (!valid) throw new UnauthorizedError('Invalid credentials');
    
    const token = jwt.sign({ userId: user.id }, process.env.JWT_SECRET);
    return { token, user: this.sanitizeUser(user) };
  }
  
  async register(email: string, password: string): Promise<User> {
    const existing = await this.userRepo.findByEmail(email);
    if (existing) throw new ConflictError('Email already exists');
    
    const hash = await bcrypt.hash(password, 10);
    return this.userRepo.create({ email, passwordHash: hash });
  }
}

Requirements

Test Requirements

• Test successful login with valid credentials
• Test login failure with invalid email
• Test login failure with wrong password
• Test successful registration
• Test registration with existing email
• Test JWT token generation
• Mock database repository
• Mock bcrypt and jwt

Test Framework

• Framework: Jest
• Location:

  tests/auth/

• Mocking: jest.mock()

Context

• Application uses TypeScript
• JWT tokens expire in 24 hours
• Passwords must be hashed with bcrypt (10 rounds)
• Database is PostgreSQL via TypeORM

Output Format

Write to OUTPUT.md with test scenarios, generated test code, coverage analysis, and any edge cases identified.

#### 2. Execute Opencode with Kimi K2.5

```bash
opencode run -m opencode/kimi-k2.5-free \
  "Read TASK.md in the current directory. Follow the instructions to generate comprehensive unit tests. Write all results to OUTPUT.md."

3. Claude Code reads OUTPUT.md

Review the generated tests, check coverage, and integrate into the test suite.

Example 2: Code Review

1. Claude Code writes TASK.md

# Task: Security Review of Payment Processing

## Objective
Perform security-focused code review of payment processing module.

## Code to Review

### File: src/payments/payment.service.ts
[Code here...]

## Review Criteria
Rate findings: CRITICAL | HIGH | MEDIUM | LOW

### Security Focus
- Input validation
- SQL injection risks
- Authentication/authorization
- Sensitive data handling
- PCI compliance

## Context
- B2B SaaS application
- Handles credit card data
- SOC2 compliance required

## Output Format
Write security findings to OUTPUT.md with severity ratings and specific fix recommendations.

2. Execute Opencode with Kimi K2.5

opencode run -m opencode/kimi-k2.5-free \
  "Read TASK.md, perform security review following the criteria, write findings to OUTPUT.md"

3. Review Findings

Claude Code reads OUTPUT.md and addresses security issues.

Environment Variables

# For Opencode provider (Moonshot AI)
MOONSHOT_API_KEY=xxx      # Kimi models via Opencode (if needed)

# For Together.ai provider
TOGETHER_API_KEY=xxx      # Kimi models via Together.ai

# Alternative providers
OPENAI_API_KEY=xxx        # OpenAI models
GEMINI_API_KEY=xxx        # Google Gemini models

Note: Set the appropriate API key for your chosen provider. Opencode will use the key matching the model provider prefix (e.g.,

togetherai/*

TOGETHER_API_KEY

Rate Limits

Opencode (Moonshot AI)

Together.ai

Note: Together.ai rate limits depend on your account tier. Check your Together.ai dashboard for current limits.

Quick Reference Table

opencode/kimi-k2.5-free

opencode/kimi-k2.5

togetherai/moonshotai/Kimi-K2.5

TOGETHER_API_KEY

*Opencode may use built-in credits or require authentication via

opencode auth

Comparison: When to Use Kimi vs Gemini vs Codex

Legend:

• ✅ = Excellent choice
• ⚠️ = Viable but not optimal

Decision Guide

Use Kimi K2.5 (via Opencode/Together.ai) when:

• Primary goal is generating comprehensive test suites
• You need thorough edge case identification
• QA verification of existing implementations
• Security-focused code reviews
• Testing TypeScript/JavaScript/Python code
• Free tier with generous limits (2,000 req/day via Opencode)

Use Gemini (via Gemini CLI) when:

• Code review is the primary goal (not test generation)
• You need 1M+ token context for large codebase analysis
• Documentation review and knowledge extraction
• Security audits without test generation
• Maximum context window needed

Use Codex (via Codex CLI) when:

• Primary goal is implementation or refactoring
• Test generation is secondary to code changes
• Complex multi-file modifications needed
• Heavy reasoning tasks beyond testing

Integration with Other Skills

Works well with:

• dev_invoke_gemini-cli

  - Cross-verify test coverage with Gemini

• dev_invoke_codex-cli

  - Implement fixes after Kimi identifies issues

• using-git-worktrees

  - Create isolated workspace for test development

• triple-model-code-review

  - Multi-model validation

Sequence example:

1. Kimi K2.5: Generate tests → Identify uncovered edge cases
2. Codex: Implement missing edge case handling
3. Kimi K2.5: Verify fixes and regenerate tests
4. Gemini: Review final implementation

Tips

1. Include full code - Paste actual code in TASK.md, don't just reference files
2. Specify test framework - Tell Opencode exactly which framework to use
3. Define coverage targets - Set clear coverage expectations
4. List edge cases explicitly - Ask Kimi K2.5 to identify additional edge cases
5. Request specific output - Define exactly what OUTPUT.md should contain
6. Use full model path - Use

   opencode/kimi-k2.5-free

   not just

   kimi-k2.5

7. Mock external dependencies - Remind Opencode to mock databases, APIs, etc.
8. Test data examples - Provide sample inputs/outputs for clarity
9. Try piping input - If

   run

   command fails, use

   cat prompt.txt | opencode run ...

10. Use interactive mode - Start with

    opencode . -m <model>

    for complex tasks

Troubleshooting

Issue: "Session not found" error

Solution: Use interactive mode instead:

opencode . -m opencode/kimi-k2.5-free

Issue: "DecimalError" with Together.ai

Solution: This is cosmetic - the output is still generated. Use the interactive mode or piping method.

Issue: API key errors

Solution: Set the appropriate environment variable:

export TOGETHER_API_KEY=your_key_here
# or
export MOONSHOT_API_KEY=your_key_here

Session Management

• Use

  opencode --continue

  to resume last session
• Use

  opencode -s <session_id>

  to resume specific session
• Sessions are stored locally by Opencode
• Session IDs appear in OUTPUT.md for reference