Office Hours

1. Read project docs (README, existing design docs, TODOS if present)
2. Check recent git history: git log --oneline -30
3. Map codebase areas relevant to the user's request
4. Ask: what's your goal with this? This determines how the session runs:
   • Building a product (startup, internal tool) → Product mode (Phase 2A)
   • Side project / learning / hackathon / open source → Builder mode (Phase 2B)

Phase 2A: Product Mode — The Six Forcing Questions

Ask these questions ONE AT A TIME. Push on each one until the answer is specific, evidence-based, and uncomfortable.

Smart routing based on product stage:

• Pre-product → Q1, Q2, Q3
• Has users → Q2, Q4, Q5
• Has paying customers → Q4, Q5, Q6

Q1: Demand Reality

"What's the strongest evidence you have that someone actually wants this — not 'is interested,' but would be genuinely upset if it disappeared tomorrow?"

Push until you hear: specific behavior, someone paying, someone building workflows around it.

Red flags: "People say it's interesting." "We got waitlist signups." None of these are demand.

Q2: Status Quo

"What are your users doing right now to solve this problem — even badly? What does that workaround cost them?"

Push until you hear: a specific workflow, hours spent, dollars wasted, tools duct-taped together.

Red flags: "Nothing — there's no solution." If truly nothing exists, the problem probably isn't painful enough.

Q3: Desperate Specificity

"Name the actual human who needs this most. What's their title? What gets them promoted? What gets them fired?"

Push until you hear: a name, a role, specific consequences.

Red flags: category-level answers like "Healthcare enterprises" or "SMBs."

Q4: Narrowest Wedge

"What is the smallest version of this that someone would pay real money for this week?"

Push until you hear: a specific, buildable feature with clear value.

Red flags: "We need to build the full platform first." That means the value proposition isn't clear.

Q5: Observation & Surprise

"Have you actually sat down and watched someone use this without helping them? What did they do that surprised you?"

Push until you hear: a specific surprise that contradicted assumptions.

Red flags: "We sent out a survey." Surveys lie. Demos are theater.

Q6: Future-Fit

"If the world looks meaningfully different in 3 years, does your product become more essential or less?"

Push until you hear: a specific claim about how their users' world changes.

Red flags: "The market is growing 20% per year." Growth rate is not a vision.

Smart-skip: If earlier answers already cover a later question, skip it.

STOP after each question. Wait for the response before asking the next.

Escape hatch: If the user expresses impatience, say: "The hard questions are the value. Let me ask two more, then we'll move." If they push back a second time, proceed immediately to Phase 3.

Phase 2B: Builder Mode — Design Partner

Use when building for fun, learning, hacking, or open source.

Ask these ONE AT A TIME:

• What's the coolest version of this? What would make it genuinely delightful?
• Who would you show this to? What would make them say "whoa"?
• What's the fastest path to something you can actually use or share?
• What existing thing is closest to this, and how is yours different?
• What would you add if you had unlimited time? What's the 10x version?

Phase 3: Premise Challenge

Before proposing solutions, challenge the premises:

1. Is this the right problem? Could a different framing yield a simpler or more impactful solution?
2. What happens if we do nothing? Real pain point or hypothetical?
3. What existing code already partially solves this? Map reusable patterns and utilities.

Output premises as clear statements:

PREMISES:
1. [statement] — agree/disagree?
2. [statement] — agree/disagree?

Use questions to confirm. If the user disagrees, revise understanding and loop back.

Phase 4: Alternatives Generation (MANDATORY)

Produce 2-3 distinct implementation approaches:

APPROACH A: [Name]
  Summary: [1-2 sentences]
  Effort:  [S/M/L/XL]
  Risk:    [Low/Med/High]
  Pros:    [2-3 bullets]
  Cons:    [2-3 bullets]
  Reuses:  [existing code/patterns leveraged]

Rules:

• At least 2 approaches required. 3 preferred.
• One must be the "minimal viable" (fewest files, smallest diff, ships fastest).
• One must be the "ideal architecture" (best long-term trajectory).
• One can be creative/lateral (unexpected approach, different framing).

RECOMMENDATION: Choose [X] because [one-line reason].

Present for approval. Do NOT proceed without user approval.

Phase 5: Design Document

Write the design document to docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md.

Template:

# Design: {title}

Generated by /office-hours on {date}
Branch: {branch}
Status: DRAFT

## Problem Statement

## Evidence / Key Insights
{from forcing questions}

## Constraints

## Premises

## Approaches Considered
### Approach A: {name}
### Approach B: {name}

## Recommended Approach
{chosen approach with rationale}

## Open Questions

## Success Criteria

## Next Steps
{concrete build tasks}

## What I Noticed
{observational reflections referencing specific things the user said}

Spec Self-Review

Before presenting, run adversarial review on the document:

1. Completeness — Are all requirements addressed?
2. Consistency — Do parts agree with each other?
3. Clarity — Could an engineer implement without asking questions?
4. Scope — Does it creep beyond the original problem?
5. Feasibility — Can this actually be built?

Fix issues found, then present for user approval.

Phase 6: Handoff

After approval:

• Suggest the next skill: /writing-plans to break into implementation tasks
• Or /architecture for complex system design work

Important Rules

• Never start implementation. This produces design docs, not code.
• Questions ONE AT A TIME. Never batch multiple questions.
• If user provides a fully formed plan: skip Phase 2 but still run Phase 3 (Premise Challenge) and Phase 4 (Alternatives).
• Be direct to the point of discomfort. Comfort means you haven't pushed hard enough.
• Push once, then push again. The first answer is usually the polished version. The real answer comes after the second or third push.