Part 2 of 2 of plan-devex-review skill (gstack) (plan-devex-review/SKILL.md in garrytan/gstack); the SKILL.md text continues verbatim from the previous part.

SKILL.md (verbatim, continued)

_EG="$HOME/.claude/skills/gstack/bin/gstack-egress-lib.sh"; [ -r "$_EG" ] && . "$_EG"; _aside_exec() { if command -v _gstack_egress_run >/dev/null 2>&1; then _gstack_egress_run open aside-agent aside.com aside-exec "user invoked this skill" --no-payload aside exec "$@"; else aside exec "$@"; fi; }
_aside_exec "Search the web for [closest competitor] developer onboarding time and time to hello world. Read-only: do not sign in, submit, or change anything. Reply with up to 6 bullets, each with the stated setup time and its source URL, then stop."

If the Aside check did not print READY, run the same searches with the WebSearch tool when the host provides it. With neither: "Search unavailable. Using reference benchmarks: Stripe (30s TTHW), Vercel (2min), Firebase (3min), Docker (5min)."

Produce a competitive benchmark table:

COMPETITIVE DX BENCHMARK
=========================
Tool              | TTHW      | Notable DX Choice          | Source
[competitor 1]    | [time]    | [what they do well]        | [url/source]
[competitor 2]    | [time]    | [what they do well]        | [url/source]
[competitor 3]    | [time]    | [what they do well]        | [url/source]
YOUR PRODUCT      | [est]     | [from README/plan]         | current plan

AskUserQuestion:

"Your closest competitors' TTHW: [benchmark table]

Your plan's current TTHW estimate: [X] minutes ([Y] steps).

Where do you want to land?

A) Champion tier (< 2 min) -- requires [specific changes]. Stripe/Vercel territory. B) Competitive tier (2-5 min) -- achievable with [specific gap to close] C) Current trajectory ([X] min) -- acceptable for now, improve later D) Tell me what's realistic for our constraints"

STOP. The chosen tier becomes the benchmark for Pass 1 (Getting Started).

0D. Magical Moment Design

Every great developer tool has a magical moment: the instant a developer goes from "is this worth my time?" to "oh wow, this is real."

Load the "## Pass 1" section from ~/.claude/skills/gstack/plan-devex-review/dx-hall-of-fame.md for gold standard examples.

Identify the most likely magical moment for this product type, then present delivery vehicle options with tradeoffs.

AskUserQuestion:

"For your [product type], the magical moment is: [specific moment, e.g., 'seeing their first API response with real data' or 'watching a deployment go live'].

How should your [persona from 0A] experience this moment?

A) Interactive playground/sandbox -- zero install, try in browser. Highest conversion but requires building a hosted environment. (human: ~1 week / CC: ~2 hours). Examples: Stripe's API explorer, Supabase SQL editor.

B) Copy-paste demo command -- one terminal command that produces the magical output. Low effort, high impact for CLI tools, but requires local install first. (human: ~2 days / CC: ~30 min). Examples: npx create-next-app, docker run hello-world.

C) Video/GIF walkthrough -- shows the magic without requiring any setup. Passive (developer watches, doesn't do), but zero friction. (human: ~1 day / CC: ~1 hour). Examples: Vercel's homepage deploy animation.

D) Guided tutorial with the developer's own data -- step-by-step with their project. Deepest engagement but longest time-to-magic. (human: ~1 week / CC: ~2 hours). Examples: Stripe's interactive onboarding.

E) Something else -- describe what you have in mind.

RECOMMENDATION: [A/B/C/D] because for [persona], [reason]. Your competitor [name] uses [their approach]."

STOP. The chosen delivery vehicle is tracked through the scoring passes.

0E. Mode Selection

How deep should this DX review go?

Present three options:

AskUserQuestion:

"How deep should this DX review go?

A) DX EXPANSION -- Your developer experience could be a competitive advantage. I'll propose ambitious DX improvements beyond what the plan covers. Every expansion is opt-in via individual questions. I'll push hard.

B) DX POLISH -- The plan's DX scope is right. I'll make every touchpoint bulletproof: error messages, docs, CLI help, getting started. No scope additions, maximum rigor. (recommended for most reviews)

C) DX TRIAGE -- Focus only on the critical DX gaps that would block adoption. Fast, surgical, for plans that need to ship soon.

RECOMMENDATION: [mode] because [one-line reason based on plan scope and product maturity]."

Context-dependent defaults:

• New developer-facing product → default DX EXPANSION
• Enhancement to existing product → default DX POLISH
• Bug fix or urgent ship → default DX TRIAGE

Once selected, commit fully. Do not silently drift toward a different mode.

STOP. Do NOT proceed until user responds.

0F. Developer Journey Trace with Friction-Point Questions

Replace the static journey map with an interactive, evidence-grounded walkthrough. For each journey stage, TRACE the actual experience (what file, what command, what output) and ask about each friction point individually.

For each stage (Discover, Install, Hello World, Real Usage, Debug, Upgrade):

1. Trace the actual path. Read the README, docs, package.json, CLI help, or whatever the developer would encounter at this stage. Reference specific files and line numbers.

2. Identify friction points with evidence. Not "installation might be hard" but "Step 3 of the README requires Docker to be running, but nothing checks for Docker or tells the developer to install it. A [persona] without Docker will see [specific error or nothing]."

3. AskUserQuestion per friction point. One question per friction point found. Do NOT batch multiple friction points into one question.

   "Journey Stage: INSTALL

   I traced the installation path. Your README says: [actual install instructions]

   Friction point: [specific issue with evidence]

   A) Fix in plan -- [specific fix] B) [Alternative approach] C) Document the requirement prominently D) Acceptable friction -- skip"

DX TRIAGE mode: Only trace Install and Hello World stages. Skip the rest. DX POLISH mode: Trace all stages. DX EXPANSION mode: Trace all stages, and for each stage also ask "What would make this stage best-in-class?"

After all friction points are resolved, produce the updated journey map:

STAGE           | DEVELOPER DOES              | FRICTION POINTS      | STATUS
----------------|-----------------------------|--------------------- |--------
1. Discover     | [action]                    | [resolved/deferred]  | [fixed/ok/deferred]
2. Install      | [action]                    | [resolved/deferred]  | [fixed/ok/deferred]
3. Hello World  | [action]                    | [resolved/deferred]  | [fixed/ok/deferred]
4. Real Usage   | [action]                    | [resolved/deferred]  | [fixed/ok/deferred]
5. Debug        | [action]                    | [resolved/deferred]  | [fixed/ok/deferred]
6. Upgrade      | [action]                    | [resolved/deferred]  | [fixed/ok/deferred]

0G. First-Time Developer Roleplay

Using the persona from 0A and the journey trace from 0F, write a structured "confusion report" from the perspective of a first-time developer. Include timestamps to simulate real time passing.

FIRST-TIME DEVELOPER REPORT
============================
Persona: [from 0A]
Attempting: [product] getting started

CONFUSION LOG:
T+0:00  [What they do first. What they see.]
T+0:30  [Next action. What surprised or confused them.]
T+1:00  [What they tried. What happened.]
T+2:00  [Where they got stuck or succeeded.]
T+3:00  [Final state: gave up / succeeded / asked for help]

Ground this in the ACTUAL docs and code from the pre-review audit. Not hypothetical. Reference specific README headings, error messages, and file paths.

AskUserQuestion:

"I roleplayed as your [persona] developer attempting the getting started flow. Here's what confused me:

[confusion report]

Which of these should we address in the plan?

A) All of them -- fix every confusion point B) Let me pick which ones matter C) The critical ones (#[N], #[N]) -- skip the rest D) This is unrealistic -- our developers already know [context]"

STOP. Do NOT proceed until user responds.

---

The 0-10 Rating Method

For each DX section, rate the plan 0-10. If it's not a 10, explain WHAT would make it a 10, then do the work to get it there.

Critical rule: Every rating MUST reference evidence from Step 0. Not "Getting Started: 4/10" but "Getting Started: 4/10 because [persona from 0A] hits [friction point from 0F] at step 3, and competitor [name from 0C] achieves this in [time]."

Pattern:

1. Evidence recall: Reference specific findings from Step 0 that apply to this dimension
2. Rate: "Getting Started Experience: 4/10"
3. Gap: "It's a 4 because [evidence]. A 10 would be [specific description for THIS product]."
4. Load Hall of Fame reference for this pass (read relevant section from dx-hall-of-fame.md)
5. Fix: Edit the plan to add what's missing
6. Re-rate: "Now 7/10, still missing [specific gap]"
7. AskUserQuestion if there's a genuine DX choice to resolve
8. Fix again until 10 or user says "good enough, move on"

Mode-specific behavior:

• DX EXPANSION: After fixing to 10, also ask "What would make this dimension best-in-class? What would make [persona] rave about it?" Present expansions as individual opt-in AskUserQuestions.
• DX POLISH: Fix every gap. No shortcuts. Trace each issue to specific files/lines.
• DX TRIAGE: Only flag gaps that would block adoption (score below 5). Skip gaps that are nice-to-have (score 5-7).

STOP. Before running the 8 DX passes, required outputs, and review report (only after Step 0 investigation is complete), Read ~/.claude/skills/gstack/plan-devex-review/sections/review-sections.md and execute it in full. Do not work from memory — that section is the source of truth for this step.

Section self-check (before you finish)

Confirm you Read the review section the Section index named, and executed all 8 DX passes, the required outputs, and the review report in full. If you produced findings or the review report from memory without Reading sections/review-sections.md, stop and Read it now.

EXIT PLAN MODE GATE (BLOCKING)

Before calling ExitPlanMode, run this self-check. If any item fails, do the missing work — do NOT call ExitPlanMode:

1. Read the plan file with the Read tool (after your most recent write to it).
2. Confirm the LAST ## heading in the file is ## GSTACK REVIEW REPORT. In-body prose that mentions "outside voice", "codex findings", or similar does NOT count — only the structured ## GSTACK REVIEW REPORT section satisfies this check.
3. Confirm the report has a Runs / Status / Findings table and a VERDICT line (CODEX / CROSS-MODEL absorbed if applicable).
4. Confirm the report's FINAL non-whitespace line is the unresolved-decisions status: the exact unbolded NO UNRESOLVED DECISIONS, or a bullet of a final **UNRESOLVED DECISIONS:** block. BLOCKING, no "if applicable" escape — a bolded sentinel, any trailing CODEX/CROSS-MODEL/VERDICT/prose, or a missing status each FAILS the gate.
5. If a plan file is in context for this skill invocation: confirm gstack-review-log was called and gstack-review-read was run at least once. If no plan file is in context (e.g. /codex consult against a diff with no plan), this check short-circuits — checks 1-4 already short-circuit when no plan file exists.

Failing this gate and calling ExitPlanMode anyway is a contract violation — the user will see a plan whose review report is missing or stale, and will (correctly) reject it. Self-deception failure mode to watch for: feeling "done" after writing review prose into the plan body. The body prose is not the report. The report is a separate, structured, table-bearing section that must be the file's terminal heading.

Other files in this skill

• SKILL.md.tmpl
• dx-hall-of-fame.md
• sections/manifest.json
• sections/review-sections.md
• sections/review-sections.md.tmpl

dx-hall-of-fame.md (verbatim)

DX Hall of Fame Reference

Read ONLY the section for the current review pass. Do NOT load the entire file.

Pass 1: Getting Started

Gold standards:

• Stripe: 7 lines of code to charge a card. Docs pre-fill YOUR test API keys when logged in. Stripe Shell runs CLI inside docs page. No local install needed.
• Vercel: git push = live site on global CDN with HTTPS. Every PR gets preview URL. One CLI command: vercel.
• Clerk: <SignIn />, <SignUp />, <UserButton />. 3 JSX components, working auth with email, social, MFA out of the box.
• Supabase: Create a Postgres table, auto-generates REST API + Realtime + self-documenting docs instantly.
• Firebase: onSnapshot(). 3 lines for real-time sync across all clients with offline persistence built-in.
• Twilio: Virtual Phone in console. Send/receive SMS without buying a number, no credit card. Result: 62% improvement in activation.

Anti-patterns:

• Email verification before any value (breaks flow)
• Credit card required before sandbox
• "Choose your own adventure" with multiple paths (decision fatigue; one golden path wins)
• API keys hidden in settings (Stripe pre-fills them into code examples)
• Static code examples without language switching
• Separate docs site from dashboard (context switching)

Pass 2: API/CLI/SDK Design

Gold standards:

• Stripe prefixed IDs: ch_ for charges, cus_ for customers. Self-documenting. Impossible to pass wrong ID type.
• Stripe expandable objects: Default returns ID strings. expand[] gets full objects inline. Nested expansion up to 4 levels.
• Stripe idempotency keys: Pass Idempotency-Key header on mutations. Safe retries. No "did I double-charge?" anxiety.
• Stripe API versioning: First call pins account to that day's version. Test new versions per-request via Stripe-Version header.
• GitHub CLI: Auto-detects terminal vs pipe. Human-readable in terminal, tab-delimited when piped. gh pr <tab> shows all PR actions.
• SwiftUI progressive disclosure: Button("Save") { save() } to full customization, same API at every level.
• htmx: HTML attributes replace JS. 14KB total. hx-get="/search" hx-trigger="keyup changed delay:300ms". Zero build step.
• shadcn/ui: Copy source code into your project. You own every line. No dependency, no version conflicts.

Anti-patterns:

• Chatty API: requiring 5 calls for one user-visible action
• Inconsistent naming: /users (plural) vs /user/123 (singular) vs /create-order (verb in URL)
• Implicit failure: 200 OK with error nested in response body
• God endpoint: 47 parameter combinations with different behavior per subset
• Documentation-required API: 3 pages of docs before first call = too much ceremony

Pass 3: Error Messages & Debugging

Three tiers of error quality:

Tier 1, Elm (Conversational Compiler):

-- TYPE MISMATCH ---- src/Main.elm
I cannot do addition with String values like this one:
42|   "hello" + 1
     ^^^^^^^
Hint: To put strings together, use the (++) operator instead.

First person, complete sentences, exact location, suggested fix, further reading.

Tier 2, Rust (Annotated Source):

error[E0308]: mismatched types
 --> src/main.rs:4:20
help: consider borrowing here
  |
4 |     let name: &str = &get_name();
  |                       +

Error code links to tutorial. Primary + secondary labels. Help section shows exact edit.

Tier 3, Stripe API (Structured with doc_url):

{"error":{"type":"invalid_request_error","code":"resource_missing","message":"No such customer: 'cus_nonexistent'","param":"customer","doc_url":"https://stripe.com/docs/error-codes/resource-missing"}}

Five fields, zero ambiguity.

The formula: What happened + Why + How to fix + Where to learn more + Actual values that caused it.

Anti-pattern: TypeScript buries "Did you mean?" at the BOTTOM of long error chains. Most actionable info should appear FIRST.

Pass 4: Documentation & Learning

Gold standards:

• Stripe docs: Three-column layout (nav / content / live code). API keys injected when logged in. Language switcher persists across ALL pages. Hover-to-highlight. Stripe Shell for in-browser API calls. Built and open-sourced Markdoc. Features don't ship until docs are finalized. Docs contributions affect performance reviews.
• 52% of developers blocked by lack of documentation (Postman 2023)
• Companies with world-class docs see 2.5x increase in adoption
• "Docs as product": ships with the feature or the feature doesn't ship

Pass 5: Upgrade & Migration Path

Gold standards:

• Next.js: npx @next/codemod upgrade major. One command upgrades Next.js, React, React DOM, runs all relevant codemods.
• AG Grid: Every release from v31+ includes a codemod.
• Stripe API versioning: One codebase internally. Version pinning per account. Breaking changes never surprise you.
• Martin Fowler's pipeline pattern: Compose small, testable transformations rather than one monolithic codemod.
• 21.9% of breaking changes in Maven Central were undocumented (Ochoa et al., 2021)

Pass 6: Developer Environment & Tooling

Gold standards:

• Bun: 100x faster than npm install, 4x faster than Node.js runtime. Speed IS DX.
• 87 interruptions per day average; 25 minutes to recover from each. Devs code only 2-4 hours/day.
• Each 1-point DXI improvement = 13 minutes saved per developer per week.
• GitHub Copilot: 55.8% faster task completion. PR time from 9.6 days to 2.4 days.

Pass 7: Community & Ecosystem

• Dev tools require ~14 exposures before purchase (Matt Biilmann, Netlify). Incompatible with quarterly OKR cycles.
• 4-5x performance multiplier for teams with strong developer experience (DevEx framework).

Pass 8: DX Measurement

Three academic frameworks:

1. SPACE (Microsoft Research, 2021): Satisfaction, Performance, Activity, Communication, Efficiency. Measure at least 3 dimensions.
2. DevEx (ACM Queue, 2023): Feedback Loops, Cognitive Load, Flow State. Combine perceptual + workflow data.
3. Fagerholm & Munch (IEEE, 2012): Cognition, Affect, Conation. The psychological "trilogy of mind."

Claude Code Skill DX Checklist

Use when reviewing plans for Claude Code skills, MCP servers, or AI agent tools.

• AskUserQuestion design: One issue per call. Re-ground context (project, branch, task). Browser handoff for visual feedback.
• State storage: Global (~/.tool/) vs per-project ($SLUG/) vs per-session. Append-only JSONL for audit trails.
• Progressive consent: One-time prompts with marker files. Never re-ask. Reversible.
• Auto-upgrade: Version check with cache + snooze backoff. Migration scripts. Inline offer.
• Skill composition: Benefits-from chains. Review chaining. Inline invocation with section skipping.
• Error recovery: Resume from failure. Partial results preserved. Checkpoint-safe.
• Session continuity: Timeline events. Compaction recovery. Cross-session learnings.
• Bounded autonomy: Clear operational limits. Mandatory escalation for destructive actions. Audit trails.

Reference implementations: gstack's design-shotgun loop, auto-upgrade flow, progressive consent, hierarchical storage.

Back to garrytan/gstack (Garry Tan's Claude Code skill suite) or Agent skills.