Before Code: Turning Intent into a Buildable Decision

For gstack, the first reliability problem is often not a bad function but an unclear request. This chapter focuses on how the project moves from a feature someone names to a direction an engineer can build and test. The reader’s practical question is simple: how can an AI agent challenge the framing without quietly taking control of the product?

The answer is a sequence of distinct decisions. gstack uses office-hours to investigate the underlying problem, CEO-style review to test scope and ambition, design and developer-experience review when those surfaces matter, and engineering review to make the chosen direction executable. The sequence is not a ceremony around code. It is a way to separate symptoms, causes, choices, and consequences before implementation makes a weak assumption expensive.

A feature request is often a symptom

Suppose someone says, “I want a daily briefing app for my calendar.” That sentence sounds specific enough to implement. It names a data source, a rough interface, and an apparent deliverable. A literal assistant could begin by connecting to a calendar API, storing events, and rendering a daily list.

The gstack example does not treat the sentence as the problem statement. Its office-hours questions ask about concrete pain: multiple Google calendars, stale information, wrong locations, weak preparation documents, and the time required to get ready for important events. Those details change the diagnosis. The valuable product may not be a calendar display. It may be a personal chief of staff that detects missing context, prepares the user for a meeting, understands relationships, and helps prioritize time.

This is not an argument that every small request should expand into a grand product. It is a test for whether the named feature is an adequate explanation of the user’s problem. The distinction matters because a feature can be perfectly implemented and still fail if it solves the visible symptom while leaving the costly work untouched. A better frame may also lead to a smaller first release: the office-hours example recommends a narrow daily briefing as a wedge rather than attempting the full vision immediately.

That diagnosis has three parts. First, there is the user’s language, which is evidence but not necessarily a complete specification. Second, there is the observed pain that gives the request meaning. Third, there is a choice about what to build now and what to leave for later. gstack’s planning skills keep those parts separate so that a recommendation can be challenged before it becomes a file tree.

The /office-hours skill is explicit about this boundary. It produces a design document and does not implement code. It first asks what kind of work the user is doing, then adapts its questions for a startup, an internal project, an open-source effort, a hackathon, learning, or a side project. In a startup-oriented setting it asks about demand reality, the status quo, desperate specificity, the narrowest wedge, observation, and future fit. In a builder setting it can be more generative, but it still has to understand what the user wants to make and why.

After the problem is stated, office-hours challenges premises rather than asking for a vague feeling of approval. Is the calendar the real source of value, or only the anchor for an intelligence layer? Is the assistant meant to replace a person’s judgment, or make that person more effective? Is a full relationship graph necessary on day one, or would a working daily briefing reveal what matters? These are product decisions, not implementation details.

The skill then requires at least two approaches. One may be the narrowest viable version, another the ideal long-term architecture, and a third may reframe the problem in a less obvious way. Each approach carries effort, risk, advantages, disadvantages, and reuse of existing patterns. The recommendation is visible, but it does not silently become the decision. The user must approve an approach before the design document is finalized.

That hard stop is important for an agentic system. If the assistant were allowed to interpret the request, pick an approach, and begin coding in one motion, later objections would arrive after implementation had created momentum. A user might accept an inferior direction simply because changing it now feels expensive. Office-hours puts the reversible conversation before the less reversible work.

From product choice to technical spine

Once the product direction is clear, gstack changes the kind of reasoning it asks for. /plan-ceo-review is the founder or product lens. It asks what the product is actually for and offers four scope modes: expansion, selective expansion, hold scope, and reduction. The modes matter because “think bigger” and “cut scope” are not always good advice. A founder may want the ambitious version, a team may need rigor within the existing boundary, or a builder may need the smallest useful experiment.

The CEO review can preserve the original request while showing what would change if the product were more ambitious. It can also recommend reduction. The important design choice is that scope is represented as a decision with consequences rather than as a hidden preference of the model. Visions and decisions can be persisted so the rationale survives the conversation that produced it.

Design and developer experience enter when the product crosses their boundaries. A plan that says “build a dashboard” has not decided what a user sees during loading, when there is no data, when an action fails, or when the viewport is narrow. The design review examines information hierarchy, interaction states, user journeys, responsive behavior, accessibility, and the risk of generic AI-generated patterns. It rates dimensions and makes missing choices visible while they are still cheap to change.

Developer experience is a parallel concern for a different user. An API, command-line tool, SDK, or documentation flow can be technically correct and still be painful to adopt. The DX review looks at developer personas, time-to-hello-world, friction points, and the moment when the tool first becomes useful. It asks the plan to account for the person who will install, integrate, debug, or learn the system, not only the code that makes the system function.

Engineering review then supplies the technical spine. It asks where components meet, what state changes, which operations are synchronous, where retries belong, what happens when one step succeeds and the next fails, and how a low-confidence or partial result is represented. It examines trust boundaries and test coverage. The project’s engineering guidance emphasizes diagrams because a sequence, state, or data-flow diagram forces assumptions into the open. A paragraph can say “the service processes the upload”; a diagram makes the reader specify which service, in which order, with what persisted state, and what happens when enrichment fails.

The handoff looks like this:

sequenceDiagram participant U as User participant O as Office-hours participant C as CEO review participant D as Design or DX review participant E as Engineering review participant A as Approved plan U->>O: Describe the problem and desired outcome O->>U: Challenge premises and present alternatives U->>O: Approve or revise the direction O->>C: Carry the design decision forward C->>D: Add product-surface constraints when relevant D->>E: Add design or developer-experience amendments E->>A: Specify architecture, failure paths, and tests A-->>U: Present final decisions for approval

The diagram is not meant to imply that every project needs every review. Design and DX are conditional. The dependency it does show is that engineering review comes after any earlier amendments that affect the system. If engineering signs off on an older plan and a later design review changes the interaction or data flow, the technical gate would be evaluating stale assumptions. /autoplan therefore makes engineering the final phase.

That ordering also limits a common failure mode in multi-agent workflows: parallel specialists producing incompatible advice. gstack’s autoplan instructions require the phases to run sequentially, not in parallel, because each stage builds on the last. A transition summary and required artifacts are checked before the next phase begins. This is slower than launching every opinion at once, but it preserves a causal relationship among decisions.

Take an event-preparation feature as a small technical example. The product decision may say that a briefing should identify stale event details and produce useful preparation, not merely list appointments. The engineering plan then has to distinguish at least several states: calendars have not been fetched, events have been fetched but not enriched, enrichment is incomplete, preparation is ready, and the user has rejected or corrected the result. It must say what happens when one calendar succeeds and another fails, whether a retry can duplicate a briefing, and which parts can be recomputed safely. The design plan must say what the user sees in each state. The test plan must include partial success, not only the happy path.

Those details are not implementation trivia. They are the point where a product promise becomes a system that can be falsified. If the plan cannot say whether stale data is shown with a warning, hidden, or treated as a hard failure, then “useful briefing” is still a slogan. If it cannot say what happens after an enrichment timeout, the future bug is already present as an unstated decision.

What the artifacts make visible

The value of a plan is not its length. It is the number of hidden assumptions it turns into inspectable objects. A failure-modes table asks what can go wrong and how the system responds. A trust-boundary description asks which inputs are treated as instructions, data, credentials, or untrusted content. A test plan maps behavior to evidence instead of treating “we should test it” as a test strategy. A diagram shows ownership and order. A decision record preserves why one alternative was chosen over another.

These artifacts also give later stages something to disagree with. A browser QA run can reveal that the chosen flow is impossible for a signed-out user. A structural review can find that a retry path creates duplicate work. A release check can discover that the code changed after the tests were run. Those findings are more useful when the original assumptions are explicit. Without a plan, the reviewer has to infer the intended behavior from code and may mistake an omission for a choice.

A useful plan therefore records both decisions and uncertainty. It can say that a narrow wedge is chosen while the full vision remains open. It can name an external dependency without pretending its failure is under local control. It can mark a design question as a user preference instead of disguising it as an engineering requirement. This makes later changes easier to interpret: a new behavior can be compared with an earlier decision, rather than judged against an undocumented intention.

This is why gstack’s process is best understood as a diagnosis-and-verification loop. Office-hours identifies the problem and separates it from the proposed feature. Product and design reviews expose competing interpretations and user-visible consequences. Engineering review tests whether the chosen direction has a coherent state model and failure path. The plan does not guarantee a good outcome, but it gives the outcome a set of claims that can later be tested.

What the agent may decide

/autoplan automates intermediate questions with six principles, including choosing completeness when the added work remains in the direct blast radius, preferring existing solutions over duplication, choosing explicit approaches over clever abstractions, and biasing toward action rather than endless review. These principles reduce the cost of routine decisions. They are not a license to hide consequential choices.

The workflow classifies decisions. A mechanical decision has one clearly right answer in context. A taste decision has multiple viable options with different trade-offs. A User Challenge arises when both model voices recommend changing the user’s stated direction. Mechanical decisions can be auto-resolved. Taste decisions are surfaced at the final gate. User Challenges are never silently accepted, because the user may know a business constraint, timing issue, or future plan that the models cannot see.

That distinction is the core safeguard of the planning system. It acknowledges that a model can analyze more alternatives than a person has time to enumerate, while still lacking the authority to redefine the product. A fully automatic plan is therefore not one with no human choices. It is one that spends human attention on the choices where context and taste matter, and automates the rest visibly.

By the end of this process, the implementation request should have a technical shape: a chosen scope, an explanation of the user value, known alternatives, system boundaries, failure modes, and tests that can distinguish success from a plausible-looking failure. The plan is ready to meet reality. The next problem is no longer deciding what the system ought to be. It is seeing what the system actually does in a browser, with state, authentication, and user-visible behavior that source files alone cannot reveal.

References