Tsurai7 Office hours
Pressure-test an idea before building it: six forcing questions, then a verdict.
The six forcing questions
- Q1 Premise challenge — restate the ask in your own words; is it the right problem? Reframe before answering if not.
- Q2 Status quo — what already addresses this (the real competitor is rarely "nothing")? What is genuinely missing?
- Q3 Evidence of value — who benefits and what measurable number moves?
- Q4 Narrowest wedge — the smallest version shippable now; name what is explicitly out of scope.
- Q5 Risk & verification — blast radius; which existing test/gate proves nothing broke, or what new one must ship with the change?
- Q6 Cost of keeping — ongoing token/maintenance cost; what would make us remove it?
Smart routing (don't run all six every time)
| Change type | Run |
|---|---|
| Pure infra/tooling | premise + Q2 + Q4 (+ Q5 when hooks/CI are touched) |
| New user-facing capability or skill | Q1 + Q3 + Q4 + Q6 |
| Recurring-cost change (always-on prefix, hooks on hot paths) | Q2 + Q4 + Q6 |
| "Should we adopt X?" decisions | all six |
Capture convention
If the target repo keeps design docs, write the session to
docs/design/<topic>-office-hours.md with an explicit Verdict section;
otherwise deliver the verdict in the response. End every vet with a verdict +
the narrowest wedge, never with an open-ended options list.
Provenance
Adapted from the gstack office-hours skill by Garry Tan
(garrytan/gstack, MIT; upstream
office-hours/SKILL.md v2.0.0). A deliberate adaptation, not a reconstruction:
upstream's four product-stage questions were replaced with engineering-relevant
ones (premise challenge, evidence of value, risk & verification, cost of
keeping). This file is the single source of truth going forward.