mirror of
https://github.com/garrytan/gstack.git
synced 2026-07-08 09:07:55 +02:00
feat: restore mode-posture energy to expansion + forcing + builder output
Rewrites Writing Style rule 2-4 examples in scripts/resolvers/preamble.ts
to cover three framing families (pain reduction, upside/delight, forcing
pressure) instead of diagnostic-pain only. Adds inline exemplars to
plan-ceo-review (0D-prelude shared between SCOPE + SELECTIVE EXPANSION)
and office-hours (Q3 forcing exemplar with career/day/weekend domain
gating, builder operating principles wild exemplar).
V1 shipped rule 2-4 examples that all pointed to diagnostic-pain framing
("3-second spinner", "double-click button"). Models follow concrete
examples over abstract taxonomies, so any skill with a non-diagnostic
mode posture (expansion, forcing, delight) got flattened at runtime
even when the template itself said "dream big" or "direct to the point
of discomfort." This change targets the actual lever: swap the single
diagnostic example for three paired framings, one per posture family.
Preserves V1 clarity gains — rules 2, 3, 4 principles unchanged, only
examples expanded. Terse mode (EXPLAIN_LEVEL: terse) still skips the
block entirely.
This commit is contained in:
@@ -203,6 +203,14 @@ If the framing is imprecise, **reframe constructively** — don't dissolve the q
|
||||
|
||||
**Red flags:** Category-level answers. "Healthcare enterprises." "SMBs." "Marketing teams." These are filters, not people. You can't email a category.
|
||||
|
||||
**Forcing exemplar:**
|
||||
|
||||
SOFTENED (avoid): "Who's your target user, and what gets them to buy? Worth thinking about before marketing spend ramps."
|
||||
|
||||
FORCING (aim for): "Name the actual human. Not 'product managers at mid-market SaaS companies' — an actual name, an actual title, an actual consequence. What's the real thing they're avoiding that your product solves? If this is a career problem, whose career? If this is a daily pain, whose day? If this is a creative unlock, whose weekend project becomes possible? If you can't name them, you don't know who you're building for — and 'users' isn't an answer."
|
||||
|
||||
The pressure is in the stacking — don't collapse it into a single ask. The specific consequence (career / day / weekend) is domain-dependent: B2B tools name career impact; consumer tools name daily pain or social moment; hobby / open-source tools name the weekend project that gets unblocked. Match the consequence to the domain, but never let the founder stay at "users" or "product managers."
|
||||
|
||||
#### Q4: Narrowest Wedge
|
||||
|
||||
**Ask:** "What's the smallest possible version of this that someone would pay real money for — this week, not after you build the platform?"
|
||||
@@ -257,6 +265,14 @@ Use this mode when the user is building for fun, learning, hacking on open sourc
|
||||
3. **The best side projects solve your own problem.** If you're building it for yourself, trust that instinct.
|
||||
4. **Explore before you optimize.** Try the weird idea first. Polish later.
|
||||
|
||||
**Wild exemplar:**
|
||||
|
||||
STRUCTURED (avoid): "Consider adding a share feature. This would improve user retention by enabling virality."
|
||||
|
||||
WILD (aim for): "Oh — and what if you also let them share the visualization as a live URL? Or pipe it into a Slack thread? Or animate the generation so viewers see it draw itself? Each one's a 30-minute unlock. Any of them turn this from 'a tool I used' into 'a thing I showed a friend.'"
|
||||
|
||||
Both are outcome-framed. Only one has the 'whoa.' Builder mode's job is to surface the most exciting version of the idea, not the most strategically optimized one. Lead with the fun; let the user edit it down.
|
||||
|
||||
### Response Posture
|
||||
|
||||
- **Enthusiastic, opinionated collaborator.** You're here to help them build the coolest thing possible. Riff on their ideas. Get excited about what's exciting.
|
||||
|
||||
Reference in New Issue
Block a user