Don’t Rush to Code—Start with /office-hours as Your First gstack Skill

Purpose of /office-hours

Many projects fail because they start solving the wrong problem. /office-hours forces a problem‑definition stage before any code, scaffolding or implementation.

Efficiency: finish a 3‑hour task in 1 hour. True efficiency: spend 5 minutes deciding whether to do it and what to do.

What /office-hours does

It is a “problem definitor”, not a code generator. The repository enforces hard constraints: no code, no project scaffolding, no implementation – only a design document is produced.

It asks a fixed set of questions:

What problem are you trying to solve?

Who feels the pain the most?

How are they currently coping?

What is the smallest viable entry point?

Is this a feature or a larger product?

Rewriting the problem – concrete example

In the repo a user asked for a “daily briefing app for calendars”. A typical agent would start planning Google‑Calendar integration, UI layout, database tables, etc. /office-hours instead probes the real pain points (multiple calendar accounts expiring, low‑quality meeting prep, wrong locations, manual follow‑ups) and concludes the underlying need is a “personal chief of staff AI”. This rewrite changes product boundaries, implementation priorities and the minimal viable slice.

Process flow

Step 1 – Determine mode

The skill first asks your goal and routes you to either Startup mode or Builder mode.

Startup mode – six forcing questions

Is there a real demand, not just interest?

What workaround do users currently employ?

Who is the most needy person?

What is the smallest payable wedge?

Have you actually observed user behavior?

Will this product be more or less important in three years?

Builder mode – showcase‑oriented questions

What is the coolest version?

What would make others say “interesting”?

How quickly can you build a usable, shareable version?

What existing solutions are most similar, and how do you differ?

If time were unlimited, what would the 10× version look like?

Two critical actions

Premise challenge

It extracts product premises from your statements and asks you to confirm them, e.g. “Is the real value in the intelligence layer?”, “Is the narrowest entry point a specific workflow?”, “Is a capability nice‑to‑have or required for the first version?”

Alternatives generation

It proposes 2‑3 concrete paths such as “run the narrowest slice first”, “build the data layer then the UI”, or “go straight to a full‑vision version”, compares effort and recommends the most suitable first step.

Key output – design document

The result is a design doc saved under ~/.gstack/projects/. Typical sections:

Problem definition

Current state and realistic alternatives

Target users and minimal slice

Key premises

Alternative paths

Recommended path

Open questions

Success criteria

Next actions

Running /office-hours repeatedly on the same branch builds a design‑evolution chain instead of starting a brand‑new document each time.

When to run it first

Many feature ideas but no clear first step.

Talking about a “platform” without a defined minimal slice.

Idea exists but the pain point or target user is unclear.

Direction feels vague.

Side project where a showcase‑ready version is needed quickly.

When it may not be needed

Fixing a clearly defined bug.

Implementing a small, well‑scoped requirement.

Already have a mature design doc and are only doing local implementation.

Pure engineering infrastructure problems with a well‑defined issue.

Minimal usage steps

Enter /office-hours.

Answer the initial “what is your goal?” question thoughtfully.

Observe how the problem is rewritten and premises are challenged.

Read the generated design doc; if it clarifies the problem, proceed to downstream skills such as /plan-ceo-review or /plan-eng-review.

Why it is a foundational skill in gstack

AI lowers the barrier to implementation, making it easy to build the wrong thing quickly. /office-hours forces explicit problem definition before any code is written, ensuring that the hours spent on implementation are spent on the right problem.