Skip to main content

tune-magic-compose

Fill in and tune the Magic Compose plugin's model rotation, model instructions, and allowed effort levels from the user's own history of model and effort choices. Use when the user asks to set up, auto-fill, or tune Magic Compose's model preferences.

소스 정보

저장소
SawyerHood/sawyer-plugins
최근 소스 활동
2026년 9월 18일 22:50
감지된 SKILL.md 언어
영어
스타
19
포크
7

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
tune-magic-compose
description
Fill in and tune the Magic Compose plugin's model rotation, model instructions, and allowed effort levels from the user's own history of model and effort choices. Use when the user asks to set up, auto-fill, or tune Magic Compose's model preferences.
# Tune Magic Compose's model preferences Magic Compose asks Jev, a fast classifier model, which model and reasoning effort each new prompt should get. Jev chooses among the models in the user's **rotation**, guided by a note on each model and by the **model instructions**. This skill writes those from how the user has actually been choosing, then checks the result against their history. Read `skills/magic-compose/SKILL.md` for the routing commands. Everything you write here lands in the user's BB settings, never in a repository. ## 1. Look at what the user picks ```sh bb magic-compose history --days 14 # counts per model and effort bb magic-compose history --days 14 --json # plus every thread's prompt ``` Only threads the user started from a composer are counted; review bots, automations, and Magic Compose's own dispatches are left out. Add `--include-origin <plugin-id>` for another plugin whose threads the user starts by hand. Go back further (`--days 30`) if there are fewer than about 100 threads. Show the user the counts, then settle two things with them before going on, in one question if you can: - **Which models belong in the rotation.** Usually the two to four they use most. Preview, retired, or one-off models do not. - **Whether some picks should count as another model.** Someone trialling a preview model would normally have used their regular strong model instead. Note each such mapping as `<regex on the model id>=<rotation model id>`. ## 2. Find what separates the groups Read the prompts group by group: each model, then each effort within it. Look for what kind of task lands in a group, in the user's own words. Two things make this history noisier than it looks. Say so when you report, and do not chase them: - **The pickers are sticky.** The composer remembers the last model and effort, so many picks are whatever was left selected. The same kind of task, such as approving a contributor, will show up at low, medium, and high. The deliberate signal is where a group is consistent, and where the user moved *away* from their default. - **Model of the day.** A day spent trying a model puts ordinary tasks on it. A model's share swinging between days is that, not routing by task. Count a few obvious categories (slash commands, PR reviews by link, "mock up", "fix this issue" with a link, new plugin or app from scratch) per model to see where the split is real. ## 3. Write the rotation and the instructions Jev reads literally and does not reason in steps. Write for that: - Short, concrete sentences. Quote the user's own phrasings as examples ("mock up", "is this safe to land?", `/approve-contributor`). - State the default outright: "X is my default. Pick it unless the task clearly matches Y." Give rough shares ("about three in five of my tasks"). - Say what does *not* decide it, if the history shows that: "The length of the prompt does not set the effort." - Effort usually depends on the model. Say each model's default effort, then what moves a task up or down from it. - Name any level the user never uses: "Never pick max." Each **rotation note** (at most 600 characters) says when to use that model; Jev sees it as the option's description. The **model instructions** (at most 4,000 characters) hold the rules for choosing the model and the effort, under two plain headings, since Jev reads them for both questions. Save what is there now before replacing it, so the user can go back: ```sh bb magic-compose rotation get --json > "$BB_THREAD_STORAGE/rotation.before.json" bb magic-compose preferences get --json > "$BB_THREAD_STORAGE/preferences.before.json" ``` Then apply: ```sh bb magic-compose rotation set "$(cat rotation.json)" bb magic-compose preferences set modelInstructions "$(cat model-instructions.txt)" ``` `rotation.json` is a list of `{"providerId", "model", "note", "reasoningLevel"}`. Take `providerId` and `model` exactly as `bb provider models <provider-id> --json` spells them. `reasoningLevel` is only a fallback for a model that offers no choice of effort; set it to that model's default. The effort levels Jev may pick are a separate setting, a hard limit rather than advice. Leave it alone unless the user never uses a level it allows. **Never turn on `ultra` or `ultracode` unless the user asks for it**: they are costly run modes, and they start off for that reason. To change the list: ```sh echo '{"scope":{"reasoningLevels":["low","medium","high","xhigh"]}}' > levels.json bb plugin rpc call magic-compose scope_set --input-file levels.json ``` ## 4. Backtest This sends the user's past prompts to Jev through their gateway. Tell them so and get a yes first. Use `--exclude` to keep out anything that should not leave the machine, such as unreleased product or model names. ```sh bb magic-compose backtest --days 14 \ --map '<regex>=<rotation model id>' \ --exclude '<regex>' --json ``` It routes each distinct past prompt with the current rotation and instructions and reports, for model and for effort, how often Jev agreed with the user, beside what always picking their favourite would score, plus confusion tables and up to 80 disagreements. A few hundred prompts take about fifteen seconds and cost well under a cent. Read the disagreements before the percentages: - Where Jev is *consistent* and the user was not (the same chore at three efforts), Jev is following the rule. Leave it. - Where a whole category goes the wrong way, fix the rule that covers it, with one more example in the user's words, and run the backtest again. Stop after one or two rounds. Agreement well above the favourite-model baseline is a good result; the sticky pickers cap how high it can go, and rules bent to fit the noise route new prompts worse. Expect effort to land within one level far more often than exactly. ## 5. Report Tell the user, plainly: - what the rotation and the instructions now say, and that both are ordinary settings under Settings → Magic Compose that they can edit; - the agreement numbers next to the baselines, including any that did not beat the baseline, and why the history limits them; - which judgment calls were yours rather than the history's; - where the previous settings were saved. Spot-check a handful of fresh prompts with `bb magic-compose route "<prompt>"` before you finish. It starts nothing.
GitHub에서 보기