Tutorial Overview

Series index: gstack Tutorial Series

/office-hours is the entry point for every gstack sprint. Its core idea: understand the problem thoroughly before writing any code.

What you will learn

• ✅ The six forcing questions that reframe products
• ✅ When /office-hours triggers
• ✅ The Socratic questioning workflow
• ✅ How design docs feed into downstream skills
• ✅ Real-world reframing examples

Why Office Hours?

The problem with jumping to code

flowchart LR
    A[Vague idea] --> B[AI writes code]
    B --> C[Realizes misunderstanding]
    C --> D[Rewrites code]
    D --> E[Another misunderstanding]
    E --> F[Multiple iterations]

    style B fill:#ffcccc
    style C fill:#ffcccc
    style D fill:#ffcccc

The gstack flow

flowchart TD
    A[Vague idea] --> B[/office-hours]
    B --> C[Six forcing questions]
    C --> D[Product reframing]
    D --> E[Design doc]
    E --> F[/plan-ceo-review]

    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style E fill:#e8f5e9

The Six Forcing Questions

/office-hours asks six questions that force clarity:

Question 1: What’s the pain?

Purpose: Find the specific, not hypothetical.

Bad: "I want to build a calendar app"
Good: "I have 5 Google calendars with conflicting events, wrong locations,
      and stale info. Prep takes 30 minutes daily and the results are wrong."

Question 2: Who has this pain?

Purpose: Define the user precisely.

Bad: "Everyone"
Good: "Busy executives who manage multiple teams across time zones"

Question 3: What have you tried?

Purpose: Understand failed solutions.

- Manual calendar checking (time-consuming)
- Shared calendars (permission issues)
- Calendar apps (don't aggregate across providers)

Question 4: What would success look like?

Purpose: Define the end state.

"A morning briefing that takes 0 prep, shows exactly what I need,
  and surfaces conflicts before they happen."

Question 5: What’s the narrowest wedge?

Purpose: Find the smallest valuable slice.

Not: "A full calendar management platform"
But: "A daily email with events, locations, and conflict warnings"

Question 6: What are you NOT building?

Purpose: Set boundaries.

Not building:
- Calendar editing (read-only for now)
- Team scheduling features
- Mobile app (web first)

When It Triggers

/office-hours triggers automatically when:

1. Starting a new feature — “I want to add…”
2. Building something from scratch — “Create a…”
3. Vague requests — “I need a better…”
4. After /office-hours explicitly — User invokes it directly

Socratic Questioning Workflow

sequenceDiagram
    participant U as User
    participant AI as AI (office-hours)
    participant D as Design Doc

    U->>AI: I want to build a daily briefing app

    Note over AI: Question 1: What's the pain?
    AI->>U: What specific problem are you solving?
    U->>AI: Multiple calendars, wrong locations...

    Note over AI: Question 2: Who has this pain?
    AI->>U: Who exactly experiences this?
    U->>AI: Busy executives with multiple teams

    Note over AI: Question 3: What have you tried?
    AI->>U: What solutions have you attempted?
    U->>AI: Manual checking, shared calendars...

    Note over AI: Question 4: Success criteria
    AI->>U: What would "done" look like?
    U->>AI: Zero prep, morning briefing

    Note over AI: Question 5: Narrowest wedge
    AI->>AI: Push back on framing...
    AI->>U: You said "briefing app" but described "chief of staff AI"
    AI->>U: 5 capabilities you didn't realize you were describing...

    Note over AI: Question 6: Boundaries
    AI->>U: What are you explicitly NOT building?
    U->>AI: No editing, no team scheduling, no mobile

    AI->>D: Generate design doc
    D->>U: Design doc created
    Note over D: Feeds into /plan-ceo-review

Real Example: Daily Briefing App

User input

I want to build a daily briefing app for my calendar.

AI reframing

I'm going to push back on the framing.

You said "daily briefing app." But what you actually described is a
personal chief of staff AI.

Let me extract the capabilities you implied:
1. Multi-calendar aggregation (Google, Outlook, Apple)
2. Location intelligence (travel time, conflicts)
3. Stale info detection (outdated meeting rooms)
4. Conflict prediction (double-booking alerts)
5. Preparation summarization (what to prep for each meeting)

The full vision is a 3-month project. But here's the narrowest wedge:

Ship tomorrow: A simple email with today's events, locations, and
conflict warnings. No editing, no intelligence, just aggregation.

RECOMMENDATION: Start with the wedge, learn from real usage.

Design doc output

# Daily Briefing App

## Overview

**Goal**: Reduce morning calendar prep from 30 minutes to 0

**User**: Busy executives with 5+ calendars across multiple providers

**Narrowest wedge**: Daily email with events, locations, conflicts

## Capabilities (discovered)

1. Multi-calendar aggregation
2. Location formatting
3. Conflict detection
4. Email delivery

## Non-goals

- Calendar editing (read-only)
- Mobile app (email first)
- Team features (personal use)

## Next steps

→ /plan-ceo-review for strategic scope challenge

Downstream Skill Integration

The design doc from /office-hours feeds into:

flowchart LR
    A[/office-hours] --> B[Design Doc]
    B --> C[/plan-ceo-review]
    B --> D[/plan-eng-review]
    B --> E[/plan-design-review]

    style A fill:#e1f5ff
    style B fill:#e8f5e9

Best Practices

For users

1. Answer with specifics — Not “performance should be good” but “latency under 100ms”
2. State constraints early — Time, tech stack, team size
3. Challenge the AI — “Why do you recommend that approach?”
4. Accept the pushback — The reframing is the value

For AI configuration

office_hours:
  question_depth: "medium"  # shallow/medium/deep
  pushback_style: "socratic"  # socratic/direct
  design_doc:
    detail_level: "standard"  # minimal/standard/comprehensive

Common Patterns

Pattern 1: User has a solution, not a problem

User: "I need a dashboard with charts"

AI: What decision will you make differently after seeing the charts?
    [Reframes: dashboard → decision support system]

Pattern 2: User wants to build too much

User: "I want an app like Notion"

AI: That's a 5-year project for a 100-person team.
    What's the ONE thing you need most?
    [Reframes: Notion clone → single-purpose tool]

Pattern 3: User has unclear success criteria

User: "Make it fast"

AI: Define "fast":
    - Page load? (target: <2s)
    - API response? (target: <100ms)
    - Data processing? (target: <1s for 10k records)
    [Reframes: vague → measurable]

Skill Quick Reference

Summary

/office-hours is your product thinking partner:

1. Six forcing questions — Pain, user, attempts, success, wedge, boundaries
2. Socratic reframing — Push back on framing, extract implied capabilities
3. Design doc output — Feeds into downstream skills automatically
4. Narrowest wedge — Find the smallest valuable slice to ship first

Key takeaways

• ✅ Don’t skip product thinking — it saves 10x in rework
• ✅ Accept the pushback — the reframing is the value
• ✅ Start with the wedge — learn from real usage
• ✅ Let the design doc flow downstream

Series navigation:

• ← Previous: Tutorial 1: Install & Setup
• → Next: Tutorial 3: plan-ceo-review — Strategic Scope Challenge
• Back: Series Index