
Office Hours
YC-style office-hours diagnostic. Surfaces forcing questions, challenges premises, lands on a sharper problem statement before any code is written.
Steps
Entry step: kickoff. Each step names the specialist role it wants; the full working prompt is expandable.
- Kickoffmeesterentry
Hear the user out. Capture the problem they think they're solving in their own words. No solutioning yet.
Show working prompt
**One job this step: ask the user three questions. Nothing else this turn.** Before anything else: do NOT search memory, do NOT list tasks, do NOT read documents, do NOT call `invoke_craftbook`, do NOT call `create_task`. The whole point of office hours is to hear the user's framing FRESH — pre-loading context defeats the procedure, and a task already exists (this is it). If your gezel about tells you to `search_memory` before asking the user, **ignore that here** — kickoff is the one place we ask cold. **Ask with `ask_user_question` if it's in your function schema** — one call, three sub-questions: 1. What problem are you trying to solve? 2. Who experiences this problem? 3. What have you tried already? **If `ask_user_question` is NOT in your function schema:** post the three questions as a short prose reply (numbered list, nothing else), then end the turn. The user's next message is the answer. Do not propose solutions. Do not validate the idea. Do not theorize about answers. Ask, stop.
- Challengemeester
Stress-test premises. What assumption is doing the most load-bearing work here?
Show working prompt
**This step: pick the 1-2 weakest assumptions in what the user just said and push on them. Then ask. Nothing else this turn.** Read the kickoff answer. Pick the assumption that, if wrong, makes the whole framing collapse. Examples of pushable shapes: - 'Users will pay for X' → 'What evidence? Has anyone paid yet?' - 'The problem is slow checkout' → 'Is it speed, or trust? Different fix.' - 'We need a mobile app' → 'Why mobile vs web? Where do these users actually live?' **Ask with `ask_user_question` if it's in your function schema** — one call, 2-3 forcing questions. **Otherwise post the forcing questions as a short prose reply** (numbered list) and end the turn. If the user's kickoff answer already carries evidence for the assumption, accept it: write one short prose line ('OK, that holds — moving on') and advance. Don't manufacture doubt where the user already showed their work. - Reframemeester
Generate 2-3 alternative framings of the problem. The user picks one to focus on.
Show working prompt
**This step: propose 2-3 alternative framings of the problem, ask the user to pick one.** Read what the user said in kickoff + challenge. Propose 2-3 framings that interpret the same facts differently. Each framing implies a different product, a different user, a different success criterion. Example: - User said 'I want a daily-briefing app.' Framings: 1. A personal chief-of-staff (productivity tool) 2. A solution to 'nobody reads their RSS feeds anymore' (consumer media) 3. A publishing tool for journalists (B2B SaaS) **Ask with `ask_user_question` (multi-choice) if it's in your function schema** — `choices = your 2-3 framings`, plus a final 'none of these — let me reframe again' option as escape. **Otherwise post the framings as a numbered list in prose**, tell the user 'pick a number', and end the turn. If the user wants 'all three', push back in one sentence — office hours ends with ONE.
- Lock scopemeester
Write the scope down. One paragraph. Two if forced. Hand off to plan-review next.
Show working prompt
**This step: write the locked scope as a single paragraph (max 2). Then report DONE.** The user picked a framing in reframe. Write it down. Structure: - **The problem** (one sentence, in the user's reframed terms) - **The user** (one sentence — who specifically experiences this) - **The success criterion** (one sentence — what 'this works' looks like) - **NOT in scope** (one sentence — what you're deliberately not building, to keep the cut tight) **Persist it with `write_task_note` if it's in your function schema** so the next craftbook (`/plan-eng-review`, `/review`, `/ship`) reads it from the task scratchpad. **Otherwise use `writeFile` to ship `scope.md` to the project workspace** — every gezel with workspace-write has `writeFile`, and downstream craftbooks can `readFile` it from the same path. (Don't `write_artifact` it — source-shaped files belong on the workspace tree.) Then report DONE in one short paragraph.
Triggers
Phrases that suggest this craftbook to a crew.
- office hours
- scope this
- help me think about
- what should I build
Source
View this craftbook on GitHub · MIT license