Real-World Dev Scenario: The Complete Gstack Workflow from New Feature to Production

The previous five posts introduced each Gstack skill individually — but after reading them, you might still have one question:

"How do these skills actually chain together?"

Knowing that /plan-ceo-review handles product decisions and /review finds production-level bugs isn't enough — you need to know where each skill fits in a real development cycle and what to do after running each one.

This post demonstrates the complete workflow using a concrete scenario.

The Scenario

You're building a SaaS tool, and you want to add a new feature: users can merge multiple reports and export them as a single PDF.

The request came from feedback from about 15 users. You believe it's high priority — but you haven't started writing any code.

Step 1: `/plan-ceo-review` — Ask Whether It's Worth Building First

Open Claude Code and type:

/plan-ceo-review

I want to add a "merge export to PDF" feature. Users can select multiple reports, and the system combines them into one PDF for download.
The request comes from feedback from about 15 users, primarily consultant-type users who regularly need to deliver reports to clients.

Gstack's CEO mode will ask you a few questions:

These 15 users — how are they solving this problem right now? Manually combining PDFs? Using another tool?
Is "merge export" their solution, or is it their problem? Is their real pain point "delivering reports to clients is tedious"?
Is there possibly a more fundamental solution beyond "merge export" — like letting reports have a "share link" for clients directly?
If the merge PDF requirement is valid, do merge order, report covers, and watermarks need to be in v1, or do we ship the simplest version first?

These questions force you to confirm one thing before you start: you're solving the user's actual problem, not the problem you assumed they had.

Say after running this you confirm: merge PDF is genuinely their core need, v1 ships the simplest version (select reports + merge download), advanced features come later.

Step 2: `/plan-eng-review` — Turn "What to Build" into "How to Build It Right"

Decision locked, switch to engineer mode:

/plan-eng-review

Feature confirmed: users can check off multiple reports in the dashboard (up to 10), click "merge export," the system merges in the background, and notifies the user when download is ready.
Average report is 5-20 pages, max single report is 50 pages.
Our backend is Node.js + PostgreSQL, reports are stored in S3.

Gstack's engineer mode outputs:

Sequence diagram — user triggers → backend receives request → background job starts → fetches reports from S3 → merges PDF → saves back to S3 → notifies user. The diagram shows the async boundaries.

Edge case list:

What if one report's S3 URL expires during the merge process?
What happens if the user triggers again while the job is still running?
How long should the merged PDF be stored? Is there a cleanup mechanism?
How long will merging 10 reports take? What should the timeout be?

Test matrix:

Unit test: PDF merge logic
Integration test: complete background job flow
E2E: the complete path from user selecting reports to downloading

This output is your architecture design document before you write any code. Having it to reference when you run into issues during implementation is far clearer than asking Claude "how do I write this" from scratch.

Step 3: Implementation

This is where Gstack steps back and you (and Claude) write code.

Use Claude Code to implement based on the /plan-eng-review design. You can continue the conversation when you hit technical issues, but you don't need any specific Gstack skill — this phase is pure implementation.

When you're done, confirm:

Core functionality works
Basic unit tests are written
Locally tested, no obvious issues

Step 4: `/review` — Find the Problems That Pass CI but Blow Up in Production

/review

No additional context needed. Gstack reads your git diff and finds issues introduced by this change.

Say this time it finds:

Critical: Race condition in PDF merging under concurrent requests — if the user clicks twice quickly, two jobs might trigger, creating duplicate charges and results
High: Presigned S3 URLs expire after 1 hour if the background job runs for more than that, but timeout is set to 2 hours
Medium: No cleanup mechanism for merged PDFs, S3 costs will keep growing

You fix the Critical and High issues, open a ticket for Medium to handle next sprint.

Step 5: `/qa` — Let AI Test the Feature with a Real Browser

/qa

Gstack analyzes the git diff, identifies affected pages — primarily the report list page and export status page in the dashboard — then opens a browser and tests:

Select three reports, trigger merge, confirm background job starts
Wait for job to finish, confirm notification appears and download link works
Download PDF, confirm content is correct
Test edge case of selecting only one report
Test the flow of selecting reports then canceling

Outputs a health score at the end. Say it's 87 — main flows are working, a few minor UX issues (like loading state text not being clear enough), but nothing blocking.

Step 6: `/ship` — One-Command Delivery

/ship

Gstack runs the complete release checklist:

✅ Sync main — branch is synced with main
✅ Run tests — all tests pass
✅ Push branch — pushed to remote
✅ Open PR — PR created with a clear description covering the scope of changes, testing approach, and the known medium issue

You review the PR and merge.

Complete Workflow at a Glance

New feature requirement
    ↓
/plan-ceo-review   ← confirm "is it worth building," define scope clearly
    ↓
/plan-eng-review   ← design architecture, identify edge cases and failure modes
    ↓
Implementation (Claude Code + you)
    ↓
/review            ← find production-level issues, fix critical / high
    ↓
/qa                ← browser testing, confirm feature works at the UI level
    ↓
/ship              ← sync, test, push, PR — the full pipeline
    ↓
Merge, ship to production

How Long Does This Flow Take?

One complete cycle, six steps, not counting implementation time:

/plan-ceo-review: 10-15 minutes (conversation + thinking)
/plan-eng-review: 10-20 minutes (complex features need more output time)
/review: 5-10 minutes (read results + fix critical issues)
/qa: 5-15 minutes (depends on number of affected pages)
/ship: 2-3 minutes

Total: 30-60 minutes, not counting implementation. Sounds like a lot, but the problems these six steps prevent typically take much longer to clean up.

Not Every Feature Needs the Full Flow

Smaller changes can skip some steps:

Fixing a small bug: straight to /review + /ship, skip Plan Review
Copy or style changes: /qa to confirm visuals, then /ship
Adding a settings option: /plan-eng-review (quick architecture check) + /review + /ship

The judgment call is one question: if this change goes wrong, how much time and effort does it take to fix? The bigger the answer, the more worthwhile it is to run the full flow.

The Gstack series is now complete. One person, nine cognitive modes, one repeatable development rhythm — from "is it worth building" to "shipping to production," every phase has a corresponding tool, no relying on memory or luck.

→ Back to the Gstack Beginner Course Series Overview

The Scenario

Step 1: /plan-ceo-review — Ask Whether It's Worth Building First

Step 2: /plan-eng-review — Turn "What to Build" into "How to Build It Right"

Step 3: Implementation

Step 4: /review — Find the Problems That Pass CI but Blow Up in Production

Step 5: /qa — Let AI Test the Feature with a Real Browser

Step 6: /ship — One-Command Delivery