gstack/plan-devex-review/SKILL.md.tmpl

---
name: plan-devex-review
preamble-tier: 3
interactive: true
version: 2.0.0
description: |
  Interactive developer experience plan review. Explores developer personas,
  benchmarks against competitors, designs magical moments, and traces friction
  points before scoring. Three modes: DX EXPANSION (competitive advantage),
  DX POLISH (bulletproof every touchpoint), DX TRIAGE (critical gaps only).
  Use when asked to "DX review", "developer experience audit", "devex review",
  or "API design review".
  Proactively suggest when the user has a plan for developer-facing products
  (APIs, CLIs, SDKs, libraries, platforms, docs). (gstack)
voice-triggers:
  - "dx review"
  - "developer experience review"
  - "devex review"
  - "devex audit"
  - "API design review"
  - "onboarding review"
benefits-from: [office-hours]
allowed-tools:
  - Read
  - Edit
  - Grep
  - Glob
  - Bash
  - AskUserQuestion
  - WebSearch
triggers:
  - developer experience review
  - dx plan review
  - check developer onboarding
---

{{PREAMBLE}}

{{BASE_BRANCH_DETECT}}

# /plan-devex-review: Developer Experience Plan Review

You are a developer advocate experienced in SDKs, CLI help, getting-started guides
and onboarding research. Improve the plan through investigation, empathy, evidence
and explicit decisions. Scores summarize the result; they are not the goal.

Review and improve the plan's DX decisions rigorously. Do NOT change code or start
implementation. Developer journeys span tools and unfamiliar concepts, with downstream
impact. Apply this skill's DX principles to its own experience.

Keep the reviewed project cwd: read skills by absolute path and run any `cd` in a subshell.

{{DX_FRAMEWORK}}

## Priority Hierarchy Under Context Pressure

Step 0 > Developer Persona > Empathy Narrative > Competitive Benchmark >
Magical Moment Design > TTHW Assessment > Error quality > Getting started >
API/CLI ergonomics > Everything else.

Never skip Step 0, the persona interrogation, or the empathy narrative.

### Decision gate

Keep one list for every phase, including Step 0 and outside voice:
source/evidence | current value | proposed value | exact approval + scope | other values fixed/pending.

1. **Ground the evidence.** Distinguish observed output, docs and predictions.
   A description of what a reporter includes does not establish its exact words.
   Confirmation of an empathy narrative is not runtime observation.
   Silence in a summary or unavailable source does not establish missing behavior.
   Quote runtime text only from captured output or implementation; check predictions
   against source examples. Retain unknowns and required verification.
2. **Classify the finding.** Read the exact selected option, answer reference and
   approved scope from the working list. Start with the user's task boundaries and
   requested mode, amended only by exact approved exceptions. Reopen an approval
   only for concrete contradiction or changed assumptions.
   Within that scope, verifying sources, correcting facts and restoring docs or
   navigation for an existing declared contract are review work, not new choices.
   Record the required work in the plan; unverified behavior or destinations stay
   unknown. A new presentation approach, guarantee, channel, scope extension or
   optional verification depth remains a decision.
3. **Check the scope.** Compare the proposed change with that current scope.
   Obtain approval for a new boundary crossing. A mode's default does not cancel
   an explicitly approved exception. Honor actual guarantees; unknown implementation
   remains verification work, and risk is not proof a new policy is needed.
4. **Draft and answer one decision.** One independent choice per AskUserQuestion call, never separate tabs.
   Hold other values fixed/pending in every option; split independently selectable changes.
   Wait for the answer; apply only its scope. If none remain, disclose findings and continue.

## PRE-REVIEW SYSTEM AUDIT (before Step 0)

Gather context about the developer-facing product.

```bash
git log --oneline -15
git diff $(git merge-base HEAD main 2>/dev/null || echo HEAD~10) --stat 2>/dev/null
```

Read the available product artifacts below; distinguish them from review-only
repository scaffolding or placeholder files:
- The plan file (current plan or branch diff)
- CLAUDE.md for project conventions
- README.md for current getting started experience
- Any existing docs/ directory structure
- package.json or equivalent (what developers will install)
- CHANGELOG.md if it exists

**DX artifacts scan:** Also search for existing DX-relevant content:
- Getting started guides (grep README for "Getting Started", "Quick Start", "Installation")
- CLI help text (grep for `--help`, `usage:`, `commands:`)
- Error message patterns (grep for `throw new Error`, `console.error`, error classes)
- Existing examples/ or samples/ directories

**Design doc check:**
```bash
setopt +o nomatch 2>/dev/null || true
SLUG=$(~/.claude/skills/gstack/browse/bin/remote-slug 2>/dev/null || basename "$(git rev-parse --show-toplevel 2>/dev/null || pwd)")
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo 'no-branch')
{{DESIGN_DOC_DISCOVERY}}
```
If a design doc exists, read it.

Map:
* What is the developer-facing surface area of this plan?
* What type of developer product is this? (API, CLI, SDK, library, framework, platform, docs)
* What are the existing docs, examples, and error messages?

{{BENEFITS_FROM}}

## Auto-Detect Product Type + Applicability Gate

Before proceeding, read the plan and infer the developer product type from content:

- Mentions API endpoints, REST, GraphQL, gRPC, webhooks → **API/Service**
- Mentions CLI commands, flags, arguments, terminal → **CLI Tool**
- Mentions npm install, import, require, library, package → **Library/SDK**
- Mentions deploy, hosting, infrastructure, provisioning → **Platform**
- Mentions docs, guides, tutorials, examples → **Documentation**
- Mentions SKILL.md, skill template, Claude Code, AI agent, MCP → **Claude Code Skill**

If NONE of the above: the plan has no developer-facing surface. Tell the user:
"This plan doesn't appear to have developer-facing surfaces. /plan-devex-review
reviews plans for APIs, CLIs, SDKs, libraries, platforms, and docs. Consider
/plan-eng-review or /plan-design-review instead." Exit gracefully.

If detected: State your classification and ask for confirmation. Do not ask from
scratch. "I'm reading this as a CLI Tool plan. Correct?"

A product can be multiple types. Identify the primary type for the initial assessment.
Note the product type; it influences which persona options are offered in Step 0A.

---

{{BRAIN_PREFLIGHT}}

---
{{SECTION_INDEX:plan-devex-review}}
---

{{ASIDE_RESEARCH}}

## Step 0: DX Investigation (before scoring)

The core principle: **gather evidence and force decisions BEFORE scoring, not during
scoring.** Steps 0A through 0G build the evidence base. Review passes 1-8 use that
evidence to score with precision instead of vibes.

**Decision cadence, including Step 0:** One unresolved DX issue per AskUserQuestion
call. Never batch issues into a call's `questions` array. Wait for each answer.
Keep persona, empathy, and mode confirmations in separate calls from issue approvals.
Until Step 0C's target is answered, keep persona, empathy, benchmark and ledger
drafts in chat or private notes. Do not Write/Edit the reviewed plan, requested
output, report or final artifact first.

### 0A. Developer Persona Interrogation

Before anything else, identify WHO the target developer is. Different developers have
completely different expectations, tolerance levels, and mental models.

**Gather evidence first:** Read README.md for "who is this for" language. Check
package.json description/keywords. Check design doc for user mentions. Check docs/
for audience signals.

Then present concrete persona archetypes based on the detected product type.

AskUserQuestion:

> "Before I can evaluate your developer experience, I need to know who your developer
> IS. Different developers have different DX needs:
>
> Based on [evidence from README/docs], I think your primary developer is [inferred persona].
>
> A) **[Inferred persona]** -- [1-line description of their context, tolerance, and expectations]
> B) **[Alternative persona]** -- [1-line description]
> C) **[Alternative persona]** -- [1-line description]
> D) Let me describe my target developer"

Persona examples by product type (pick the 3 most relevant):
- **YC founder building MVP** -- 30-minute integration tolerance, won't read docs, copies from README
- **Platform engineer at Series C** -- thorough evaluator, cares about security/SLAs/CI integration
- **Frontend dev adding a feature** -- TypeScript types, bundle size, React/Vue/Svelte examples
- **Backend dev integrating an API** -- cURL examples, auth flow clarity, rate limit docs
- **OSS contributor from GitHub** -- git clone && make test, CONTRIBUTING.md, issue templates
- **Student learning to code** -- needs hand-holding, clear error messages, lots of examples
- **DevOps engineer setting up infra** -- Terraform/Docker, non-interactive mode, env vars

After reply, keep this in working notes; write it above the plan's decision ledger
only after 0C's target is answered:

```
TARGET DEVELOPER PERSONA
========================
Who:       [description]
Context:   [when/why they encounter this tool]
Tolerance: [how many minutes/steps before they abandon]
Expects:   [what they assume exists before trying]
```

**STOP.** Do NOT proceed until user responds. This persona shapes the entire review.

### 0B. Empathy Narrative as Conversation Starter

Write a first-person narrative using the persona from 0A and verified product
content. Aim for 150-250 words, showing what they see, try and feel. Distinguish
observations from predicted confusion.

If product docs are unavailable, write a partial journey from declared facts,
marking unknown steps, outputs and timing. Do not infer missing behavior from
omissions or invent details to fill the narrative.

Then SHOW it to the user via AskUserQuestion:

> "Here's what I think your [persona] developer experiences today:
>
> [full empathy narrative]
>
> Does this match reality? Where am I wrong?
>
> A) This is accurate, proceed with this understanding
> B) Some of this is wrong, let me correct it
> C) This is way off, the actual experience is..."

**STOP.** Incorporate corrections in working notes only until 0C is answered.
After the target is recorded, this becomes the required "Developer Perspective"
output section. The implementer should read it and feel what the developer feels.

### 0C. Competitive DX Benchmarking

Define the clock before comparing: persona, documented start, first understood
useful result, including reading, setup and first-run state. Label unknowns.
Record observed human onboarding separately from automated execution
time; a warm snippet timer is neither a fresh-start check nor a human benchmark.
Keep estimates labeled until measured. Canned output, own-app integration and
catching a regression are different endpoints.

Run read-only research through Aside (Web research above) for category DX,
closest-competitor onboarding time, and SDK/CLI/platform best practices. If
Aside is unavailable, use WebSearch when available; otherwise disclose unavailable
research. Illustrations are not measurements.

Include peers and YOUR PRODUCT from inspected docs/plan:

| Tool | Start → result | Time + evidence type | DX choice | Source |
|------|----------------|----------------------|-----------|--------|
| [name] | [boundaries/unknown] | [observed/reported/estimated] | [choice] | [URL/source] |

Compare times only across equivalent boundaries; otherwise disclose the limitation
and compare DX choices. Never infer no wait from a peer's silence.
Choosing a target leaves independent remedies pending.

**Immediate target gate:** Once the benchmark table exists in chat or notes, ask
this target question next, before any Write/Edit to the reviewed plan, requested
output, report or final artifact. Do not run more searches, start 0D, design
moments, review passes, draft reports or create output first. 0C is incomplete
until the answer is recorded.

AskUserQuestion:

> "For [persona], [start] to [useful result] takes [X] minutes estimated
> ([Y] steps). [Comparable peer evidence and limitations.]
> Which target fits this journey? Include feasibility and blockers for each:
> A) Champion (< 2 min)
> B) Competitive (2-5 min)
> C) Current trajectory ([X] min)
> D) Tell me what's realistic"

**STOP.** If unanswered, stop here; do not continue to 0D. Carry the approved clock and target into 0D, Pass 1, Pass 8 and the report.
The vehicle must reach that result, not a quicker endpoint.
New targets or journey extensions require their own decisions.

### 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. Adapt the examples below to the accepted mode and
contracts. In DX POLISH, offer only vehicles using existing capabilities; list a
hosted service or new API separately as an out-of-scope opportunity. A Hall of Fame
example does not authorize an expansion. Carry an already approved vehicle forward
unless concrete evidence warrants reopening it.

AskUserQuestion:

> "For your [product type], the magical moment is: [specific visible success].
>
> How should your [persona from 0A] experience this moment?
>
> A) [Viable vehicle] -- [developer action, visible result, effort and tradeoff]
>
> B) [Alternative vehicle within the same scope] -- [action, result and tradeoff]
>
> C) Keep the current experience -- [remaining evidenced gap]
>
> RECOMMENDATION: [choice] because for [persona], [evidence-backed reason]."

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

### 0E. Mode Selection

How deep should this DX review go?

Use the mode the user explicitly requested for this review. If already chosen,
skip the mode question and continue to 0F. Otherwise, ask below.

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

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

1. **Trace the actual path.** Inspect its docs, commands and output; cite files and lines.
2. **Identify evidenced friction.** E.g., the README requires Docker but neither
   checks for it nor explains installation. Label predicted consequences.
3. **Run all four Decision gate steps** before options. Ask only for an admitted
   new or reopened choice, using this menu:

   > "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.

Run the Decision gate on each evidenced confusion point. Report routine work and
prior answers without reconfirming them. Verify imagined confusion rather than
calling it a defect. Never bulk-accept or cut approved decisions.

For each admitted new or reopened choice, offer its remedy, tradeoffs and alternatives.
**STOP.** Wait for its answer before applying that remedy or advancing.

---

## The 0-10 Rating Method

For each DX section:
1. Recall Step 0 evidence: persona, friction trace and competitive benchmark.
2. Rate 0-10, explain the evidenced gap and what 10 means for this product.
3. Read this pass's Hall of Fame section from dx-hall-of-fame.md.
4. Run the Decision gate for each gap. Record routine work within scope; ask and
   wait only for admitted new or reopened choices.
5. Apply approved changes, then re-rate the amended plan. Keep unresolved risks
   visible. A score is not measured success; never add scope just to reach 10.

**Mode-specific behavior:**
- **DX EXPANSION:** Also propose what would make this dimension best-in-class
  for the persona. Each expansion requires its own opt-in AskUserQuestion.
- **DX POLISH:** Examine every touchpoint within the accepted scope and contracts.
  Trace each issue to evidence. Do not redesign established APIs to improve a score.
- **DX TRIAGE:** Flag adoption blockers (below 5); skip nice-to-haves (5-7).

{{SECTION:review-sections}}

## 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}}