Most AI coding tools jump straight to implementation. You describe a feature, the AI generates code, and you spend the next three days fixing the assumptions it made about what you actually wanted. Gstack AI plan review solves this by inserting two structured planning phases before any code is written: /plan-ceo-review for product vision and /plan-eng-review for engineering architecture. One asks whether you are building the right thing. The other ensures you can actually build it.
These are not document generators that produce boilerplate planning templates. They are opinionated review processes that challenge your thinking, surface hidden assumptions, and produce artifacts — reframed specifications, architectural diagrams, test matrices — that directly inform implementation. Used together, they form the planning backbone of the gstack skills suite.
Two Planning Skills, Two Mindsets
The distinction between these skills is intentional. Product thinking and engineering thinking require fundamentally different mental models. Combining them into a single planning phase means one always gets shortchanged. Gstack AI plan review separates them so each mode of thinking gets full attention before anyone writes a line of code.
/plan-ceo-review
Asks "What is this product actually for?" before implementing. Challenges literal interpretation, finds the 10-star version hiding inside the request. User empathy, taste, ambition.
/plan-eng-review
Locks in architecture, system boundaries, data flow, state transitions. Forces diagrams that expose hidden assumptions. Makes the idea buildable, not smaller.
10-Star Thinking
What does a 10-star version of this feature look like? Not to build it all today, but to know the direction so every incremental step compounds toward something extraordinary.
Diagrams as Thinking Tools
Sequence, state, component, and data-flow diagrams force hidden assumptions into the open. If you cannot diagram the feature, you do not understand it well enough to build it.
The /plan-ceo-review Skill: Founder Mode
The /plan-ceo-review skill — sometimes called "Brian Chesky mode" — operates from a single premise: before you implement anything, you need to understand what this product is actually for. Not what the ticket says. Not what the user literally requested. What the underlying need is, and what the most ambitious response to that need looks like.
This matters because developers and AI tools alike are trained to take requests literally. A request for "photo upload" becomes a file picker and an S3 integration. The CEO review asks a different question: why does the user want to upload a photo? What are they trying to accomplish? And what would a version of this feature look like that makes them unreasonably happy?
How /plan-ceo-review Reframes a Feature Request
File picker, upload to S3, display thumbnail on listing page.
Auto-identify item from image, generate title and description, pull specs from product database, suggest pricing from comps.
The literal interpretation produces a file upload widget. The CEO review version produces an intelligent listing creation system where the photo is the input to an entire workflow. The user does not want to "upload a photo" — they want to create a listing with minimal effort. The photo is just the most convenient starting point they have.
What the CEO Review Actually Asks
When you run /plan-ceo-review, the skill walks through a structured evaluation of your feature request. It does not generate a plan immediately. Instead, it interrogates the request across several dimensions:
- Intent analysis — What is the user actually trying to accomplish? Is the stated request the best solution to that problem, or is it one possible approach among many?
- Ambition calibration — What does a 1-star version look like? A 5-star? A 10-star? Where on that spectrum should this feature land given your constraints and timeline?
- User empathy mapping — Who is doing this task, in what context, with what emotional state? A seller listing their first item has different needs than a power seller listing their thousandth.
- Taste and coherence — Does this feature fit the product's identity? Does it make the overall experience more coherent or more fragmented?
- Long time horizon — Where does this feature lead in six months? Does it create a foundation for compounding value, or is it a dead end that will need replacement?
The output is a reframed feature specification that preserves the core intent while raising the ambition level. It includes the reasoning behind each recommendation so you can evaluate tradeoffs yourself rather than blindly accepting the suggestion.
Key insight: The CEO review does not make the scope bigger. It makes the direction better. Often, the 10-star version of a feature is actually simpler than the original spec because it removes unnecessary steps instead of adding more features. Fewer fields, fewer clicks, more intelligence.
The /plan-eng-review Skill: Architecture Mode
Where /plan-ceo-review asks "are we building the right thing?", /plan-eng-review asks "can we actually build this, and what will break when we do?" This is engineering manager and tech lead mode. It takes a feature specification — ideally one that has already passed through the CEO review — and subjects it to rigorous architectural analysis.
The eng review does not make ideas smaller. Its job is to make them buildable. An ambitious feature that lacks architectural grounding will collapse during implementation. A well-architected plan with clear system boundaries, defined failure modes, and explicit test coverage can handle even aggressive scope because the team knows exactly what they are building and where the risks live.
Forced Diagrams: The Core Mechanism
The most distinctive feature of /plan-eng-review is that it forces diagram generation. Not optional. Not "consider adding a diagram." The skill requires concrete visual artifacts before a plan is considered complete:
- Sequence diagrams — Trace request flows from client through server to database and external services. Expose hidden service dependencies and ordering assumptions.
- State diagrams — Enumerate every state an entity can be in and every valid transition between states. Identify illegal states to guard against.
- Component diagrams — Define system boundaries and clarify which module owns which responsibility. Prevent ownership ambiguity before it causes merge conflicts.
- Data-flow diagrams — Track where data originates, how it transforms at each stage, and where it lands. Reveal hidden data dependencies.
- Test matrices — Map features against test types (unit, integration, e2e) with specific scenarios for each cell. Ensure nothing falls through the cracks.
Why force diagrams? Because diagrams force hidden assumptions into the open. A written spec can be vague and still feel complete. A sequence diagram cannot. When you draw the arrows between services, you immediately discover the unanswered questions: Who retries on failure? What happens when the downstream service is slow? Is this call synchronous or asynchronous? Where does the timeout live? These are the questions that, left unanswered, become production incidents three weeks after launch.
What the Eng Review Covers
| Area | What It Examines |
|---|---|
| System Boundaries | Which services are involved, who owns what, where are the API contracts defined |
| Data Flow | Data origin, transformations, storage locations, access patterns, migration strategy |
| State Transitions | Every state an entity can enter, valid transitions, illegal states to guard against |
| Failure Modes | Network failures, partial writes, timeout behavior, retry strategies, data consistency |
| Trust Boundaries | Input validation, authentication, authorization, data sanitization at every boundary |
| Edge Cases | Boundary conditions, empty states, permission variations, race conditions, concurrent access |
| Test Coverage | Unit tests, integration tests, e2e scenarios, test matrices, acceptance criteria |
The Full Gstack AI Plan Review Workflow
The intended workflow is sequential: CEO review first, then eng review. This ordering matters because the CEO review often changes the scope or direction of a feature, and there is no point architecting something that will be reframed. Once both reviews are complete, the outputs feed directly into implementation, testing, and code review.
/plan-ceo-review
Set direction. Find the 10-star product.
/plan-eng-review
Lock architecture. Force diagrams. Map edge cases.
Build
Implement with clear specs. No ambiguity.
Test & Ship
QA, code review, deploy with confidence.
# Step 1: Reframe the feature through product lens
/plan-ceo-review "Add photo upload to marketplace listings"
# Step 2: Architect the reframed version
/plan-eng-review
# Step 3: Build, test, review, and ship
# Plan artifacts guide every subsequent stepAfter both reviews, you have a feature specification that is both ambitious and buildable. The CEO review ensures you are solving the right problem at the right ambition level. The eng review ensures you have a concrete path to implementation with explicit handling of failure modes, edge cases, and test coverage. The result is a plan that a development team can execute without constantly pausing to ask clarifying questions.
Comparing the Two Planning Modes
| Dimension | /plan-ceo-review | /plan-eng-review |
|---|---|---|
| Core question | Are we building the right thing? | Can we build it reliably? |
| Mindset | Founder / CEO / product visionary | Eng manager / tech lead / architect |
| Primary output | Reframed feature specification | Diagrams, architecture docs, test matrices |
| Challenges | Literal interpretation of requests | Vague or hand-wavy architecture |
| Time horizon | Long-term product coherence | Implementation sprint readiness |
| Key artifacts | 10-star analysis, user empathy map | Sequence, state, component, data-flow diagrams |
| Best used for | User-facing features, new products | Any feature touching multiple systems |
When to Use Each Skill Independently
While the two skills are designed to complement each other, there are cases where one is the right tool by itself.
Use /plan-ceo-review alone when you are in early ideation, evaluating whether to build a feature at all, or brainstorming product direction. It is also valuable for reviewing competitor features — understanding why a competitor built something a certain way and whether your version should take a different approach.
Use /plan-eng-review alone when the product direction is already clear and locked in, but the engineering approach needs specification. This includes infrastructure migrations, performance optimization projects, refactoring efforts, and any work where the "what" is known but the "how" needs rigorous definition. It pairs especially well with AI code review — if a review surfaces architectural concerns, running an eng review on the proposed changes can clarify the right path forward.
Practical Example: Notification System
Consider the request: "Add email notifications for order status changes." Most implementations would wire up a transactional email template to an order status webhook and call it done. Gstack AI plan review takes a different path.
The /plan-ceo-review asks whether email is even the right channel, whether the user actually wants to know about every status change or just the ones that require action, and whether the notification itself can be actionable — one tap to confirm delivery, one tap to request a return. The feature direction shifts from "send emails about orders" to "give users the right information at the right time through the right channel with one-tap actions."
The /plan-eng-review then maps the event pipeline from order service to notification dispatcher, designs dead-letter queues for failed deliveries, specifies delivery guarantees across channels, diagrams the template rendering architecture, and produces a state machine for notification preferences with explicit handling of edge cases like unsubscribed users, bounced emails, and concurrent preference changes.
How Plan Review Connects to Other Gstack Skills
The gstack AI plan review skills feed directly into every subsequent step of the shipping workflow:
- AI Code Review validates that the implementation matches the architecture plan from
/plan-eng-review, catching drift between design and code - Automated QA Testing uses the test matrix from
/plan-eng-reviewas its test plan, ensuring coverage maps to the original specification - Shipping Workflow references the plan artifacts when validating that a feature is complete and meets acceptance criteria before merge
For teams using parallel AI coding, the component diagrams from the eng review are especially valuable. When multiple developers or AI agents work on different parts of the same feature, a shared architectural specification ensures everyone builds toward the same system boundaries, data contracts, and state transitions.
Getting Started with Gstack AI Plan Review
Both planning skills are available immediately after installing gstack. No additional configuration is needed. To try them, open Claude Code in your project directory and run either skill with a description of what you want to build:
# Start with the CEO review for product thinking
/plan-ceo-review "We need a notification system for our marketplace"
# Then run the eng review on the reframed specification
/plan-eng-review
# Or run the eng review directly if you already know what to build
/plan-eng-review "Add WebSocket-based real-time notifications
with push support, read receipts, and preference management"The skills work with any project type and any codebase. They read your existing code structure to ground their recommendations in your actual stack rather than proposing ideal-world designs that would require rewriting everything. The output of /plan-ceo-review feeds into /plan-eng-review automatically within the same session context, and the architecture plan then guides implementation.
The real cost of skipping planning: Planning is not overhead that delays shipping. It is the step that prevents three-day debugging sessions, the "wait, I thought we agreed on X" conversations, and the post-launch realization that you built a file uploader when you needed a listing creation system. The time invested in gstack AI plan review pays for itself before the first commit.