gstack Can Demand Evidence. It Cannot Produce It.

I use gstack as the methodological backbone of my work with Claude Code. It is good when there is code to build, review, and ship.

I wanted to know what happens when I use it earlier, before a product has code, users, or a price.

That is where many expensive product mistakes are made. Not because the work is sloppy, but because it is rigorous about the wrong assumption.

gstack does one thing particularly well in this phase: it demands evidence. It does not do the other half of the job: help me produce that evidence.

That distinction changed how I use it.

The interrogation is useful

/office-hours in Startup Mode is not a brainstorming companion. It is an interrogation.

It pushes through six uncomfortable areas: demand reality, the status quo, desperate specificity, the narrowest wedge, observation and surprise, and future fit. Its rules are explicit. Interest is not demand. A user’s words beat a founder’s pitch. Every answer receives a position, not reassurance, and the process states what evidence would change that position.

The diagnosis then goes through adversarial review, a cross-model second opinion, and a design document.

This is YC-style office hours turned into a repeatable workflow. When a founder brings real evidence, it has something to bite into.

The problem starts when there is nothing substantial to bring.

Asking for proof is not a method for obtaining it

The first question asks for the strongest proof that somebody wants the product. A waitlist does not count. Polite interest does not count.

That is the right question.

But the workflow does not explain how to collect a customer’s words without contaminating them. It does not create a process for interviewing people about past behaviour rather than pitching them a hypothetical future. It does not force the idea to be expressed as customer progress instead of product capability. It does not rank commercial and technical assumptions by risk. It does not establish what willingness to pay means while the product is still a concept.

After diagnosis, the centre of gravity moves toward premise challenge, alternatives, design, specification, engineering review, and shipping.

There is no explicit step that says: leave the room, talk to people, and return with better evidence.

That omission is coherent with what gstack is built to do. It is a toolkit for building and shipping. Its pre-code entry point is a demanding filter, not a complete customer-discovery system.

The mistake would be treating the filter as the evidence engine.

The failure looks like a good plan

This gap does not produce an obvious error. It produces a precise plan on the wrong axis.

Suppose I enter /office-hours with a single friendly user and no external conversations. My honest answer about demand is weak. The workflow still needs something measurable, so the most legible assumption tends to win: whether the technology works.

The result can be impressively rigorous. It may include a holdout set, preregistered thresholds, denominator rules, and clear success criteria. It can tell me whether a technical approach performs as expected.

It can remain completely silent on the more dangerous question: will anyone pay for this instead of continuing with the free workaround they already use?

The rigor is not the problem. The problem is that rigor attaches itself to the assumption with available data, not necessarily to the assumption with the greatest risk.

Garbage in, excellent processor.

Four skills between diagnosis and design

I filled this gap with four project-scoped skills from wondelai/skills, an MIT-licensed collection that distils business frameworks into agent workflows with explicit scoring rubrics.

I copied the four skills into .claude/skills/ in the repository. I did not install them globally. A method selected for one product should not silently become policy for every other project.

I also did not use Wondel’s create-business orchestrator. It starts from a raw idea and derives a sequence of business documents. I already had a design document. Running the orchestrator would have created a second process that tried to rediscover decisions already made.

I needed targeted evidence producers, not another operating system.

Jobs to Be Done changes the unit of analysis

The jobs-to-be-done skill forces me to describe the progress a customer is trying to make without naming my product.

That removes the feature vocabulary that makes weak ideas sound stronger than they are. It also forces the real alternative into view. The competitor is often not another SaaS product. It is a spreadsheet, a message to a friend, an existing habit, or doing nothing.

Until that alternative is explicit, a product can win every comparison except the one the customer is actually making.

The Mom Test protects the conversation from the pitch

The mom-test skill is the bridge from a plausible theory to conversations with real people.

It redirects questions toward the person’s past behaviour, current workflow, and existing costs. It treats compliments as weak signals and commitments as stronger ones. Most importantly, it reduces the founder’s ability to teach the interviewee the desired answer.

This does not make an interview objective. It makes self-deception more expensive.

Lean Startup orders assumptions by risk

The lean-startup skill separates value hypotheses from technical hypotheses and asks which assumption can kill the idea first.

That ordering matters. Without it, agents naturally gravitate toward tests that are easy to specify and automate. Technical feasibility usually offers cleaner metrics than demand, so it receives more attention even when it is not the main source of uncertainty.

I want pivot and persevere criteria written before results exist. Otherwise the experiment becomes a machine for explaining why any outcome still supports the original plan.

Monetizing Innovation moves pricing before the product

I initially placed monetizing-innovation too late.

The create-business journey uses it after several strategy and positioning steps, and I followed that sequence rather than the principle behind the source material. The more useful rule is price before product: discuss willingness to pay while the product is still a concept.

This does not mean pretending that a small set of friendly interviews can reveal the correct price. The price level would be noise.

The earlier question is the pricing metric: what is the customer paying for?

That choice affects what the first prototype must measure. If the relevant unit is not instrumented from the beginning, there will be no historical signal when pricing decisions become real.

Put discovery between the decision gates

/plan-ceo-review is useful before I speak to customers because it can challenge the proposed research plan. The discovery skills then shape the interviews, assumptions, and pricing questions. /office-hours becomes useful again when I return with observed behaviour and real commitments. /plan-eng-review belongs later, once the evidence has become requirements worth implementing.

A scoring rubric can quantify fiction

The Wondel skills use explicit scoring rubrics. That makes their outputs easier to inspect, but it introduces the same failure mode I was trying to avoid.

A Jobs to Be Done document can score 10/10 while being based entirely on my assumptions. A perfectly structured interview plan is not an interview. A complete experiment specification is not a market signal.

Quantification makes omissions visible only when the rubric measures contact with reality. Otherwise it gives speculation a cleaner interface.

The most important rule in create-business is therefore not one of its scores: the agent must never simulate an interviewee. A role-played customer is structurally inclined to confirm the context and hopes embedded in the prompt.

The expensive part remains outside every skill. I still have to conduct the conversations. I still have to hear no. The tools can reduce the probability of asking bad questions; they cannot absorb the social cost of asking them.

Evidence also needs somewhere to live

A second gap appeared after several weeks of work.

gstack writes decisions.jsonl, learnings.jsonl, and timeline.jsonl when one of its skills is running. Claude Code maintains project memory. Product artifacts live in docs/. gbrain indexes the code.

That left me with four stores and no reliable authority.

A decision made during an unstructured reasoning session might enter Claude’s memory but not gstack’s logs. The next gstack context recovery would reconstruct a project that had stopped days earlier. Claude’s memory would describe a newer state. Both histories could look plausible.

My rule became simple: a fact lives where it will be read.

A durable decision goes into gstack-decision-log during the session in which I make it, even when no gstack skill is active. Native project memory stores how we work and points to the authoritative artifact. Documents stay in docs/ and Git. gbrain makes them searchable.

This rule is manual exactly where manual discipline tends to fail, so I added three project-scoped hooks.

A PostToolUse hook watches Write, Edit, and Bash operations. When a Markdown file under docs/ changes, it runs gbrain capture with a stable file-based slug. gbrain deduplicates by content hash, so re-saving a file updates one page instead of creating another. I added this after discovering that /sync-gbrain indexed code but not those Markdown documents.

An asynchronous Stop hook runs the memory stage of gstack-gbrain-sync, with a 30-minute debounce. Stop fires at the end of every turn rather than only at the end of a working session, so running it without a debounce would create noise rather than continuity.

A SessionStart hook injects the last five entries from decisions.jsonl into context. It cannot decide that something said in conversation counts as a durable decision. That still requires judgment. It can make a missing record visible before the next session builds on stale assumptions.

Two hooks are deterministic. The third is a reminder. That is as far as I can automate the boundary without pretending that classification is mechanical.

The operating model is evidence in, decisions out

I have not turned gstack into a customer-discovery toolkit. I have made its boundary explicit.

gstack remains the decision layer. The four additional skills help produce customer and commercial evidence between those decisions. The hooks preserve enough continuity that the next review sees the project that actually exists, not the last version captured by whichever memory store happened to run.

The reusable distinction is not between one toolkit and another. It is between demanding evidence, producing evidence, and preserving evidence.

An agent can help with all three, but it cannot perform all three in the same way. Demanding evidence can be procedural. Preserving it can be partly deterministic. Producing it still requires contact with people whose answers are not under the system’s control.

That is the part I do not want the workflow to automate away.