super-ux 0.5.0 → 0.7.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +37 -0
- package/README.md +41 -25
- package/cursor/rules/super-ux.mdc +9 -6
- package/cursor/rules/ux-foundation.mdc +47 -0
- package/cursor/rules/ux-scenarios.mdc +6 -1
- package/package.json +1 -1
- package/templates/foundation.md +39 -0
package/CHANGELOG.md
CHANGED
|
@@ -4,6 +4,43 @@ All notable changes to this project are documented in this file. The format
|
|
|
4
4
|
follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); versions
|
|
5
5
|
follow [SemVer](https://semver.org/spec/v2.0.0.html).
|
|
6
6
|
|
|
7
|
+
## [0.7.0] - 2026-07-20
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
|
|
11
|
+
- **Best-practices catalog** (`skills/references/best-practices.md`) — a
|
|
12
|
+
living, tag-indexed catalog (48 entries seeded from "48 Laws of
|
|
13
|
+
Subscription App Success", Botsi 2025): each practice has an ID (BP-NNN),
|
|
14
|
+
own-words summary, mechanism, applicability, and tags (stage / mechanism /
|
|
15
|
+
domain / effect) so agents can select what fits the product. Growable per
|
|
16
|
+
in-file rules.
|
|
17
|
+
- Integration: `ux-scenarios` consults the catalog when drafting (practices
|
|
18
|
+
applied only when they serve a traced job); `ux-foundation` uses it for
|
|
19
|
+
journey opportunities; `ux-audit` gains an optional practices pass
|
|
20
|
+
(suggestion findings `[BP-NNN]`, never blockers); `/ux` menu gains a
|
|
21
|
+
"Best-practices review" action.
|
|
22
|
+
|
|
23
|
+
## [0.6.0] - 2026-07-20
|
|
24
|
+
|
|
25
|
+
### Added
|
|
26
|
+
|
|
27
|
+
- **ux-foundation skill** — the WHY layer: personas, Jobs to Be Done (with
|
|
28
|
+
forces and success metrics), customer journey maps (stage / action /
|
|
29
|
+
touchpoint / emotion / pain / opportunity), user stories (INVEST,
|
|
30
|
+
Given/When/Then acceptance criteria). New file contract
|
|
31
|
+
`docs/ux/foundation.md`, template, `/ux-foundation` command, Cursor rule.
|
|
32
|
+
- **ux-contract v2** — scenarios gain a `Traces:` field (story/job/journey
|
|
33
|
+
stage) and traceability rules: every must/should story covered, every
|
|
34
|
+
scenario serves a story or job; orphans are findings.
|
|
35
|
+
- **Full-context audits** — `ux-audit` loads traced acceptance criteria as
|
|
36
|
+
checks and judges whether the implementation serves the job, not just
|
|
37
|
+
renders elements; new `coverage` scope audits the chain itself; fix plans
|
|
38
|
+
prioritized by Frequency × Severity × Solvability.
|
|
39
|
+
- **`/ux` action menu** — single entry point now reports status across all
|
|
40
|
+
three layers and offers the applicable actions (init/update foundation,
|
|
41
|
+
build scenarios, validate chain, audit, coverage audit, plan fixes) with
|
|
42
|
+
one recommended default.
|
|
43
|
+
|
|
7
44
|
## [0.5.0] - 2026-07-19
|
|
8
45
|
|
|
9
46
|
### Changed
|
package/README.md
CHANGED
|
@@ -1,5 +1,9 @@
|
|
|
1
1
|
# super-ux
|
|
2
2
|
|
|
3
|
+
[](https://www.npmjs.com/package/super-ux)
|
|
4
|
+
[](https://github.com/ssheleg/super-ux/actions/workflows/validate.yml)
|
|
5
|
+
[](LICENSE)
|
|
6
|
+
|
|
3
7
|
Scenario-driven UI development for AI agents (Claude Code + Cursor).
|
|
4
8
|
|
|
5
9
|
AI agents generate poor interfaces because they build UI without a model of
|
|
@@ -13,25 +17,29 @@ the codebase.
|
|
|
13
17
|
|
|
14
18
|
```mermaid
|
|
15
19
|
flowchart LR
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
20
|
+
W[Personas + JTBD\n+ journeys + stories] --> B[Derive scenarios\nwith Traces]
|
|
21
|
+
A[Feature idea] --> V{Which job? Which stage?\nValidate vs base}
|
|
22
|
+
W --> V
|
|
23
|
+
V -->|approved| D[Design & build UI]
|
|
19
24
|
D --> E[Update scenarios\nin the same change]
|
|
20
|
-
E --> F[/ux-audit:
|
|
21
|
-
|
|
22
|
-
|
|
25
|
+
E --> F[/ux-audit: code vs scenarios\nwith story acceptance criteria/]
|
|
26
|
+
B --> F
|
|
27
|
+
F --> G[Report + findings]
|
|
28
|
+
G --> H[Prioritized fix plan\nFreq × Severity × Solvability] --> D
|
|
23
29
|
```
|
|
24
30
|
|
|
25
31
|
## What's inside
|
|
26
32
|
|
|
27
33
|
| Piece | Purpose |
|
|
28
34
|
|---|---|
|
|
29
|
-
| skill `ux-
|
|
30
|
-
| skill `ux-
|
|
31
|
-
|
|
|
32
|
-
| `/ux
|
|
33
|
-
| `
|
|
34
|
-
| `
|
|
35
|
+
| skill `ux-foundation` | The WHY layer (`docs/ux/foundation.md`): personas, Jobs to Be Done with forces, customer journey maps, user stories with Given/When/Then acceptance criteria |
|
|
36
|
+
| skill `ux-scenarios` | Maintain `docs/ux/scenarios.md`: scenarios derived from stories/journeys with `Traces:`, updated on every change, validated for conflicts, coverage, and traceability |
|
|
37
|
+
| skill `ux-audit` | Batched audit loop with full context: code vs every scenario + its story's acceptance criteria; verdicts PASS/PARTIAL/FAIL/BLOCKED with `file:line` evidence; `coverage` scope audits the chain itself |
|
|
38
|
+
| `/ux` | **The one command**: sets up whatever is missing, then status across all layers + a menu of applicable actions with one recommended default. Idempotent |
|
|
39
|
+
| `/ux-foundation` `/ux-init` `/ux-update` `/ux-audit` `/ux-rule` | Direct controls; `/ux-rule` installs the hard rule into the project's CLAUDE.md |
|
|
40
|
+
| `cursor/rules/*.mdc` | The same methodology for Cursor (always-on hard rule + three agent-requested rules) |
|
|
41
|
+
| `templates/` | Skeletons for the foundation, scenario base, audit report, and the CLAUDE.md rule snippet |
|
|
42
|
+
| [best-practices.md](plugins/super-ux/skills/references/best-practices.md) | Living, tag-indexed catalog of proven UX/growth practices (seeded with 48 subscription-app laws); agents filter by stage/domain tags and apply what serves a traced job |
|
|
35
43
|
|
|
36
44
|
The format all of them share is locked in
|
|
37
45
|
[scenario-format.md](plugins/super-ux/skills/references/scenario-format.md):
|
|
@@ -99,16 +107,20 @@ rules after a new release.
|
|
|
99
107
|
|
|
100
108
|
## Typical cycle
|
|
101
109
|
|
|
102
|
-
1. `/ux` — first run sets everything up
|
|
103
|
-
interview
|
|
104
|
-
|
|
110
|
+
1. `/ux` — first run sets everything up: foundation first (greenfield:
|
|
111
|
+
interview about personas, jobs, journeys; existing code:
|
|
112
|
+
reverse-engineer them), then scenarios derived from the stories with
|
|
113
|
+
full traceability.
|
|
105
114
|
2. Work normally; every user-facing change updates the base in the same
|
|
106
115
|
change (the always-on rule catches it; `/ux-update` for manual control).
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
116
|
+
New feature ideas are validated against the chain first: which job,
|
|
117
|
+
which journey stage, which story.
|
|
118
|
+
3. `/ux` any time — status across layers + action menu; `/ux-audit` —
|
|
119
|
+
batched verification of code vs scenarios (with acceptance criteria);
|
|
120
|
+
`/ux-audit coverage` — chain gaps. Reports land in
|
|
121
|
+
`docs/ux/audits/YYYY-MM-DD.md`.
|
|
122
|
+
4. Findings become a prioritized fix plan (Frequency × Severity ×
|
|
123
|
+
Solvability) via your planning workflow; build; repeat.
|
|
112
124
|
|
|
113
125
|
## Development
|
|
114
126
|
|
|
@@ -120,11 +132,15 @@ is semver; bump `marketplace.json` + `plugin.json` + `CHANGELOG.md` together
|
|
|
120
132
|
## По-русски (коротко)
|
|
121
133
|
|
|
122
134
|
Проблема: агенты генерируют плохие интерфейсы, потому что строят UI без
|
|
123
|
-
модели поведения пользователя. super-ux
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
135
|
+
модели поведения пользователя. super-ux строит цепочку: **персоны → JTBD →
|
|
136
|
+
карта пути → user stories → UX-сценарии → аудиты → планы фиксов**.
|
|
137
|
+
Foundation (`docs/ux/foundation.md`) отвечает на «зачем», сценарии
|
|
138
|
+
(`docs/ux/scenarios.md`) — источник правды поведения, трассируются к
|
|
139
|
+
stories. Всё пишется и валидируется **до** интерфейса, обновляется тем же
|
|
140
|
+
изменением, что и поведение. Аудиты (`/ux-audit`) проверяют код против
|
|
141
|
+
сценариев вместе с acceptance criteria, вердикты PASS/PARTIAL/FAIL/BLOCKED
|
|
142
|
+
с доказательствами `file:line`; `/ux-audit coverage` ищет дыры в самой
|
|
143
|
+
цепочке. Установка: в
|
|
128
144
|
Claude Code — `/plugin marketplace add ssheleg/super-ux`, в Cursor —
|
|
129
145
|
`npx super-ux --cursor <проект>`. Дальше одна команда — `/ux`: сама ставит
|
|
130
146
|
правило и базу, а при повторных запусках показывает статус и следующий шаг.
|
|
@@ -5,13 +5,16 @@ alwaysApply: true
|
|
|
5
5
|
|
|
6
6
|
# UX scenarios — hard rule (super-ux)
|
|
7
7
|
|
|
8
|
-
- `docs/ux/scenarios.md` is the source of truth for all user-facing behavior
|
|
8
|
+
- `docs/ux/scenarios.md` is the source of truth for all user-facing behavior;
|
|
9
|
+
`docs/ux/foundation.md` (personas, JTBD, journeys, user stories) is the WHY
|
|
10
|
+
layer scenarios trace to.
|
|
9
11
|
- Any change that touches user-facing behavior MUST update
|
|
10
12
|
`docs/ux/scenarios.md` in the same change (add/adjust scenarios, statuses,
|
|
11
13
|
coverage). New user-facing behavior with no scenario is a blocker, not a
|
|
12
14
|
warning.
|
|
13
|
-
- Any new feature or project STARTS with
|
|
14
|
-
|
|
15
|
-
only then design and
|
|
16
|
-
|
|
17
|
-
|
|
15
|
+
- Any new feature or project STARTS with the chain: which job does it serve,
|
|
16
|
+
which journey stage, which story — then scenarios, validated against the
|
|
17
|
+
existing base (conflicts, overlaps, gaps), approved — only then design and
|
|
18
|
+
build UI. An idea serving no job is challenged, not silently accepted.
|
|
19
|
+
- Workflows: `ux-foundation` rule (WHY layer), `ux-scenarios` rule
|
|
20
|
+
(scenario base), `ux-audit` rule (evidence-backed audits).
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Maintain docs/ux/foundation.md (personas, Jobs to Be Done, customer journeys, user stories): apply when defining who the users are and why they use the product, during product discovery, or when scenarios need a WHY layer to trace to"
|
|
3
|
+
alwaysApply: false
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# ux-foundation — The WHY Layer
|
|
7
|
+
|
|
8
|
+
`docs/ux/foundation.md` holds the chain scenarios trace to: **Personas
|
|
9
|
+
(P-NN) → Jobs to Be Done (JTBD-NN) → Customer journeys (JRN-NN) → User
|
|
10
|
+
stories (ST-NNN)**. IDs sequential, never reused; dropped entries kept, not
|
|
11
|
+
deleted.
|
|
12
|
+
|
|
13
|
+
## Formats (ux-contract v2)
|
|
14
|
+
|
|
15
|
+
- **Persona `P-NN`:** 1–3 sentences, grounded in data/observation,
|
|
16
|
+
recognizable by a real user.
|
|
17
|
+
- **JTBD `JTBD-NN`:** `When <situation>, I want to <motivation>, so I can
|
|
18
|
+
<outcome>` + personas + type (functional|emotional|social) + forces
|
|
19
|
+
(push/pull/anxiety/habit) + success metric (user outcome, never a
|
|
20
|
+
feature).
|
|
21
|
+
- **Journey `JRN-NN`** (persona × job): stage table — `# | Stage | User
|
|
22
|
+
action | Touchpoint | Emotion (1-5) | Pain | Opportunity`; end-to-end
|
|
23
|
+
(before/during/after product); opportunity priority = Frequency ×
|
|
24
|
+
Severity × Solvability.
|
|
25
|
+
- **Story `ST-NNN`:** `As <persona>, I want <capability>, so that
|
|
26
|
+
<benefit>` + Traces (JTBD, JRN/stage) + Given/When/Then acceptance
|
|
27
|
+
criteria + priority (must|should|could) + status
|
|
28
|
+
(proposed|validated|delivered|dropped). Quality bar: INVEST.
|
|
29
|
+
|
|
30
|
+
## Workflows
|
|
31
|
+
|
|
32
|
+
- **Init (interview):** greenfield — ask one question at a time: who uses
|
|
33
|
+
it; what situation triggers the job; what outcome = success; walk the
|
|
34
|
+
path end-to-end; derive stories from pains and outcomes.
|
|
35
|
+
- **Init (reverse):** existing product — reverse-engineer jobs/personas
|
|
36
|
+
from the UI and scenarios; tag entries observed vs inferred; flag
|
|
37
|
+
features serving no job and jobs with no support.
|
|
38
|
+
- **Update:** locate by ID, update, mark dropped (never delete), then
|
|
39
|
+
cascade: list scenarios tracing to changed IDs and update them in the
|
|
40
|
+
same change.
|
|
41
|
+
- **Validate:** integrity (IDs, references), quality (no features in JTBD,
|
|
42
|
+
INVEST, observable criteria), coverage (persona→job→journey→story chain
|
|
43
|
+
complete; must/should stories have scenarios).
|
|
44
|
+
|
|
45
|
+
Evidence beats opinion: mark unvalidated guesses as assumptions
|
|
46
|
+
(desirability/viability/feasibility/usability) and test risky ones before
|
|
47
|
+
building on them.
|
|
@@ -14,7 +14,12 @@ Title, then header comment, then: **Index** table
|
|
|
14
14
|
(`| ID | Title | Feature | Persona | Status | Last audit |`), **Personas**
|
|
15
15
|
(1–3 sentences each), **Scenarios** grouped by feature.
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
When `docs/ux/foundation.md` exists, scenarios derive from it: draft per
|
|
18
|
+
user story / journey stage, fill `Traces:` (e.g. `ST-001 (JTBD-01,
|
|
19
|
+
JRN-01/#2)`), enforce traceability — every must/should story covered by ≥1
|
|
20
|
+
scenario, every scenario serves ≥1 story or job.
|
|
21
|
+
|
|
22
|
+
Scenario entry fields (exact names): `Persona`, `Feature`, `Traces`, `Entry point`,
|
|
18
23
|
`Preconditions`, `Steps` (numbered, one user action each), `Expected result`
|
|
19
24
|
(observable), `UI elements` (every button/field/link/dialog/toast involved —
|
|
20
25
|
this is what audits check), `States covered` (loading|empty|error|success),
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "super-ux",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.7.0",
|
|
4
4
|
"description": "Scenario-driven UI development for AI agents (Claude Code + Cursor): scenario base, scenario-first hard rule, evidence-backed UX audits. This package is the installer CLI.",
|
|
5
5
|
"bin": {
|
|
6
6
|
"super-ux": "bin/super-ux.js"
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# UX Foundation
|
|
2
|
+
|
|
3
|
+
<!-- Managed with super-ux (ux-contract v2). The WHY layer: personas, jobs
|
|
4
|
+
to be done, customer journeys, user stories. Update when the understanding
|
|
5
|
+
of users changes; scenarios in scenarios.md trace to the IDs defined here. -->
|
|
6
|
+
|
|
7
|
+
## Personas
|
|
8
|
+
|
|
9
|
+
<!-- ### P-01: <name>
|
|
10
|
+
1-3 sentences: who they are, what they know, what they want. Grounded in
|
|
11
|
+
data/observation, recognizable by a real user. -->
|
|
12
|
+
|
|
13
|
+
## Jobs to Be Done
|
|
14
|
+
|
|
15
|
+
<!-- ### JTBD-01: <short job name>
|
|
16
|
+
- **Statement:** When <situation>, I want to <motivation>, so I can <expected outcome>.
|
|
17
|
+
- **Personas:** P-01
|
|
18
|
+
- **Type:** functional | emotional | social
|
|
19
|
+
- **Forces:** push: <...>; pull: <...>; anxiety: <...>; habit: <...>
|
|
20
|
+
- **Success metric:** <observable user outcome, not a feature>
|
|
21
|
+
-->
|
|
22
|
+
|
|
23
|
+
## Customer journeys
|
|
24
|
+
|
|
25
|
+
<!-- ### JRN-01: <persona> — <job> (JTBD-01)
|
|
26
|
+
| # | Stage | User action | Touchpoint | Emotion (1-5) | Pain | Opportunity |
|
|
27
|
+
|---|-------|------------|------------|---------------|------|-------------|
|
|
28
|
+
-->
|
|
29
|
+
|
|
30
|
+
## User stories
|
|
31
|
+
|
|
32
|
+
<!-- ### ST-001: <short name>
|
|
33
|
+
- **Story:** As <persona>, I want <capability>, so that <benefit>.
|
|
34
|
+
- **Traces:** JTBD-01, JRN-01/#2
|
|
35
|
+
- **Acceptance criteria:**
|
|
36
|
+
- Given <precondition>, when <action>, then <observable result>.
|
|
37
|
+
- **Priority:** must | should | could
|
|
38
|
+
- **Status:** proposed
|
|
39
|
+
-->
|