garrytan / garrytan/gstack

office-hours: Conductor sessions never ask the forcing questions — prose fallback is decision-brief-only, so open-ended skill questions have no legal form

Open
#2,719 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.