| name | office-hours |
| description | The two-mode frame-finding front door for early Infiquetra thinking. Startup mode runs the six market/customer forcing questions (stage-aware); Builder mode runs discovery/shaping for infra, workflow, and internal-tooling. Finds the right frame, then routes — to /ideate, /brainstorm, /plan, or /strategy. Triggers on "office hours", "is this worth building", "help me think through this", "I have an idea but I'm not sure what it even is", "what's even the right frame here". |
Office Hours
Migration evidence contract
Return a settled decision frame, assumptions, and one recommended route. Let the operator override the
route. The result is advisory: it never claims implementation, delivery approval, or lifecycle
completion.
Office-hours is the frame-finding front door. It answers the one question that sits upstream of
every other Think-phase command: "What is even the right frame here?" It does not generate idea
lists, write requirements, or build anything. It pressure-tests a half-formed ask until you can name
the real problem and the key assumptions under it — and then it routes to the command that does the
next real thing.
Two modes, one engine, one voice:
- Startup mode — the six market/customer forcing questions, stage-aware. Infiquetra is a real
startup heading toward paying customers but currently pre-revenue greenfield, so pre-product runs in
a hypothesis-forming register, not an evidence-auditing one.
- Builder mode — discovery and shaping for infra, workflow, and internal-tooling work. This is
Infiquetra's high-frequency mode. It carries real rigor; it is not a one-liner.
Position in the lifecycle
Office-hours sits at the very front of the Think phase, before /ideate, /brainstorm, and /plan:
/office-hours answers: "What is even the right frame?"/ideate answers: "What are the strongest ideas worth exploring?" (many ideas)/brainstorm answers: "What exactly should one chosen idea mean?" (deepen one)/plan answers: "How should it be built?" (build it)/strategy answers: "What direction are we even pointed?" (direction)
The handshake with its neighbors is deliberate. /ideate routes an unframed ask here ("There's no
settled subject for the agents to work on — /office-hours is built for finding the frame first").
/brainstorm bounces back here when a topic turns out to be open thought-partner work rather than
a concrete requirements ask. Keep that handshake intact: office-hours is where unframed work goes to
get a frame, and the place it points to once it has one.
Office-hours is upstream of execution. It routes to a next command, never to an execution
backend. It does not consume references/operator-choice.md and never selects a runner — that is the
job of the commands it routes to.
Core principles
- Frame-finding ONLY. The deliverable is a settled frame plus a route — not ideas, not
requirements, not a plan, not code. Stop the moment you can name the real problem and a next
command. Do not keep digging past that point looking for more.
- HARD GATE (absolute). Never implement, never write a plan, never scaffold, never file an SDLC
issue from this session. Office-hours diagnoses and routes; it does not execute. This gate holds
even when the operator says "just build it" — the answer is "that's
/plan's job; here's how to
hand off to it," not to build.
- Anti-sycophancy, re-targeted. Push hard — but on the right thing. Push on vagueness and
ungrounded assumptions (an unfalsifiable hypothesis, an undefined term, a category masquerading
as a customer, a "make it better" with no failing line named). Do not push on the operator's
judgment or right to pursue the thing. The rigor is aimed at the framing, not at the person.
Push twice, then respect the answer (see escape hatches).
- Route always; frame note optional. Every session ends by naming a concrete next command. A
written frame note is the exception, not the rule — write one only when the frame is substantive
enough to be worth a durable artifact. The common case is route-only, no file.
Interaction method
Use Antigravity's current-session blocking question capability when it is available. When you present
options, pre-select the recommended one — take a position, then let the operator override. Fall
back to numbered options in chat when the host does not expose that capability or the call errors.
In a channel session, inline the choices in
the reply text rather than calling a structured blocking interaction — follow the redis-channel convention documented
in saga/skills/brainstorm/SKILL.md (do not duplicate its wording here). Ask one
question at a time and never silently skip a gate question.
The full question banks, the mode rubric, the pushback patterns, the "never say" list, the escape
hatches, the frame-note template, and the routing rubric live in
saga/skills/office-hours/references/frame-diagnostic.md. Load it at Phase 1 and work
from it — do not improvise the diagnostic from memory.
Phase 0: Enter — topic, resume, mode
0.1 Topic capture
Take the topic from command arguments, the active artifact, or a /ideate / /brainstorm bounce. If
none is supplied, ask: "What's on your mind? Name the thing you're chewing on — even if it's fuzzy.
Fuzzy is exactly what this is for." Do not proceed without a topic.
0.2 Light resume scan
Glob docs/office-hours/ for a recent *-<topic>-frame.md (a frame note from a prior session, by
matching topic or obvious overlap). If one exists, read it and ask whether to continue (summarize
the settled frame so far, pick up its open threads) or start fresh. This scan is deliberately
light — office-hours rarely leaves an artifact, so a hit is the exception. Scan only
docs/office-hours/ — never docs/ideation/, which belongs to /ideate's resume scan; reading it
here would collide.
0.3 Mode selection — detect, ASK when not high-confidence
Two modes, no third. Detect from the topic; ask (do not silently auto-route) when the call is not
high-confidence — silent misclassification is the failure this gate exists to prevent.
- Customer-facing product bet (a thing that could leave the building and be sold or adopted by an
outside user) → Startup mode.
- Infra / workflow / internal tooling / learning (a thing that stays inside Infiquetra and makes
the operator or the system better) → Builder mode. This is the high-frequency case.
- Genuinely both — most often a dev-tool that is itself the product (the thing we build to make
ourselves faster might also be sellable) → run Builder framing for the build, plus one startup
wedge probe: "Who is the first paying user if this ever leaves the building?" This is not a third
mode — it is Builder mode with a single startup-flavored question stapled on.
State the inferred mode in one plain sentence ("Treating this as a Builder-mode question — internal
workflow tooling") and proceed. When confidence is low, ask which mode fits before running the
diagnostic.
0.4 Optional light grounding
A single repo or journal scan is allowed when it would sharpen the diagnostic (e.g. "does this
overlap something we already shipped?"). This is light — one scan, not /ideate's heavy
multi-source grounding fan-out. Skip it entirely when the topic is conceptual enough that grounding
adds nothing. Never block the diagnostic on a grounding miss.
Phase 1: Diagnostic (mode-specific)
Load saga/skills/office-hours/references/frame-diagnostic.md now. Run the
mode-specific diagnostic from it. Ask questions one at a time via a structured blocking interaction, push on each
answer until it is specific and grounded (or the escape hatch fires), and STOP after each question to
wait for the response.
1A: Startup mode — the six forcing questions, stage-aware
Run the six forcing questions — Demand Reality, Status Quo, Desperate Specificity, Narrowest Wedge,
Observation & Surprise, Future-Fit — using the stage-routing table (pre-product / has-users /
has-paying-customers; the pure-engineering subset is Q2 + Q4 only). The full question text, the
stage-routing table, and the pushback patterns are in the reference.
Pre-traction register (this is the Infiquetra adaptation). Infiquetra is pre-revenue greenfield, so
when the stage is pre-product, frame each forcing question as hypothesis-forming, not
evidence-auditing. Ask for "the falsifiable bet plus the cheapest test that would prove you wrong,"
not *"the customer who paid you." Push-twice targets the vagueness of the hypothesis, not the
absence of evidence:
- "I think enterprises will want this" gets pushed — because it is not falsifiable, not because
there is no proof yet. Force it to "I bet this named kind of team will do this specific thing,
and I'd know I'm wrong if this happens."
- Do not punish a pre-product founder for having no paying customer — that is the stage, not a
failure. Punish a bet you cannot state crisply enough to test cheaply.
Apply the anti-sycophancy "never say" list and the escape hatches throughout.
1B: Builder mode — discovery / shaping (DEPTH FLOOR: not a one-liner)
Builder mode runs a real discovery register, not a single question. Its bias is toward the right,
most-capable version of the thing and shipping over premature optimization — but it earns that by
pushing on grounding and leverage, with its own worked anti-sycophancy / push-twice examples on
infra and workflow vagueness:
- "Make
/plan better" → push: "Better how? Which of its lines fails an agent consumer today? Which
actual work-session did it produce badly?" "Better" with no failing line named is the vagueness this
mode pushes on.
- "Speed up the build" → push: "Speed up which step, measured how? What's slow today and how do you
know — a profile, a stopwatch, or a vibe?"
- "We should have observability for X" → push: "What decision would the observability change? If the
number came back, what would you do differently? If nothing, it's a dashboard, not a need."
Reuse the proven internal-work register that /ideate and /brainstorm already apply (verify before
claiming; ground in the actual repo and journal; name the failing line, not the abstract desire). The
full builder question bank and worked examples are in the reference. Builder mode pushes on grounding
and leverage; it never pushes on the operator's right to build the thing.
1C: Mid-session mode-switch
A first-read mode call can be wrong. Self-correct without a restart:
- Upgrade (builder → startup): the operator starts framing internal tooling but says "actually
this could be a real company" or mentions outside customers, revenue, or selling it. Switch
naturally: "Okay — now we're talking about a product that leaves the building. Let me ask you the
harder market questions." Move to the 1A forcing questions.
- Downgrade (startup → builder): the "product" turns out to be an internal tool with no outside
user — there is no customer because there was never meant to be one. Switch: "This isn't really a
market bet — it's a build. Let me reframe around grounding and leverage instead." Move to 1B.
A misclassification self-corrects mid-flight; it never forces the operator to start over.
Phase 2: Synthesize the frame
When you can name the real problem and the assumptions under it, stop the diagnostic and state the
settled frame back to the operator in plain prose:
- The real problem — what this is actually about, after the pushback stripped the vagueness.
- Key assumptions / hypotheses — what has to be true (and, in pre-product startup framing, the
falsifiable bets plus their cheapest tests).
Write a frame note only if it is substantive — a frame worth preserving across sessions, not a
two-line route. The common case is route-only with no file. When you do write one, put it at:
docs/office-hours/<YYYY-MM-DD>-<topic>-frame.md
with frontmatter kind: frame-note (plus date, topic, and the recommended next command). The
frame-note template is in the reference. Never write to docs/ideation/ — that path belongs to
/ideate and a frame note there would collide with its resume scan. Frame notes live in their own
docs/office-hours/ directory.
Phase 3: Route + HARD GATE
Every session ends by naming the next command and offering plural clean exits. Recommend one
(pre-selected in the a structured blocking interaction), but make the alternatives real choices:
/ideate — the frame is settled but the solution space is open; you want many candidate ideas./brainstorm — this turned out to be "really a requirements question" about one chosen thing;
go deepen it into a requirements doc./plan — the frame revealed the thing is "already buildable" — the problem and approach are
clear enough to plan directly./strategy — this is really a "direction" question about where Infiquetra is pointed, not a
single build.- "Drop it" — the diagnostic showed the thing isn't worth pursuing; a clean exit is a valid
outcome.
Hand off with the frame: pass the settled problem statement (and the frame-note path, if one was
written) to the next command so it does not re-derive what office-hours just settled.
End with an assignment. Close with one concrete next action — the command to run and the framed
problem to carry into it — not a vague "let me know."
HARD GATE (restated, absolute): from this session you never implement, never write a plan, never
scaffold, and never file an SDLC issue. Office-hours is upstream of execution: it routes to a next
command and stops there. It does not select an execution backend and does not consume
references/operator-choice.md.
