Files
CLI-Anything/skills
kk be964a5f25 feat(minimax tts): expose all voice/audio parameters on the tts subcommand (#360)
* # feat(minimax tts): expose all voice/audio parameters on the tts subcommand

## Summary

The MiniMax TTS backend (`cli_anything/minimax/utils/minimax_backend.py`)
already supported a full set of voice and audio parameters, but the CLI
exposed only `--text`, `--model`, `--voice`, and `--output`. Every other
field was hardcoded, so users had to fork the harness to change speech
speed, volume, pitch, sample rate, bitrate, audio format, or channel
layout.

This change promotes all seven hardcoded parameters to first-class CLI
options on the `tts` subcommand, with click-level range and choice
validation, and adds a regression test module.

## What changed

### `cli_anything/minimax/utils/minimax_backend.py`
- `tts_synthesize(...)` gains 7 new parameters: `speed`, `vol`, `pitch`,
  `sample_rate`, `bitrate`, `audio_format`, `channel`.
- The hardcoded `voice_setting` and `audio_setting` blocks now read from
  the new parameters. Defaults match the previous hardcoded values, so
  the change is fully backward compatible at the API level.

### `cli_anything/minimax/minimax_cli.py`
- The `tts` Click command gains 7 new options:
  - `--speed` (FloatRange 0.5..2.0, default 1.0)
  - `--vol` (FloatRange 0.0..10.0, default 1.0)
  - `--pitch` (IntRange -12..12, default 0)
  - `--sample-rate` (Choice: 8000/16000/22050/24000/32000/44100, default 32000)
  - `--bitrate` (Choice: 32000/64000/128000/256000, default 128000)
  - `--format` (Choice: mp3/pcm/flac, default mp3)
  - `--channel` (Choice: 1/2, default 1)
- The `tts_synthesize(...)` call is updated to forward the new options.

### `cli_anything/minimax/tests/test_tts_extended.py` (new)
- 4 mock-based tests:
  - `test_tts_default_voice_audio_settings` — guards backward-compatible defaults
  - `test_tts_custom_voice_setting` — speed / vol / pitch propagation
  - `test_tts_custom_audio_setting` — sample_rate / bitrate / format / channel
  - `test_tts_voice_id_propagates` — regression guard for voice + speed combo

## Verification

```bash
# Apply patches (from repo root)
patch -p0 < pr-minimax-tts/01-backend.patch
patch -p0 < pr-minimax-tts/02-cli.patch
cp pr-minimax-tts/03-tests-test_tts_extended.py \
   cli_anything/minimax/tests/test_tts_extended.py

# Run the new tests
cd minimax/agent-harness
PYTHONPATH=. python3 -m pytest cli_anything/minimax/tests/test_tts_extended.py -v
# 4 passed

# Inspect the new surface
PYTHONPATH=. python3 -m cli_anything.minimax.minimax_cli tts --help
```

## Backward compatibility

- API call signature gains keyword-only-ish params with default values
  identical to the previous hardcoded values, so any existing caller of
  `tts_synthesize(api_key, text, model, voice, output_path)` keeps
  working unchanged.
- CLI behavior is unchanged when none of the new options are passed.

## Related

- Skill surfaces this command under `cli-anything-minimax tts` —
  `skills/cli-anything-minimax/SKILL.md` should mention the new flags
  in a follow-up doc pass.

* docs(minimax): document new tts options in README and SKILL.md

Companion to #360. Surfaces the new --speed/--vol/--pitch/--sample-rate/
--bitrate/--format/--channel flags in both:
- minimax/agent-harness/cli_anything/minimax/README.md (TTS options table)
- skills/cli-anything-minimax/SKILL.md (TTS options block)

No code change; just user-facing doc sync.

---------

Co-authored-by: hhdhh <hhdhh@users.noreply.github.com>
2026-07-09 20:13:36 +08:00
..
2026-04-18 11:53:57 +00:00

CLI-Anything Skills

This directory is the canonical npx skills surface for in-repo CLI-Anything harnesses.

Layout:

skills/
  cli-anything-audacity/SKILL.md
  cli-anything-blender/SKILL.md
  ...

Typical usage:

npx skills add HKUDS/CLI-Anything --list
npx skills add HKUDS/CLI-Anything --skill cli-anything-audacity -g -y

The SKILL.md files here are the canonical repo-root copies. Installed harness packages still ship compatibility copies inside cli_anything/<software>/skills/ for local runtime discovery.

CI rule:

  • If a harness keeps a deep packaged SKILL.md, it must also have a matching repo-root skills/<skill-id>/SKILL.md.
  • A future harness that only defines its canonical skill directly in skills/ is also valid.