@hegemonart/get-design-done 1.14.7 → 1.15.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/.claude-plugin/marketplace.json +2 -2
- package/.claude-plugin/plugin.json +14 -2
- package/CHANGELOG.md +84 -0
- package/README.md +18 -0
- package/SKILL.md +2 -0
- package/agents/a11y-mapper.md +25 -0
- package/agents/design-auditor.md +92 -8
- package/agents/design-context-builder.md +6 -0
- package/agents/design-executor.md +5 -2
- package/agents/design-pattern-mapper.md +2 -0
- package/agents/design-start-writer.md +221 -0
- package/agents/design-verifier.md +11 -0
- package/agents/motion-mapper.md +45 -0
- package/agents/token-mapper.md +36 -0
- package/agents/visual-hierarchy-mapper.md +29 -0
- package/hooks/first-run-nudge.sh +82 -0
- package/hooks/hooks.json +8 -0
- package/package.json +14 -2
- package/reference/anti-patterns.md +69 -0
- package/reference/audit-scoring.md +34 -3
- package/reference/brand-voice.md +199 -0
- package/reference/checklists.md +30 -3
- package/reference/data/google-fonts.csv +51 -0
- package/reference/data/palettes.csv +41 -0
- package/reference/data/styles.csv +39 -0
- package/reference/design-system-guidance.md +177 -0
- package/reference/design-systems-catalog.md +151 -0
- package/reference/framer-motion-patterns.md +411 -0
- package/reference/gestalt.md +219 -0
- package/reference/iconography.md +231 -0
- package/reference/motion.md +102 -0
- package/reference/palette-catalog.md +82 -0
- package/reference/performance.md +304 -0
- package/reference/registry.json +257 -27
- package/reference/review-format.md +2 -2
- package/reference/start-interview.md +84 -0
- package/reference/style-vocabulary.md +62 -0
- package/reference/surfaces.md +114 -0
- package/reference/typography.md +80 -0
- package/reference/visual-hierarchy-layout.md +306 -0
- package/scripts/lib/detect-ui-root.cjs +187 -0
- package/scripts/lib/start-findings-engine.cjs +405 -0
- package/skills/start/SKILL.md +166 -0
|
@@ -0,0 +1,306 @@
|
|
|
1
|
+
# Visual Hierarchy & Layout
|
|
2
|
+
|
|
3
|
+
<!-- Source: nextlevelbuilder/ui-ux-pro-max-skill (MIT) — data/landing.csv -->
|
|
4
|
+
|
|
5
|
+
Visual hierarchy is the system by which a design communicates importance before the user consciously processes it. Every element in a layout has a perceived rank — determined by size, contrast, position, spacing, and depth — and that rank tells the eye where to go and in what order. A layout without deliberate hierarchy forces the user to negotiate with the design rather than work through it. The principles in this file apply to screens, components, and marketing pages equally.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Z-Order and Depth Cues
|
|
10
|
+
|
|
11
|
+
Shadow is the primary depth signal in modern flat design, because it mimics the physical relationship between surfaces at different altitudes. Shadows do not decorate — they locate. A surface with more shadow sits higher in the visual stack, which means it is more foregrounded and more important.
|
|
12
|
+
|
|
13
|
+
### Three-Layer Shadow System
|
|
14
|
+
|
|
15
|
+
The standard three-layer system maps to real UI altitude needs:
|
|
16
|
+
|
|
17
|
+
| Layer | Shadow Spec | Use |
|
|
18
|
+
|-------|------------|-----|
|
|
19
|
+
| Base (elevation 0) | No shadow | Default page surface, cards at rest |
|
|
20
|
+
| Raised (elevation 1) | `box-shadow: 0 2px 4px rgba(0,0,0,0.08)` | Hover states, interactive cards, sticky headers |
|
|
21
|
+
| Floating (elevation 2) | `box-shadow: 0 8px 16px rgba(0,0,0,0.12)` | Dropdowns, tooltips, popovers |
|
|
22
|
+
| Overlay (elevation 3) | `box-shadow: 0 16px 32px rgba(0,0,0,0.18)` | Modals, drawers, sheets |
|
|
23
|
+
|
|
24
|
+
Using only these four levels prevents visual noise from competed shadows and keeps the depth hierarchy readable. An element should never sit at the same shadow level as an element it is meant to overlay — that collapses the depth relationship.
|
|
25
|
+
|
|
26
|
+
### Blur-as-Scrim for Modal Depth
|
|
27
|
+
|
|
28
|
+
When a modal or drawer is open, applying a backdrop blur (`backdrop-filter: blur(4px)` or a semi-transparent dark overlay) on the content beneath reinforces that the modal is spatially in front of it. This is a figure-ground manipulation (see Gestalt principles). The scrim communicates "this content is currently inaccessible" without hiding it entirely, preserving orientation.
|
|
29
|
+
|
|
30
|
+
### Z-Index Scale
|
|
31
|
+
|
|
32
|
+
A consistent z-index scale prevents the stacking context chaos that makes UI debugging painful. Each level exists for a reason:
|
|
33
|
+
|
|
34
|
+
| Level | Value | Purpose |
|
|
35
|
+
|-------|-------|---------|
|
|
36
|
+
| Base | 0 | Static page content — no stacking context needed |
|
|
37
|
+
| Sticky | 100 | Sticky headers and footers that must stay above scrolled content |
|
|
38
|
+
| Dropdown | 200 | Menus and autocomplete dropdowns that overlay adjacent content |
|
|
39
|
+
| Modal | 300 | Dialogs and drawers that overlay the entire page |
|
|
40
|
+
| Toast | 400 | Notifications that must appear above even open modals |
|
|
41
|
+
|
|
42
|
+
Gaps of 100 between levels exist so intermediate values can be inserted without renumbering. Never assign z-index values outside this scale without a documented reason, because arbitrary z-index values signal that someone solved a specificity problem instead of understanding the stacking architecture.
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Whitespace as Design Element
|
|
47
|
+
|
|
48
|
+
Whitespace is not empty space — it is the space that gives meaning to what surrounds it. Without whitespace, elements cannot be perceived as distinct objects; they collapse into visual noise. With intentional whitespace, proximity becomes a communication tool: elements that are close together are related, and elements that are far apart are not.
|
|
49
|
+
|
|
50
|
+
### Micro-Spacing (Related Elements)
|
|
51
|
+
|
|
52
|
+
Elements that belong together — a label and its input, an icon and its caption, a list item and its supporting text — should be separated by 4–8px. This distance signals "these are one thing" without fusing them visually. Tighter than 4px feels merged; looser than 8px starts to break the association.
|
|
53
|
+
|
|
54
|
+
### Macro-Spacing (Section Separation)
|
|
55
|
+
|
|
56
|
+
Distinct content sections — hero to features, features to testimonials, nav to page content — benefit from 32–64px of separation. This spacing creates visual "chapters" in the layout, giving the eye a moment to land before beginning the next section. Without this spacing, the page feels like one undifferentiated mass regardless of the visual variation within it.
|
|
57
|
+
|
|
58
|
+
### Premium vs. Compact
|
|
59
|
+
|
|
60
|
+
More whitespace signals premium and confidence: the brand is not anxious about showing off everything at once. Less whitespace signals density and efficiency: the product respects the user's time and assumes they have a specific goal. Neither is universally correct — a data dashboard should be compact because users came to see data, while a luxury product landing page should be expansive because users came to be immersed.
|
|
61
|
+
|
|
62
|
+
The rule of thumb: **match whitespace density to the pace at which users should move through the content.** Fast task completion → compact. Consideration and exploration → generous.
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## Asymmetry and Rhythm
|
|
67
|
+
|
|
68
|
+
Symmetric layouts feel stable, balanced, and trustworthy — which makes them appropriate for institutional, financial, and governmental contexts where those qualities matter. They also feel static, because perfect balance has no direction and creates no tension.
|
|
69
|
+
|
|
70
|
+
Asymmetric layouts create tension and visual interest by violating the expectation of balance. When used purposefully, asymmetry directs the eye along a path — a large element on the left creates pressure toward the right, a heavy top creates pressure downward. This directed attention is why most effective marketing layouts use asymmetry: the imbalance leads the user's eye toward the CTA.
|
|
71
|
+
|
|
72
|
+
The key discipline is intentionality. Asymmetry that emerges from neglect — uneven margins, inconsistent column widths — reads as incompetence, not dynamism. Asymmetry that is designed — a deliberate large/small pairing, a grid that breaks at one exact point — reads as craft. Always be able to explain why a layout is asymmetric in terms of what attention it is directing.
|
|
73
|
+
|
|
74
|
+
### Rhythm
|
|
75
|
+
|
|
76
|
+
Rhythm in layout means that repetition creates a predictable visual beat that the eye can lock onto and traverse quickly. A card grid has rhythm. A consistent heading-body-space pattern has rhythm. Rhythm is not uniformity — it is the reliable expectation that similar content will appear in similar visual form. Break rhythm only to signal importance: a featured item in a grid that is twice the size says "this one matters."
|
|
77
|
+
|
|
78
|
+
---
|
|
79
|
+
|
|
80
|
+
## Compositional Grids
|
|
81
|
+
|
|
82
|
+
Grids are not aesthetic choices — they are coordination mechanisms. A grid aligns elements to invisible reference lines, which means users can scan a layout without actively negotiating where each element sits.
|
|
83
|
+
|
|
84
|
+
### Responsive Column Grid
|
|
85
|
+
|
|
86
|
+
| Breakpoint | Columns | Gutter | Margin |
|
|
87
|
+
|------------|---------|--------|--------|
|
|
88
|
+
| Mobile (≤767px) | 4 | 16px | 16px |
|
|
89
|
+
| Tablet (768–1023px) | 8 | 24px | 24px |
|
|
90
|
+
| Desktop (1024–1439px) | 12 | 24px | 32px |
|
|
91
|
+
| Ultra-wide (≥1440px) | 16 | 32px | 48px |
|
|
92
|
+
|
|
93
|
+
12-column desktop is the most common grid because it divides evenly into halves (6), thirds (4), quarters (3), sixths (2), and twelfths (1), giving layouts maximum compositional flexibility. 16-column ultra-wide grids are appropriate for dashboards because they accommodate more simultaneously visible data columns without collapsing to tiny widths.
|
|
94
|
+
|
|
95
|
+
### Baseline Grid
|
|
96
|
+
|
|
97
|
+
A baseline grid aligns text and element heights to a consistent vertical increment — typically 4px or 8px. Every element's height, padding, and margin should be a multiple of this increment. The baseline grid is what makes a layout feel "settled" rather than arbitrarily positioned, because every vertical decision relates to a shared rhythm. In practice, use 8px as the primary increment and 4px for sub-increments only (e.g., within a component's internal padding).
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## Figure-Ground Manipulation
|
|
102
|
+
|
|
103
|
+
Figure-ground perception is the visual system's ability to separate a subject (figure) from its context (ground). Design relies on this to make interactive elements pop out of the background, modal overlays recede the page behind them, and navigation items separate from the content they sit above.
|
|
104
|
+
|
|
105
|
+
The primary tools for establishing figure-ground relationships are:
|
|
106
|
+
|
|
107
|
+
- **Color contrast:** The figure must have at least 3:1 contrast ratio against the ground (WCAG AA for large text; perceived separation requires at least this even for decorative elements).
|
|
108
|
+
- **Size:** Larger elements naturally read as foreground.
|
|
109
|
+
- **Shadow:** Elements with elevation shadows read as physically in front of flat elements.
|
|
110
|
+
- **Blur:** Blurred elements recede perceptually, making sharp elements read as foreground.
|
|
111
|
+
|
|
112
|
+
Never rely on a single cue alone — a foreground element established only by shadow may become invisible in certain display contexts. Combining contrast + shadow + position creates a robust figure-ground relationship.
|
|
113
|
+
|
|
114
|
+
---
|
|
115
|
+
|
|
116
|
+
## Reading-Order Scoring
|
|
117
|
+
|
|
118
|
+
Users do not read UIs — they scan them. Understanding the scan pattern users will apply to a layout allows designers to place information where the eye will naturally encounter it in the intended order.
|
|
119
|
+
|
|
120
|
+
### F-Pattern
|
|
121
|
+
|
|
122
|
+
Users scan the top horizontally, then move down the left side, occasionally scanning horizontally partway across the middle. This pattern dominates text-heavy content: documentation, long-form reads, dense lists. In an F-pattern layout, the most important content belongs at the top and along the left edge. Midline content will receive partial attention; right-column and lower-left content will frequently be missed.
|
|
123
|
+
|
|
124
|
+
**Implication:** In F-pattern contexts, do not place critical information or CTAs in the right column or below the visible horizontal sweeps.
|
|
125
|
+
|
|
126
|
+
### Z-Pattern
|
|
127
|
+
|
|
128
|
+
Users scan the top-left, move horizontally to the top-right, then diagonally across to the bottom-left, then horizontally to the bottom-right. This pattern dominates sparse layouts with clear visual anchors — marketing pages with a headline, an image, and a CTA. The Z traces through the key moments of the layout, which is why placing a CTA at the Z-terminal (bottom-right) is effective for conversion-optimized pages.
|
|
129
|
+
|
|
130
|
+
**Implication:** In Z-pattern contexts, place the brand/logo at top-left, the most compelling claim at top-right, the value summary along the diagonal, and the CTA at bottom-right.
|
|
131
|
+
|
|
132
|
+
### Inverted Triangle
|
|
133
|
+
|
|
134
|
+
The layout starts wide at the top (a full-width headline), narrows through supporting content, and terminates at a focused CTA. This pattern concentrates user attention progressively, mimicking an argument structure: here is the claim (wide), here is the evidence (mid-width), here is the action (narrow and high-contrast).
|
|
135
|
+
|
|
136
|
+
**Implication:** The inverted triangle is one of the strongest conversion patterns because it naturally channels the user's attention from awareness to action without requiring a deliberate scan path.
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Progressive Disclosure Hooks
|
|
141
|
+
|
|
142
|
+
Progressive disclosure is the principle that interface complexity should be revealed in proportion to user readiness and need. Showing all complexity at once overwhelms; hiding complexity aggressively creates friction. The correct level of disclosure depends on what the user is trying to do right now.
|
|
143
|
+
|
|
144
|
+
**Accordion:** Use for dense but not immediately required information. FAQs, advanced settings, and multi-section forms benefit from accordions because users can navigate to the section they need without reading everything. Never hide primary actions behind an accordion — only secondary and contextual content belongs there.
|
|
145
|
+
|
|
146
|
+
**Tooltip:** Use for inline definitions and contextual help that would interrupt reading flow if placed in line. Tooltips are appropriate for technical terms, icon meanings, and field constraints. They should appear on hover (not click) for desktop, and on tap for mobile. Tooltip copy must be brief — if the explanation requires more than two sentences, it belongs in documentation, not a tooltip.
|
|
147
|
+
|
|
148
|
+
**Drill-down:** Use for hierarchical data exploration where showing all levels simultaneously would be overwhelming. File browsers, category navigation, and data dashboards with sub-dimension exploration are appropriate drill-down contexts. Each level should clearly communicate where the user is in the hierarchy and how to return.
|
|
149
|
+
|
|
150
|
+
**The invariant:** Never hide primary actions behind any disclosure pattern. If a user must open an accordion to find the main CTA, the information architecture is broken. Disclosure patterns are for secondary information only.
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Landing-Page Archetypes
|
|
155
|
+
|
|
156
|
+
<!-- Source: nextlevelbuilder/ui-ux-pro-max-skill (MIT) — data/landing.csv -->
|
|
157
|
+
|
|
158
|
+
A landing-page archetype is a proven structural pattern — a specific order of sections, CTA placement rule, and visual approach — calibrated to a specific conversion goal and audience state. Matching the archetype to the product's vertical and the visitor's awareness level dramatically improves conversion without requiring creative originality at every decision.
|
|
159
|
+
|
|
160
|
+
The 24 archetypes below are ordered by section sequence. "CTA placement rule" describes where to place the primary call to action relative to page content.
|
|
161
|
+
|
|
162
|
+
---
|
|
163
|
+
|
|
164
|
+
### 1. Hero-Centric
|
|
165
|
+
**Section order:** Full-viewport hero → brief feature highlights → footer
|
|
166
|
+
**CTA placement rule:** Above the fold, within the hero — the primary action is visible without scrolling
|
|
167
|
+
**Best for:** SaaS product launches, single-purpose apps, brand launches where one conversion goal dominates
|
|
168
|
+
**Key visual pattern:** Large image or video background, single headline, single CTA button — nothing competes with the hero
|
|
169
|
+
|
|
170
|
+
### 2. Conversion-Optimized
|
|
171
|
+
**Section order:** Headline → CTA → minimal social proof → secondary CTA
|
|
172
|
+
**CTA placement rule:** Within 200px of the top of the page; repeated on scroll at a consistent interval
|
|
173
|
+
**Best for:** Lead generation, email capture, high-intent landing pages where the visitor already knows what they want
|
|
174
|
+
**Key visual pattern:** Minimal distraction — no navigation, no secondary offers; everything serves the single conversion action
|
|
175
|
+
|
|
176
|
+
### 3. Feature-Rich Showcase
|
|
177
|
+
**Section order:** Hero → feature grid → social proof → pricing summary → CTA
|
|
178
|
+
**CTA placement rule:** Mid-page, after the feature grid has established value
|
|
179
|
+
**Best for:** Complex products with multiple differentiated capabilities that need explaining before the user will convert
|
|
180
|
+
**Key visual pattern:** Icon cards with short descriptions arranged in a grid; screenshots or product mockups for each feature
|
|
181
|
+
|
|
182
|
+
### 4. Minimal and Direct
|
|
183
|
+
**Section order:** Logo → tagline → single CTA → optional supporting line
|
|
184
|
+
**CTA placement rule:** Above the fold; the page is essentially nothing but the CTA
|
|
185
|
+
**Best for:** Luxury brands, exclusive invitations, invite-only launches, products where restraint signals quality
|
|
186
|
+
**Key visual pattern:** White space is the dominant visual element; typography carries the entire design load; photography is secondary
|
|
187
|
+
|
|
188
|
+
### 5. Social-Proof-Focused
|
|
189
|
+
**Section order:** Hero → testimonial prominences → customer logo wall → case study summary → CTA
|
|
190
|
+
**CTA placement rule:** After the social proof block — conversion happens once trust is established
|
|
191
|
+
**Best for:** Products where credibility is the primary conversion barrier: enterprise software, high-ticket services, health products
|
|
192
|
+
**Key visual pattern:** Real face photography accompanying testimonials; recognizable logos displayed at full opacity; specific measurable results quoted
|
|
193
|
+
|
|
194
|
+
### 6. Interactive Product Demo
|
|
195
|
+
**Section order:** Hero with embedded live demo or interactive preview → feature explanation → CTA
|
|
196
|
+
**CTA placement rule:** Inline with the demo; allow the user to try before committing
|
|
197
|
+
**Best for:** Developer tools, SaaS products, any product where the experience is the best argument for conversion
|
|
198
|
+
**Key visual pattern:** Live code editor, interactive prototype, or animated walkthrough embedded directly in the page — not behind a click
|
|
199
|
+
|
|
200
|
+
### 7. Trust and Authority
|
|
201
|
+
**Section order:** Credentials and certifications → case study highlights → team or methodology → CTA
|
|
202
|
+
**CTA placement rule:** Conservative — placed after all trust signals have been presented; below the fold is acceptable
|
|
203
|
+
**Best for:** B2B enterprise sales, consulting services, legal and compliance products where buying risk is high
|
|
204
|
+
**Key visual pattern:** Logo wall with named clients; specific metrics from case studies; certifications and awards displayed prominently
|
|
205
|
+
|
|
206
|
+
### 8. Storytelling-Driven
|
|
207
|
+
**Section order:** Narrative introduction → problem acknowledgment → solution journey → outcome → CTA
|
|
208
|
+
**CTA placement rule:** End of story — the CTA is the natural conclusion of the narrative arc
|
|
209
|
+
**Best for:** Mission-driven brands, founder-led companies, products where the origin story creates emotional investment
|
|
210
|
+
**Key visual pattern:** Full-bleed photography that advances the narrative; minimal UI chrome; scroll-triggered reveals that pace the story
|
|
211
|
+
|
|
212
|
+
### 9. Comparison/Competitive
|
|
213
|
+
**Section order:** Positioning headline → feature comparison matrix → pricing → CTA
|
|
214
|
+
**CTA placement rule:** After the comparison matrix — once the product has won the comparison
|
|
215
|
+
**Best for:** Competitive category entries, products explicitly positioning against a named incumbent, switching-cost contexts
|
|
216
|
+
**Key visual pattern:** Side-by-side comparison table with clear visual wins; checkmarks vs. X marks; pricing presented as a conclusion, not an opener
|
|
217
|
+
|
|
218
|
+
### 10. Problem-Solution
|
|
219
|
+
**Section order:** Pain point articulation → solution introduction → specific benefits → social proof → CTA
|
|
220
|
+
**CTA placement rule:** Mid-page, after the solution and benefits have been presented
|
|
221
|
+
**Best for:** Products solving a well-understood pain that users actively feel but haven't found a solution for
|
|
222
|
+
**Key visual pattern:** Before/after contrast; language that mirrors how users describe the problem to themselves; solution reveal that feels like relief
|
|
223
|
+
|
|
224
|
+
### 11. Community-Led
|
|
225
|
+
**Section order:** Community value proposition → user-generated content grid → join CTA → community stats
|
|
226
|
+
**CTA placement rule:** After seeing the community in action — conversion is to join, not to buy
|
|
227
|
+
**Best for:** Social apps, creator platforms, forums, any product whose value scales with network size
|
|
228
|
+
**Key visual pattern:** Real user content grid; community size metrics; faces and usernames to signal that real people are already here
|
|
229
|
+
|
|
230
|
+
### 12. Free-Tool
|
|
231
|
+
**Section order:** Tool embedded directly at top → output or result preview → upgrade value proposition → CTA
|
|
232
|
+
**CTA placement rule:** After tool use — show the upgrade CTA once the user has experienced the value
|
|
233
|
+
**Best for:** Freemium SaaS products where the tool itself is the best acquisition mechanism
|
|
234
|
+
**Key visual pattern:** Functional tool widget inline in the page; results visible without signup; upgrade gate triggered by usage limit or advanced feature
|
|
235
|
+
|
|
236
|
+
### 13. Event/Launch
|
|
237
|
+
**Section order:** Event name and date → countdown timer → value proposition → registration form
|
|
238
|
+
**CTA placement rule:** Above the fold alongside the countdown — urgency and action together
|
|
239
|
+
**Best for:** Product launches, webinars, conferences, limited-availability events
|
|
240
|
+
**Key visual pattern:** Countdown timer as the hero element; date and time prominently displayed; registration form short enough to complete immediately
|
|
241
|
+
|
|
242
|
+
### 14. Portfolio/Agency
|
|
243
|
+
**Section order:** Brand positioning → selected work grid → process or approach → contact CTA
|
|
244
|
+
**CTA placement rule:** Bottom of page — the portfolio is the argument; the CTA is the conclusion
|
|
245
|
+
**Best for:** Creative agencies, freelancers, design studios, any service business where the work speaks for itself
|
|
246
|
+
**Key visual pattern:** Full-bleed project images; minimal copy; case study depth available on click; contact form or email rather than a purchase CTA
|
|
247
|
+
|
|
248
|
+
### 15. E-commerce Category
|
|
249
|
+
**Section order:** Category headline → filter controls → product grid → individual product CTAs
|
|
250
|
+
**CTA placement rule:** Per-product — each product card has its own CTA
|
|
251
|
+
**Best for:** Retail product categories, marketplace verticals, any browsing-first commerce context
|
|
252
|
+
**Key visual pattern:** Masonry or uniform grid layout; filter/sort controls accessible without page navigation; product image as the primary communication vehicle
|
|
253
|
+
|
|
254
|
+
### 16. Mobile-App Download
|
|
255
|
+
**Section order:** App value proposition → device mockup → key screens → app store badges → social proof
|
|
256
|
+
**CTA placement rule:** Above the fold with app store badge buttons; repeated at bottom
|
|
257
|
+
**Best for:** Consumer mobile apps, games, utilities targeting smartphone-first audiences
|
|
258
|
+
**Key visual pattern:** Phone frame showing the app in use; platform-specific badges (App Store / Google Play) as primary CTAs; optional rating and download count as social proof
|
|
259
|
+
|
|
260
|
+
### 17. Video-First
|
|
261
|
+
**Section order:** Autoplay background video → overlaid headline and CTA → supporting content below
|
|
262
|
+
**CTA placement rule:** Overlaid on the video — visible immediately on page load
|
|
263
|
+
**Best for:** Experiential brands, travel companies, premium consumer products where atmosphere is the argument
|
|
264
|
+
**Key visual pattern:** Full-screen video autoplay (muted); minimal text overlay; the video carries the emotional and brand argument
|
|
265
|
+
|
|
266
|
+
### 18. Pricing-Forward
|
|
267
|
+
**Section order:** Brief positioning → pricing table with tier comparison → per-tier CTA → FAQ
|
|
268
|
+
**CTA placement rule:** Per-tier — each pricing column has its own conversion action
|
|
269
|
+
**Best for:** Products with transparent, self-serve pricing; SaaS with clear tier differentiation; subscription businesses
|
|
270
|
+
**Key visual pattern:** Three-tier layout with middle tier highlighted as recommended; feature comparison below price; annual/monthly toggle
|
|
271
|
+
|
|
272
|
+
### 19. Newsletter/Content
|
|
273
|
+
**Section order:** Value proposition → email capture form → sample content or recent issues → social proof subscriber count
|
|
274
|
+
**CTA placement rule:** Above the fold — the form is the entire purpose of the page
|
|
275
|
+
**Best for:** Media companies, content creators, thought leaders, any subscription email product
|
|
276
|
+
**Key visual pattern:** Minimal design that does not compete with the form; preview of content quality as the primary trust signal
|
|
277
|
+
|
|
278
|
+
### 20. Data/Analytics Showcase
|
|
279
|
+
**Section order:** Positioning headline → live or animated dashboard preview → capability explanation → CTA
|
|
280
|
+
**CTA placement rule:** After the demo — once the data quality has been demonstrated
|
|
281
|
+
**Best for:** Analytics platforms, BI tools, data products where the output is the proof
|
|
282
|
+
**Key visual pattern:** Interactive chart or live dashboard preview embedded in the page; real-seeming data rather than placeholders; metric definitions visible to signal depth
|
|
283
|
+
|
|
284
|
+
### 21. Long-Form Sales Page
|
|
285
|
+
**Section order:** Headline → problem → agitation → solution → proof → benefits → objection handling → CTA → guarantee → repeated CTA
|
|
286
|
+
**CTA placement rule:** Repeated multiple times throughout — after each major argument and at the end
|
|
287
|
+
**Best for:** High-ticket items, coaching programs, courses, any product requiring significant commitment
|
|
288
|
+
**Key visual pattern:** Text-heavy with strategic visual breaks; testimonials woven throughout rather than grouped; guarantee section near the final CTA to reduce last-minute drop-off
|
|
289
|
+
|
|
290
|
+
### 22. Waitlist/Pre-launch
|
|
291
|
+
**Section order:** Teaser headline → product promise → email capture form → optional: social sharing incentive
|
|
292
|
+
**CTA placement rule:** Above the fold — the form is the entire conversion goal
|
|
293
|
+
**Best for:** Pre-launch products, invite-only launches, limited-release products
|
|
294
|
+
**Key visual pattern:** Intentional information scarcity; anticipation over explanation; social proof through waitlist size if available
|
|
295
|
+
|
|
296
|
+
### 23. Marketplace
|
|
297
|
+
**Section order:** Search bar → category navigation → featured listings → browse grid
|
|
298
|
+
**CTA placement rule:** Search-first — the search bar is the primary CTA; per-listing CTAs secondary
|
|
299
|
+
**Best for:** Two-sided platforms, classified marketplaces, any product where supply browsing is the primary user behavior
|
|
300
|
+
**Key visual pattern:** Search prominence above everything else; category browsing as primary navigation; featured/promoted listings visually distinct but not intrusive
|
|
301
|
+
|
|
302
|
+
### 24. Documentation Hub
|
|
303
|
+
**Section order:** Search bar → quick-start links → navigation tree → content area
|
|
304
|
+
**CTA placement rule:** No primary marketing CTA — navigation is the only action
|
|
305
|
+
**Best for:** Developer documentation, product help centers, API references, any knowledge base
|
|
306
|
+
**Key visual pattern:** Navigation-heavy layout; dense information with strong typographic hierarchy; search is the dominant entry point; no marketing chrome competing with the content
|
|
@@ -0,0 +1,187 @@
|
|
|
1
|
+
#!/usr/bin/env node
|
|
2
|
+
'use strict';
|
|
3
|
+
|
|
4
|
+
// Component-directory detection helper for /gdd:start (Phase 14.7-02).
|
|
5
|
+
// Deterministic, read-only, pure Node — no LLM, no subprocess, no interactive prompts.
|
|
6
|
+
//
|
|
7
|
+
// Contract:
|
|
8
|
+
// detectUiRoot(cwd) -> { kind, path, confidence, reason } | { kind: "backend-only", path: null, confidence, reason } | null
|
|
9
|
+
//
|
|
10
|
+
// `path` is always relative to cwd and uses forward slashes.
|
|
11
|
+
|
|
12
|
+
const fs = require('fs');
|
|
13
|
+
const path = require('path');
|
|
14
|
+
|
|
15
|
+
const UI_EXT = new Set(['.tsx', '.jsx', '.ts', '.js', '.svelte', '.vue']);
|
|
16
|
+
const BACKEND_DEPS = ['express', 'fastify', 'koa', '@nestjs/core', 'hapi', 'restify'];
|
|
17
|
+
const UI_DEPS = ['react', 'preact', 'vue', 'svelte', 'solid-js', '@remix-run/react', 'next'];
|
|
18
|
+
|
|
19
|
+
function readJsonSafe(p) {
|
|
20
|
+
try {
|
|
21
|
+
return JSON.parse(fs.readFileSync(p, 'utf8'));
|
|
22
|
+
} catch {
|
|
23
|
+
return null;
|
|
24
|
+
}
|
|
25
|
+
}
|
|
26
|
+
|
|
27
|
+
function hasUiFiles(absDir) {
|
|
28
|
+
let stack;
|
|
29
|
+
try {
|
|
30
|
+
stack = [absDir];
|
|
31
|
+
} catch {
|
|
32
|
+
return false;
|
|
33
|
+
}
|
|
34
|
+
// Bounded BFS — stop at 3 levels deep or after 200 entries to keep fast.
|
|
35
|
+
let checked = 0;
|
|
36
|
+
let depth = 0;
|
|
37
|
+
const maxEntries = 200;
|
|
38
|
+
const maxDepth = 3;
|
|
39
|
+
while (stack.length && checked < maxEntries && depth < maxDepth) {
|
|
40
|
+
const next = [];
|
|
41
|
+
for (const dir of stack) {
|
|
42
|
+
let entries;
|
|
43
|
+
try {
|
|
44
|
+
entries = fs.readdirSync(dir, { withFileTypes: true });
|
|
45
|
+
} catch {
|
|
46
|
+
continue;
|
|
47
|
+
}
|
|
48
|
+
for (const e of entries) {
|
|
49
|
+
if (e.name.startsWith('.') || e.name === 'node_modules') continue;
|
|
50
|
+
const full = path.join(dir, e.name);
|
|
51
|
+
if (e.isFile()) {
|
|
52
|
+
if (UI_EXT.has(path.extname(e.name))) return true;
|
|
53
|
+
checked += 1;
|
|
54
|
+
if (checked >= maxEntries) return false;
|
|
55
|
+
} else if (e.isDirectory()) {
|
|
56
|
+
next.push(full);
|
|
57
|
+
}
|
|
58
|
+
}
|
|
59
|
+
}
|
|
60
|
+
stack = next;
|
|
61
|
+
depth += 1;
|
|
62
|
+
}
|
|
63
|
+
return false;
|
|
64
|
+
}
|
|
65
|
+
|
|
66
|
+
function firstExistingUiDir(cwd, relPath) {
|
|
67
|
+
const abs = path.join(cwd, relPath);
|
|
68
|
+
if (!fs.existsSync(abs) || !fs.statSync(abs).isDirectory()) return null;
|
|
69
|
+
if (!hasUiFiles(abs)) return null;
|
|
70
|
+
return relPath.split(path.sep).join('/');
|
|
71
|
+
}
|
|
72
|
+
|
|
73
|
+
function firstMonorepoAppsComponents(cwd) {
|
|
74
|
+
const appsDir = path.join(cwd, 'apps');
|
|
75
|
+
if (!fs.existsSync(appsDir) || !fs.statSync(appsDir).isDirectory()) return null;
|
|
76
|
+
let children;
|
|
77
|
+
try {
|
|
78
|
+
children = fs.readdirSync(appsDir, { withFileTypes: true });
|
|
79
|
+
} catch {
|
|
80
|
+
return null;
|
|
81
|
+
}
|
|
82
|
+
for (const c of children) {
|
|
83
|
+
if (!c.isDirectory()) continue;
|
|
84
|
+
const rel = `apps/${c.name}/components`;
|
|
85
|
+
const abs = path.join(cwd, rel);
|
|
86
|
+
if (fs.existsSync(abs) && fs.statSync(abs).isDirectory() && hasUiFiles(abs)) {
|
|
87
|
+
return rel;
|
|
88
|
+
}
|
|
89
|
+
}
|
|
90
|
+
return null;
|
|
91
|
+
}
|
|
92
|
+
|
|
93
|
+
function detectFramework(pkg) {
|
|
94
|
+
if (!pkg) return 'unknown';
|
|
95
|
+
const deps = { ...(pkg.dependencies || {}), ...(pkg.devDependencies || {}) };
|
|
96
|
+
if (deps.next) return 'next';
|
|
97
|
+
if (deps['@remix-run/react'] || deps['@remix-run/node']) return 'remix';
|
|
98
|
+
if (deps['react-scripts']) return 'cra';
|
|
99
|
+
if (deps.vite) return 'vite';
|
|
100
|
+
if (deps.svelte || deps['@sveltejs/kit']) return 'svelte';
|
|
101
|
+
if (deps.vue) return 'vue';
|
|
102
|
+
if (deps.solid) return 'solid';
|
|
103
|
+
if (deps.astro) return 'astro';
|
|
104
|
+
if (deps.react || deps.preact) return 'react';
|
|
105
|
+
return 'unknown';
|
|
106
|
+
}
|
|
107
|
+
|
|
108
|
+
function hasAnyDep(pkg, names) {
|
|
109
|
+
if (!pkg) return false;
|
|
110
|
+
const deps = { ...(pkg.dependencies || {}), ...(pkg.devDependencies || {}) };
|
|
111
|
+
return names.some((n) => Object.prototype.hasOwnProperty.call(deps, n));
|
|
112
|
+
}
|
|
113
|
+
|
|
114
|
+
function detectUiRoot(cwd) {
|
|
115
|
+
const pkgPath = path.join(cwd, 'package.json');
|
|
116
|
+
const pkg = readJsonSafe(pkgPath);
|
|
117
|
+
|
|
118
|
+
// Priority-ordered checks. First match wins.
|
|
119
|
+
const checks = [
|
|
120
|
+
{ rel: 'packages/ui/src', kind: 'monorepo-ui-pkg', confidence: 0.95 },
|
|
121
|
+
{ rel: null, custom: firstMonorepoAppsComponents, kind: 'monorepo-apps', confidence: 0.9 },
|
|
122
|
+
{ rel: 'app/components', kind: 'next-app-router', confidence: 0.9 },
|
|
123
|
+
{ rel: 'src/app/components', kind: 'next-app-router-src', confidence: 0.85 },
|
|
124
|
+
{ rel: 'src/components', kind: 'src-components', confidence: 0.85 },
|
|
125
|
+
{ rel: 'components', kind: 'root-components', confidence: 0.8 },
|
|
126
|
+
];
|
|
127
|
+
|
|
128
|
+
for (const c of checks) {
|
|
129
|
+
const found = c.custom ? c.custom(cwd) : firstExistingUiDir(cwd, c.rel);
|
|
130
|
+
if (found) {
|
|
131
|
+
const framework = detectFramework(pkg);
|
|
132
|
+
return {
|
|
133
|
+
kind: c.kind,
|
|
134
|
+
path: found,
|
|
135
|
+
confidence: c.confidence,
|
|
136
|
+
reason: `Found UI files at ${found} (framework=${framework}, kind=${c.kind})`,
|
|
137
|
+
framework,
|
|
138
|
+
};
|
|
139
|
+
}
|
|
140
|
+
}
|
|
141
|
+
|
|
142
|
+
// Routes-based detection — Svelte/Remix sometimes colocate inside routes
|
|
143
|
+
const routesAbs = path.join(cwd, 'src/routes');
|
|
144
|
+
if (fs.existsSync(routesAbs) && fs.statSync(routesAbs).isDirectory() && hasUiFiles(routesAbs)) {
|
|
145
|
+
return {
|
|
146
|
+
kind: 'routes-based',
|
|
147
|
+
path: 'src/routes',
|
|
148
|
+
confidence: 0.7,
|
|
149
|
+
reason: 'Found UI files inline at src/routes — framework colocation pattern',
|
|
150
|
+
framework: detectFramework(pkg),
|
|
151
|
+
};
|
|
152
|
+
}
|
|
153
|
+
|
|
154
|
+
// Backend-only path — package.json present with only backend deps and no UI deps
|
|
155
|
+
if (pkg) {
|
|
156
|
+
const isBackend = hasAnyDep(pkg, BACKEND_DEPS) && !hasAnyDep(pkg, UI_DEPS);
|
|
157
|
+
if (isBackend) {
|
|
158
|
+
return {
|
|
159
|
+
kind: 'backend-only',
|
|
160
|
+
path: null,
|
|
161
|
+
confidence: 0.9,
|
|
162
|
+
reason: `Backend-only repo detected (deps: ${BACKEND_DEPS.filter((d) =>
|
|
163
|
+
Object.prototype.hasOwnProperty.call(
|
|
164
|
+
{ ...(pkg.dependencies || {}), ...(pkg.devDependencies || {}) },
|
|
165
|
+
d
|
|
166
|
+
)
|
|
167
|
+
).join(', ')}) — frontend-only diagnostic applies`,
|
|
168
|
+
framework: 'backend',
|
|
169
|
+
};
|
|
170
|
+
}
|
|
171
|
+
}
|
|
172
|
+
|
|
173
|
+
return null;
|
|
174
|
+
}
|
|
175
|
+
|
|
176
|
+
module.exports = detectUiRoot;
|
|
177
|
+
module.exports.detectUiRoot = detectUiRoot;
|
|
178
|
+
|
|
179
|
+
if (require.main === module) {
|
|
180
|
+
const cwd = process.argv[2] || process.cwd();
|
|
181
|
+
const result = detectUiRoot(path.resolve(cwd));
|
|
182
|
+
if (result == null) {
|
|
183
|
+
process.stdout.write(JSON.stringify({ kind: null, path: null, confidence: 0, reason: 'No UI directory detected and no backend signal either.' }) + '\n');
|
|
184
|
+
} else {
|
|
185
|
+
process.stdout.write(JSON.stringify(result) + '\n');
|
|
186
|
+
}
|
|
187
|
+
}
|