d4767ac2e0
* fix: replace /gsd: command format with /gsd- skill format in all suggestions All next-step suggestions shown to users were still using the old colon format (/gsd:xxx) which cannot be copy-pasted as skills. Migrated all occurrences across agents/, commands/, get-shit-done/, docs/, README files, bin/install.js (hardcoded defaults for claude runtime), and get-shit-done/bin/lib/*.cjs (generate-claude-md templates and error messages). Updated tests to assert new hyphen format instead of old colon format. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: migrate remaining /gsd: format to /gsd- in hooks, workflows, and sdk Addresses remaining user-facing occurrences missed in the initial migration: - hooks/: fix 4 user-facing messages (pause-work, update, fast, quick) and 2 comments in gsd-workflow-guard.js - get-shit-done/workflows/: fix 21 Skill() literal calls that Claude executes directly (installer does not transform workflow content) - sdk/prompt-sanitizer.ts: update regex to strip /gsd- format in addition to legacy /gsd: format; update JSDoc comment - tests/: update autonomous-ui-steps, prompt-sanitizer to assert new format Note: commands/gsd/*.md frontmatter (name: gsd:xxx) intentionally unchanged — installer derives skillName from directory path, not the name field. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix(plan-phase): preserve --chain flag in auto-advance sync and handle ui-phase gate in chain mode Bug 1: step 15 sync-flag check only guarded against --auto, causing _auto_chain_active to be cleared when plan-phase is invoked without --auto in ARGUMENTS even though a --chain pipeline was active. Added --chain to the guard condition, matching discuss-phase behaviour. Bug 2: UI Design Contract gate (step 5.6) always exited the workflow when UI-SPEC was missing, breaking the discuss --chain pipeline silently. When _auto_chain_active is true, the gate now auto-invokes gsd-ui-phase --auto via Skill() and continues to step 6 without prompting. Manual invocations retain the existing AskUserQuestion flow. * fix: remove <sub>/clear</sub> pattern and duplicate old-format command in discuss-phase.md --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
93 lines
3.0 KiB
Markdown
93 lines
3.0 KiB
Markdown
# 模型配置
|
||
|
||
模型配置控制每个 GSD 代理使用哪个 Claude 模型。这允许平衡质量和 token 消耗。
|
||
|
||
## 配置定义
|
||
|
||
| 代理 | `quality` | `balanced` | `budget` |
|
||
|-------|-----------|------------|----------|
|
||
| gsd-planner | opus | opus | sonnet |
|
||
| gsd-roadmapper | opus | sonnet | sonnet |
|
||
| gsd-executor | opus | sonnet | sonnet |
|
||
| gsd-phase-researcher | opus | sonnet | haiku |
|
||
| gsd-project-researcher | opus | sonnet | haiku |
|
||
| gsd-research-synthesizer | sonnet | sonnet | haiku |
|
||
| gsd-debugger | opus | sonnet | sonnet |
|
||
| gsd-codebase-mapper | sonnet | haiku | haiku |
|
||
| gsd-verifier | sonnet | sonnet | haiku |
|
||
| gsd-plan-checker | sonnet | sonnet | haiku |
|
||
| gsd-integration-checker | sonnet | sonnet | haiku |
|
||
| gsd-nyquist-auditor | sonnet | sonnet | haiku |
|
||
|
||
## 配置理念
|
||
|
||
**quality** - 最大推理能力
|
||
- 所有决策代理使用 Opus
|
||
- 只读验证使用 Sonnet
|
||
- 适用场景：有配额可用、关键架构工作
|
||
|
||
**balanced**（默认）- 智能分配
|
||
- 仅规划（架构决策发生的地方）使用 Opus
|
||
- 执行和研究使用 Sonnet（遵循明确指令）
|
||
- 验证使用 Sonnet（需要推理，不仅仅是模式匹配）
|
||
- 适用场景：正常开发、质量与成本的良好平衡
|
||
|
||
**budget** - 最小化 Opus 使用
|
||
- 编写代码的使用 Sonnet
|
||
- 研究和验证使用 Haiku
|
||
- 适用场景：节省配额、大量工作、不太关键的阶段
|
||
|
||
## 解析逻辑
|
||
|
||
编排器在生成代理前解析模型：
|
||
|
||
```
|
||
1. 读取 .planning/config.json
|
||
2. 检查 model_overrides 是否有代理特定覆盖
|
||
3. 如果没有覆盖，在配置表中查找代理
|
||
4. 将 model 参数传递给 Task 调用
|
||
```
|
||
|
||
## 单代理覆盖
|
||
|
||
覆盖特定代理而不更改整个配置：
|
||
|
||
```json
|
||
{
|
||
"model_profile": "balanced",
|
||
"model_overrides": {
|
||
"gsd-executor": "opus",
|
||
"gsd-planner": "haiku"
|
||
}
|
||
}
|
||
```
|
||
|
||
覆盖优先于配置。有效值：`opus`、`sonnet`、`haiku`。
|
||
|
||
## 切换配置
|
||
|
||
运行时：`/gsd-set-profile <profile>`
|
||
|
||
项目默认值：在 `.planning/config.json` 中设置：
|
||
```json
|
||
{
|
||
"model_profile": "balanced"
|
||
}
|
||
```
|
||
|
||
## 设计理由
|
||
|
||
**为什么 gsd-planner 使用 Opus？**
|
||
规划涉及架构决策、目标分解和任务设计。这是模型质量影响最大的地方。
|
||
|
||
**为什么 gsd-executor 使用 Sonnet？**
|
||
执行者遵循明确的 PLAN.md 指令。计划已包含推理；执行只是实现。
|
||
|
||
**为什么 balanced 中验证器使用 Sonnet（而非 Haiku）？**
|
||
验证需要目标回溯推理 —— 检查代码是否**交付**了阶段承诺的内容，而不仅仅是模式匹配。Sonnet 处理得很好；Haiku 可能会遗漏细微的差距。
|
||
|
||
**为什么 gsd-codebase-mapper 使用 Haiku？**
|
||
只读探索和模式提取。不需要推理，只需从文件内容输出结构化结果。
|
||
|
||
**为什么用 `inherit` 而不是直接传递 `opus`？**
|
||
Claude Code 的 `"opus"` 别名映射到特定模型版本。组织可能阻止旧版 opus 而允许新版。GSD 为 opus 级代理返回 `"inherit"`，使其使用用户在会话中配置的任何 opus 版本。这避免了版本冲突和静默回退到 Sonnet。 |