---
name: gstack-office-hours-consumer-ai
description: Run gstack /office-hours non-interactively for Consumer AI Factory ventures, especially when Antoine says a product feels weak, gimmicky, or needs a sharper wedge.
tags:
  - consumer-ai
  - gstack
  - office-hours
  - venture-strategy
  - product-reframe
---

# GStack Office Hours for Consumer AI Ventures

## When to use

Use when Antoine asks to run gstack `/office-hours`, or says a Consumer AI Factory venture/product:

- feels like a gimmick
- is not delivering enough value
- needs to be fleshed out
- may be too close to ChatGPT-with-UX
- needs a sharper first-use wedge, retention loop, or product artifact

This skill is for product/strategy diagnosis, not implementation.

## Goal

Produce a hard product diagnostic and concrete next experiment, then save the output in both:

1. gstack's local design-doc store
2. the relevant venture's Obsidian product/research folder

## Procedure

1. Load relevant factory skills first when available:
   - `consumer-ai-factory-opportunity-evaluation`
   - `consumer-ux-director` if the critique concerns UX/product artifact
   - any venture-specific skill if present

2. Inspect the gstack office-hours skill directly:

```bash
read /Users/antoinelevy/.claude/skills/gstack/office-hours/SKILL.md
```

At minimum, follow its core shape:

- Startup mode for ventures/demand probes
- hard diagnostic before solutions
- challenge demand, status quo, desperate user, narrowest wedge, observation, future-fit
- generate at least 2-3 distinct directions
- write a design doc

3. Run the gstack preamble safely but do not enable optional features by default:

```bash
~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true
~/.claude/skills/gstack/bin/gstack-config get telemetry 2>/dev/null || true
~/.claude/skills/gstack/bin/gstack-config get proactive 2>/dev/null || true
eval "$(~/.claude/skills/gstack/bin/gstack-slug 2>/dev/null)" 2>/dev/null || true
```

If an update is available, do not derail the user’s product task. Snooze it unless Antoine explicitly asked to upgrade gstack.

4. Gather repo context:

```bash
git status --short --branch
git log --oneline -10
git diff origin/main --stat 2>/dev/null || true
```

Read the core product files and tests relevant to the current experience. Avoid secrets: never read `.env` or `.env.*`.

5. If Antoine already gave a strong critique or asks to “just run it,” do not stop for interactive gstack questions. Fast-track with explicit assumptions. Use a Claude Code prompt that says:

- run gstack `/office-hours` as closely as possible
- Startup Mode, not Builder Mode
- do not implement code
- do not deploy
- do not enable telemetry/proactive/team/cookies/cross-project sharing
- infer from current context and clearly label assumptions
- produce a design/strategy doc and concise recommendation

Example prompt skeleton:

```text
Run gstack /office-hours for [venture].

Use the gstack office-hours skill as closely as possible, but fast-track because Antoine explicitly asked to run it and already gave the core critique. Do not implement code. Produce a design/strategy doc and concise actionable synthesis.

Project:
- Repo: [repo path]
- Product: [current product/url]
- Current product: [one-paragraph current product]
- Stage: live pre-product / demand probe unless evidence says otherwise
- Antoine critique: "[quote]"
- Factory bar: reject generic ChatGPT-with-UX. The product needs a repeated outcome system, expert framework, tracking, multiplayer/accountability, real workflow completion, or some non-ChatGPT advantage.
- Known user/product preferences: [relevant memories]

Run Startup Mode. Treat this as a hard product diagnostic:
1. Read repo context and current product files.
2. Challenge the current premise.
3. Generate 3 materially different product directions/wedges.
4. Recommend one direction with a concrete first-use artifact, retention loop, and cheapest demand test.
5. Save the design doc to ~/.gstack/projects/<slug>/ using the office-hours naming convention.
6. Output the saved doc path and concise recommendation.

Constraints:
- Do not ask Antoine questions in this run; infer from context and label assumptions.
- Do not write code or modify app files.
- Do not deploy.
- Do not enable telemetry, proactive mode, team sync, cookies, or cross-project sharing.
- Avoid generic productivity/app advice.
```

Run via Claude Code with constrained tools and explicit secret exclusions.

6. Verify the gstack doc exists with `search_files` or `read_file` under `~/.gstack/projects/`.

7. Save a venture-facing synthesis in Obsidian.

For Start Small, use:

```text
/Users/antoinelevy/Documents/Obsidian Vault/Consumer AI Company Factory/05 Ventures/Venture 002 - Start Small/01 Product/
```

For other ventures, use the relevant `05 Ventures/Venture XXX - Name/01 Product/` or `02 Research/` folder.

The Obsidian note should include:

- trigger/critique
- hard verdict
- core insight
- product reframe
- directions considered
- recommendation
- cheapest demand test
- success criteria
- kill criteria
- what to stop
- what to keep
- next implementation brief

8. Append to the Consumer AI Factory build log:

```text
/Users/antoinelevy/Documents/Obsidian Vault/Consumer AI Company Factory/00 Operating System/Consumer AI Company Factory - Build Log.md
```

Entry fields:

- Action
- Why
- Artifact
- Signal
- Decision
- Factory learning

## Quality bar

A good output does not say “make the product better.” It names:

- the current weak premise
- the actual user pain moment
- the status quo/workaround
- the specific first-use artifact
- a non-ChatGPT advantage
- a retention loop
- a cheapest demand test
- success and kill criteria

## Example learning from Start Small

Start Small’s first weak premise was “break stuck tasks into tiny steps.” That is not enough because ChatGPT can already do step generation and timers are commodity.

The next attempted reframe was:

```text
Start Small is a calm AI body double that gets you from frozen to moving, stays with you during the first step, and saves proof that you did it.
```

This improved the UX, but the later gstack diagnostic found it still gimmicky because the deployed app had no real AI, no voice/TTS/mic, no persistence, no memory, no human/accountability loop, and no adaptive presence. “Companion” copy plus timer check-ins is not enough to claim body doubling.

Current stronger reframe:

```text
Start Small remembers your stuck patterns and turns each rescue session into a lightweight Stuck Journal: what task type froze you, what physical-first move got you started, and what to try next time.
```

Recommended cheapest experiment:

```text
Receipt-level pattern-memory test = after session completion, show a fake-but-plausible insight card based on task category, e.g. “Pattern spotted: admin tasks are where you freeze. Physical-first starts helped you get moving. Want me to remember this for next time?” A/B it against the generic waitlist CTA.
```

Success bar:

- Pattern-memory / “remember my stuck patterns” CTA converts around 2x the generic waitlist CTA, or shows clear qualitative pull within ~100 receipt views / one week.
- If it works, build minimal persistence: localStorage or email-only magic link + session history.
- If it fails, pause or kill Start Small rather than continuing to polish the static companion.

Factory lesson:

For focus/rescue products, the core value must cross the knowing-to-moving gap and compound across sessions. Calm UI is not enough unless it creates an outcome ChatGPT cannot: real presence, accountability, persistent memory/tracking, protocolized behavior change, or a repeated outcome system. When Antoine says a polished version still feels gimmicky, stop UX polishing and re-run strategy against demand, retention, and non-ChatGPT advantage.

## Adjacent gstack components after office-hours

When Antoine asks to “keep iterating with gstack” or asks what other gstack components are useful, do not default to another `/office-hours` run. Pick the component based on the current risk:

1. `/plan-ceo-review`
   - Best immediately after a hard office-hours verdict or before any bigger build.
   - Use it to decide whether the next build increases product advantage or just polishes a weak wedge.
   - For Start Small-like demand probes, frame the review around: non-ChatGPT advantage, retention loop, cheapest proof, and what not to build yet.

2. `/qa-only`
   - Best after a small shipped change or when the product is live and needs conversion/first-use QA.
   - Run in report-only mode first.
   - Useful findings from Start Small: telemetry property gaps, wrong seated-vs-standing prompt logging, and silent form-validation failures are worth fixing because they corrupt the demand probe even if they are not core product features.

3. `/design-review`
   - Use for bounded landing/receipt clarity, not for broad ideation.
   - Good when the product promise is right but the first viewport, CTA, or receipt artifact is unclear.

4. `/retro`
   - Use after real data arrives, especially after an A/B demand probe.
   - Extract factory learnings: what signal moved, what copy/flow created intent, what pattern becomes reusable, and whether to continue/kill.

5. `/design-shotgun` and `/autoplan`
   - Avoid early unless the strategic direction is already validated.
   - `design-shotgun` can create attractive but distracting UI paths.
   - `autoplan` can create premature implementation momentum before demand is proven.

Safe gstack iteration pattern for live Consumer AI probes:

```text
/office-hours for hard product diagnosis → /plan-ceo-review for next-build decision → /qa-only for live flow + telemetry integrity → implement only low-risk probe-preserving fixes → tests/build/browser QA → /retro after data.
```

Implementation guardrail: after `/qa-only`, only fix defects that improve measurement integrity or obvious first-use completion. Do not use QA output as permission for a redesign spiral.

## Pitfalls

- Do not blindly enable gstack telemetry, proactive mode, cookies, team sync, or cross-project sharing.
- Do not let gstack update prompts derail the requested office-hours run; snooze updates unless Antoine asks to upgrade.
- Do not produce generic productivity app advice. Consumer AI Factory ideas need a non-ChatGPT advantage.
- Do not skip Obsidian/build-log capture for meaningful strategy work.
- Do not implement immediately after office-hours unless Antoine asks. The deliverable is a strategy/design doc and next experiment.