office-hours: Conductor sessions never ask the forcing questions — prose fallback is decision-brief-only, so open-ended skill questions have no legal form
- Dominant language
- TypeScript
- Stars
- 133k
- Forks
- 19.9k
- Avg merge
- 18h 46m
- Merged PRs (30d)
- 26
Description
**gstack v1.72.0.0 · Claude Code inside Conductor · macOS**
### Summary
In a Conductor session, `/office-hours` never asks the six forcing questions. Not "asks them badly" — never emits them at all. Same for Phase 2B's generative questions. The skill still produces a design doc and runs the tiered handoff, so from the outside it looks like it ran.
The cause is a collision between two rules that are each correct on their own:
1. `office-hours/sections/phase-2a-startup-diagnostic.md` — "Ask these questions **ONE AT A TIME** via AskUserQuestion."
2. `office-hours/SKILL.md` → `## AskUserQuestion Format` → *Tool resolution*, branch 1 — "`CONDUCTOR_SESSION: true` → do **NOT** call AskUserQuestion at all … render EVERY decision brief as the **prose form** below and STOP."
3. Same file, `### Format` — "**Every** AskUserQuestion is a decision brief": `D` title, ELI10, Stakes, `Recommendation:`, `Completeness: X/10`, A/B/C/D options with ✅/❌ bullets.
The forcing questions are open-ended and have no option set. "Name the actual human who needs this most. What's their title? What gets them fired?" cannot be rendered as a `D` brief with per-option completeness scores. So in Conductor the model is told never to call the tool, and the only sanctioned prose output has a shape the question does not fit. The conversation phase silently drops and the run proceeds straight to the deliverable.
This is **not** the hook breakage in #2207 / #2340 / #2320 — those are about AUQ failing to render. Here the Conductor prose path works exactly as documented; the gap is that the documented prose form only covers decision briefs.
### Evidence
Measured across 22 `/office-hours` runs in Conductor sessions:
| Measure | Count |
|---|---|
| Exact `Skill(skill="office-hours")` invocations | **22** |
| Assistant-emitted messages containing any of the six forcing questions verbatim | **0** |
| `AskUserQuestion` calls inside those 22 runs | **0** |
Phase 2A has carried this instruction since v0.18.1.0 (2026-04-16), so the collision predates the section carve in v1.71.0.0. Re-checked on v1.78.0.0: `phase-2a-startup-diagnostic.md:71` and `SKILL.md:113` are unchanged and the behaviour persists.
### Suggested fix
Add an **open-question prose form** next to the decision brief in `## AskUserQuestion Format`, and have Phase 2A/2B cite it explicitly:
```
Q —
Why I'm asking: <1-2 sentences: the stakes, what a weak answer would mean>
What a strong answer sounds like:
Reply in your own words — I'll wait.
```
…then STOP and wait, with the same end-of-turn semantics as the decision-brief prose form (including satisfying plan mode). Then change Phase 2A/2B from "via AskUserQuestion" to "via AskUserQuestion, or the open-question prose form when AskUserQuestion is unavailable — which is always the case in Conductor."
Two smaller adjacent gaps:
- `## Section self-check` verifies *"did you Read the section"* but not *"did you actually ask."* A cheap addition: "if you emitted zero questions in Phase 2A/2B, the diagnostic did not run — say so explicitly in the completion summary rather than presenting the design doc as a completed office-hours session."
- Consider recording a `questions_asked` count in `gstack-developer-profile --log-session`, so a skipped diagnostic shows up in the builder profile instead of being invisible.
Implemented in #2729 (open).
Contributor guide
Research direction
Start with office-hours/SKILL.md, office-hours/sections/phase-2a-startup-diagnostic.md, and the Phase 2B section, then review the implementation noted in #2729. Verify that Conductor sessions emit and wait for open-ended questions through the prose fallback, while decision briefs retain their existing format and skipped-question checks are reported.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 25/100