mirror of
https://github.com/garrytan/gstack.git
synced 2026-06-19 08:10:08 +02:00
Garry Tan
b5c65c70cc
The /plan-eng-review skill failed to fire AskUserQuestion on a real plan review and surfaced 4 calibration decisions via prose instead. Investigation traced this to a "fallback when neither variant is callable" clause in the preamble that the model rationalizes around as a general escape hatch from "fanning out round-trip AUQs," even when an AUQ variant IS callable. Codex review confirmed the fallback exists in 8 inline sites with 2 surviving escape hatches the original narrowing missed (a "genuinely trivial" exception duplicated across all 4 plan-* templates, and a "outside plan mode, output as prose and stop" branch in the preamble itself). Net deletion in skill text. Closes both branches of the deleted fallback (plan-file write AND prose-and-stop) and the trivial-fix exception with a single hard rule: If no AskUserQuestion variant appears in your tool list, this skill is BLOCKED. Stop, report `BLOCKED — AskUserQuestion unavailable`, and wait for the user. Honest about being a model directive, not a runtime guard — none of the PTY harness helpers enforce BLOCKED today. The architectural improvement is that the model has fewer alternatives to obey it against. Runtime enforcement is a follow-up TODO. Sources changed: - scripts/resolvers/preamble/generate-ask-user-format.ts: delete both fallback branches; replace with 1-line BLOCKED rule - scripts/resolvers/preamble/generate-completion-status.ts: delete fallback in generatePlanModeInfo - plan-eng-review/SKILL.md.tmpl: delete fallback at Step 0 + Sections 1-4 (5 instances) + delete trivial-fix exception - office-hours/SKILL.md.tmpl: delete fallback in approach-selection - plan-ceo-review/SKILL.md.tmpl: delete trivial-fix exception - plan-design-review/SKILL.md.tmpl: delete trivial-fix exception - plan-devex-review/SKILL.md.tmpl: delete trivial-fix exception Generated SKILL.md regen lands in a follow-up commit per the bisect convention (template changes separate from regenerated output). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
63 lines
3.5 KiB
TypeScript
63 lines
3.5 KiB
TypeScript
import type { TemplateContext } from '../types';
|
|
|
|
export function generateAskUserFormat(_ctx: TemplateContext): string {
|
|
return `## AskUserQuestion Format
|
|
|
|
### Tool resolution (read first)
|
|
|
|
"AskUserQuestion" can resolve to two tools at runtime: the **host MCP variant** (e.g. \`mcp__conductor__AskUserQuestion\` — appears in your tool list when the host registers it) or the **native** Claude Code tool.
|
|
|
|
**Rule:** if any \`mcp__*__AskUserQuestion\` variant is in your tool list, prefer it. Hosts may disable native AUQ via \`--disallowedTools AskUserQuestion\` (Conductor does, by default) and route through their MCP variant; calling native there silently fails. Same questions/options shape; same decision-brief format applies.
|
|
|
|
**If no AskUserQuestion variant appears in your tool list, this skill is BLOCKED.** Stop, report \`BLOCKED — AskUserQuestion unavailable\`, and wait for the user. Do not write decisions to the plan file as a substitute, do not emit them as prose and stop, and do not silently auto-decide (only \`/plan-tune\` AUTO_DECIDE opt-ins authorize auto-picking).
|
|
|
|
### Format
|
|
|
|
Every AskUserQuestion is a decision brief and must be sent as tool_use, not prose.
|
|
|
|
\`\`\`
|
|
D<N> — <one-line question title>
|
|
Project/branch/task: <1 short grounding sentence using _BRANCH>
|
|
ELI10: <plain English a 16-year-old could follow, 2-4 sentences, name the stakes>
|
|
Stakes if we pick wrong: <one sentence on what breaks, what user sees, what's lost>
|
|
Recommendation: <choice> because <one-line reason>
|
|
Completeness: A=X/10, B=Y/10 (or: Note: options differ in kind, not coverage — no completeness score)
|
|
Pros / cons:
|
|
A) <option label> (recommended)
|
|
✅ <pro — concrete, observable, ≥40 chars>
|
|
❌ <con — honest, ≥40 chars>
|
|
B) <option label>
|
|
✅ <pro>
|
|
❌ <con>
|
|
Net: <one-line synthesis of what you're actually trading off>
|
|
\`\`\`
|
|
|
|
D-numbering: first question in a skill invocation is \`D1\`; increment yourself. This is a model-level instruction, not a runtime counter.
|
|
|
|
ELI10 is always present, in plain English, not function names. Recommendation is ALWAYS present. Keep the \`(recommended)\` label; AUTO_DECIDE depends on it.
|
|
|
|
Completeness: use \`Completeness: N/10\` only when options differ in coverage. 10 = complete, 7 = happy path, 3 = shortcut. If options differ in kind, write: \`Note: options differ in kind, not coverage — no completeness score.\`
|
|
|
|
Pros / cons: use ✅ and ❌. Minimum 2 pros and 1 con per option when the choice is real; Minimum 40 characters per bullet. Hard-stop escape for one-way/destructive confirmations: \`✅ No cons — this is a hard-stop choice\`.
|
|
|
|
Neutral posture: \`Recommendation: <default> — this is a taste call, no strong preference either way\`; \`(recommended)\` STAYS on the default option for AUTO_DECIDE.
|
|
|
|
Effort both-scales: when an option involves effort, label both human-team and CC+gstack time, e.g. \`(human: ~2 days / CC: ~15 min)\`. Makes AI compression visible at decision time.
|
|
|
|
Net line closes the tradeoff. Per-skill instructions may add stricter rules.
|
|
|
|
### Self-check before emitting
|
|
|
|
Before calling AskUserQuestion, verify:
|
|
- [ ] D<N> header present
|
|
- [ ] ELI10 paragraph present (stakes line too)
|
|
- [ ] Recommendation line present with concrete reason
|
|
- [ ] Completeness scored (coverage) OR kind-note present (kind)
|
|
- [ ] Every option has ≥2 ✅ and ≥1 ❌, each ≥40 chars (or hard-stop escape)
|
|
- [ ] (recommended) label on one option (even for neutral-posture)
|
|
- [ ] Dual-scale effort labels on effort-bearing options (human / CC)
|
|
- [ ] Net line closes the decision
|
|
- [ ] You are calling the tool, not writing prose
|
|
`;
|
|
}
|