Files
e587004ee4 Refactor: cleaner top-level directory structure (#138)
* refactor(content): merge content/site/ into site/content/

Phase 1 step 1 of the directory restructure. The dual content tree was
called out in CLAUDE.md as cleanup; both trees were already in sync
except for anti-patterns-catalog.js, which moves to site/data/.

- Delete content/site/skills/ and content/site/tutorials/ (duplicates of
  site/content/, which is what Astro's content collection actually reads).
- Move content/site/anti-patterns-catalog.js -> site/data/.
- Update scripts/lib/sub-pages-data.js and scripts/build.js to read from
  site/content/ and site/data/.
- Drop content/site/ from validateProse target list (site/content was
  already there).
- Rewrite the "Two content trees" section in CLAUDE.md as a single-tree
  pointer; update stale dev-server text mentioning the deleted
  server/index.js.

Tests: 186/186 pass. Skills build: clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(skill): rename source/skills/impeccable/ -> skill/

Phase 1 step 2 of the directory restructure. The path was redundantly
nested ("source/" wrapper plus "skills/impeccable/" — singular content
hidden behind the plural). Collapses to flat skill/SKILL.md +
skill/reference/ + skill/scripts/.

- Move source/skills/impeccable/ -> skill/.
- Rewrite scripts/lib/utils.js readSourceFiles(): drop the multi-skill
  iteration (CLAUDE.md commits to a single user-invocable skill); read
  skill/SKILL.md directly.
- Update scripts/build.js, scripts/generate-og-image.js, and the
  sub-pages data layer to point at skill/.
- Update tests/lib/utils.test.js: drop the "multi-skill" and "dir-name
  fallback" cases, update single-skill paths to skill/.
- Update tests/build.test.js similarly: drop "multiple skills"
  integration test, update paths.
- Update non-glob path joins in tests/framework-fixtures.test.mjs,
  tests/live-e2e/session.mjs, tests/live-e2e/agents/llm-agent.mjs,
  tools/live-loop.mjs.
- Update prose/text references in CLAUDE.md, AGENTS.md, DEVELOP.md,
  README.md, scripts/lib/sub-pages-data.js, bin/commands/skills.mjs,
  site/data/anti-patterns-catalog.js, site/pages/docs/[...slug].astro,
  docs/adr-live-variant-mode.md, docs/plans/.

Eval framework note: the separate impeccable-evals repo reads
../impeccable/source/skills/impeccable/ and needs a coordinated
rename to ../impeccable/skill/.

Tests: 186/186 pass. Skills build: clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor: rename docs/ -> notes/

Phase 1 step 3 of the directory restructure. The internal docs/ dir
(ADRs and plans) clashed with the site's /docs route. Renaming it
"notes/" makes the difference unambiguous: notes/ is project-internal
process, /docs is the user-facing route under site/pages/docs/.

No code references the dir; the rename is a clean git mv.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(site): move public/ under site/public/

Phase 2 step 4 of the directory restructure. Public assets and the
Astro publicDir now live alongside the rest of the site, so site/
is fully self-contained for static content.

- git mv public site/public.
- astro.config.mjs: add publicDir: './site/public'. Astro defaults to
  ./public at the project root, so the override is required.
- scripts/build.js: write generated _data, _headers, _redirects,
  _routes.json, and js/detect-antipatterns-browser.js into
  site/public/. Also delete the dead _REMOVED() Bun static-site
  builder (replaced by Astro at #130; the placeholder no longer earns
  its keep).
- scripts/build.js validateProse: replace the stale public/index.html
  reference (deleted at the Astro migration) with site/pages/index.astro
  in the count-validation file list, restoring homepage drift detection.
- scripts/generate-og-image.js: write OG image into site/public/.
- scripts/screenshot-antipatterns.js: read examples from + write
  screenshots to site/public/antipattern-{examples,images}/.
- scripts/lib/sub-pages-data.js: load command demos from
  site/public/js/demos/commands.
- .gitignore: rename the public/* generator-output entries to
  site/public/*.
- CLAUDE.md: refresh CSS/data-file paths (still pointing at the old
  pre-Astro public/css/ + public/js/ tree), point the changelog and
  command-add checklists at site/pages/index.astro and
  site/scripts/data.js + site/scripts/components/framework-viz.js.

Cloudflare Pages note: functions/ stays at the repo root because
CF Pages auto-discovers it there with no configuration knob to
relocate. Moving it under site/ would either break deployment or
require a build-time copy step that adds more complexity than the
cleanup is worth.

Tests: 186/186 pass. Skills + site build clean. _headers,
_redirects, _routes.json, _data/ all land in build/ correctly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* refactor(cli): consolidate bin/ + src/ + lib/ under cli/

Phase 2 step 5 of the directory restructure. The CLI surface was split
across three top-level dirs whose names were easy to mistake for each
other (especially src/ vs source/ pre-step-2). Consolidates under cli/.

- git mv bin -> cli/bin (CLI entry + skills sub-command)
- git mv src -> cli/engine (detect-antipatterns engine + browser variant)
- git mv lib -> cli/lib (download-providers helper)

Update package.json:
- bin.impeccable: cli/bin/cli.js
- main + exports: cli/engine/detect-antipatterns.mjs and the
  ./browser variant
- files: ["cli/", "LICENSE"]

Update internal references:
- cli/bin/cli.js: dynamic import points at ../engine/, package.json
  read goes one level deeper (../../package.json).
- functions/api/download/[type]/[provider]/[id].js + bundle/[provider].js:
  cli/lib/download-providers.js path.
- scripts/build.js, scripts/build-browser-detector.js,
  scripts/build-extension.js: cli/engine path constants.
- scripts/lib/sub-pages-data.js, scripts/lib/utils.js, skill/scripts/
  live-server.mjs: comment refs.
- tests/detect-antipatterns{,-browser,-fixtures}.test.{js,mjs},
  tests/windows-path-fix.test.js: import + read paths.
- AGENTS.md, CLAUDE.md: doc paths.

Verified:
- npx node cli/bin/cli.js --version, --help, detect --help all work.
- bun run build, bun run build:browser, bun run build:extension all
  clean. Browser detector lands at cli/engine/detect-antipatterns-browser.js;
  extension/detector/detect.js still emits to the same location.
- bun run test: 186/186 pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix: update browser-detector paths missed in cli/ rename

Bugbot caught two runtime path leaks where the comment got renamed
to cli/engine/ but the actual code still used the old src/ segment.

- skill/scripts/live-server.mjs: detectPaths array now joins cli, engine,
  detect-antipatterns-browser.js for both the repo-relative lookup
  (4 dirs up from .claude/skills/impeccable/scripts/ to repo root) and
  the npm node_modules fallback. Without this fix, the detection
  overlay would silently not load during live-server sessions.

- scripts/build.js: the post-build copy of the browser detector into
  site/public/js/ was reading from src/. The if (fs.existsSync(...))
  guard meant the copy was silently skipping, so antipattern-examples
  pages would 404 on /js/detect-antipatterns-browser.js once the site
  was deployed.

Tests: 186/186 pass. Build clean. site/public/js/detect-antipatterns-browser.js
re-emits as expected.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix: cleanup-deprecated import path missed an extra .. in cli/ rename

Bugbot caught three call sites in cli/bin/commands/skills.mjs that
import '../../skill/scripts/cleanup-deprecated.mjs'. Pre-rename, that
was correct from bin/commands/ (one parent to bin/, one to repo root).
After moving the file from bin/commands/ to cli/bin/commands/, the
path is one directory deeper, so it needs three .. segments to reach
the repo root. Without the fix, every cleanup invocation throws on
import and gets swallowed by the surrounding try/catch — silent skip.

cli/bin/cli.js's package.json read already uses '../../package.json'
(the same depth pattern), confirming three levels is correct.

Verified: dynamic import resolves and exports the expected functions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* chore: sweep stale path/file references missed in the restructure

Same root cause as the two bugbot finds: some references in moved or
related files weren't tracked because they didn't match a simple
sed pattern. Caught the rest by walking each moved dir's depth and
each Astro-migration deletion.

Stale path references (post-Astro migration, missed earlier):
- CLAUDE.md: legacy URL redirects "live in server/index.js" -> point
  at the actual sources (scripts/build.js generateCFConfig +
  site/public/_redirects).
- AGENTS.md: counts.js path (public/ -> site/public/), changelog file
  (public/index.html -> site/pages/index.astro), screenshots note
  (public/ -> site/), source-of-truth dirs (source/, src/ -> skill/,
  cli/).
- tests/detect-antipatterns-browser.test.mjs: comment about routes
  "in server/index.js".
- skill/reference/live.md: workflow.css example for "this repo" was
  pre-Astro (public/css/) -> site/styles/. (User-project Vite/Next
  example unchanged.)

Stale path that pointed at moved files:
- tests/skills-cli.test.js: CLI path was '..', 'bin', 'cli.js'; now
  '..', 'cli', 'bin', 'cli.js'. Test isn't wired into bun run test
  but it would have failed if invoked.

Dead files (orphaned by Astro migration, never cleaned up):
- tests/server/download-validation.test.js: imported from
  ../../server/lib/{validation,api-handlers}.js which were deleted in
  b8f09c8. Test was a silent failure waiting to happen.
- scripts/lib/render-markdown.js: 156-line module with zero consumers
  (the only caller, scripts/lib/render-page.js, was deleted in the
  Astro cleanup).
- scripts/build.js: dead commented-out generateSubPages import.

Tests: 186/186 pass. Build clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix(build): remove invalid Corepack packageManager spec

Cloudflare Pages rejects the build with `Unsupported package manager
specification (bun@1.3.11)`. The packageManager field follows
Corepack's syntax which only validates npm/pnpm/yarn — `bun@X.Y.Z`
parses as a malformed Corepack directive even though Bun itself
treats it as a hint.

Pre-existing on main since d874af0 (CF Pages deploy on main also
failing); just surfaces here because the PR triggers a fresh deploy.

CF Pages auto-detects Bun anyway (the build log confirms:
"Detected the following tools from environment: bun@1.3.11,
pnpm@10.11.1, nodejs@22.16.0"). Removing the field unblocks the
deploy without changing local dev behavior.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Paul Bakaus <paulbakaus@pauls-mbp-3.lan>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-04 16:38:03 -07:00

7.6 KiB

Additional context needed: the "aha moment" you want users to reach, and users' experience level.

Get users to first value as fast as possible. Onboarding's job is not to teach the product. Its job is to get people to the moment that proves the product is worth their time.

Assess Onboarding Needs

Understand what users need to learn and why:

  1. Identify the challenge:

    • What are users trying to accomplish?
    • What's confusing or unclear about current experience?
    • Where do users get stuck or drop off?
    • What's the "aha moment" we want users to reach?
  2. Understand the users:

    • What's their experience level? (Beginners, power users, mixed?)
    • What's their motivation? (Excited and exploring? Required by work?)
    • What's their time commitment? (5 minutes? 30 minutes?)
    • What alternatives do they know? (Coming from competitor? New to category?)
  3. Define success:

    • What's the minimum users need to learn to be successful?
    • What's the key action we want them to take? (First project? First invite?)
    • How do we know onboarding worked? (Completion rate? Time to value?)

CRITICAL: Onboarding should get users to value as quickly as possible, not teach everything possible.

Onboarding Principles

Follow these core principles:

Show, Don't Tell

  • Demonstrate with working examples, not just descriptions
  • Provide real functionality in onboarding, not separate tutorial mode
  • Use progressive disclosure, teach one thing at a time

Make It Optional (When Possible)

  • Let experienced users skip onboarding
  • Don't block access to product
  • Provide "Skip" or "I'll explore on my own" options

Time to Value

  • Get users to their "aha moment" ASAP
  • Front-load most important concepts
  • Teach 20% that delivers 80% of value
  • Save advanced features for contextual discovery

Context Over Ceremony

  • Teach features when users need them, not upfront
  • Empty states are onboarding opportunities
  • Tooltips and hints at point of use

Respect User Intelligence

  • Don't patronize or over-explain
  • Be concise and clear
  • Assume users can figure out standard patterns

Design Onboarding Experiences

Create appropriate onboarding for the context:

Initial Product Onboarding

Welcome Screen:

  • Clear value proposition (what is this product?)
  • What users will learn/accomplish
  • Time estimate (honest about commitment)
  • Option to skip (for experienced users)

Account Setup:

  • Minimal required information (collect more later)
  • Explain why you're asking for each piece of information
  • Smart defaults where possible
  • Social login when appropriate

Core Concept Introduction:

  • Introduce 1-3 core concepts (not everything)
  • Use simple language and examples
  • Interactive when possible (do, don't just read)
  • Progress indication (step 1 of 3)

First Success:

  • Guide users to accomplish something real
  • Pre-populated examples or templates
  • Celebrate completion (but don't overdo it)
  • Clear next steps

Feature Discovery & Adoption

Empty States: Instead of blank space, show:

  • What will appear here (description + screenshot/illustration)
  • Why it's valuable
  • Clear CTA to create first item
  • Example or template option

Example:

No projects yet
Projects help you organize your work and collaborate with your team.
[Create your first project] or [Start from template]

Contextual Tooltips:

  • Appear at relevant moment (first time user sees feature)
  • Point directly at relevant UI element
  • Brief explanation + benefit
  • Dismissable (with "Don't show again" option)
  • Optional "Learn more" link

Feature Announcements:

  • Highlight new features when they're released
  • Show what's new and why it matters
  • Let users try immediately
  • Dismissable

Progressive Onboarding:

  • Teach features when users encounter them
  • Badges or indicators on new/unused features
  • Unlock complexity gradually (don't show all options immediately)

Guided Tours & Walkthroughs

When to use:

  • Complex interfaces with many features
  • Significant changes to existing product
  • Industry-specific tools needing domain knowledge

How to design:

  • Spotlight specific UI elements (dim rest of page)
  • Keep steps short (3-7 steps max per tour)
  • Allow users to click through tour freely
  • Include "Skip tour" option
  • Make replayable (help menu)

Best practices:

  • Interactive over passive (let users click real buttons)
  • Focus on workflow, not features ("Create a project" not "This is the project button")
  • Provide sample data so actions work

Interactive Tutorials

When to use:

  • Users need hands-on practice
  • Concepts are complex or unfamiliar
  • High stakes (better to practice in safe environment)

How to design:

  • Sandbox environment with sample data
  • Clear objectives ("Create a chart showing sales by region")
  • Step-by-step guidance
  • Validation (confirm they did it right)
  • Graduation moment (you're ready!)

Documentation & Help

In-product help:

  • Contextual help links throughout interface
  • Keyboard shortcut reference
  • Search-able help center
  • Video tutorials for complex workflows

Help patterns:

  • ? icon near complex features
  • "Learn more" links in tooltips
  • Keyboard shortcut hints (⌘K shown on search box)

Empty State Design

Every empty state needs:

What Will Be Here

"Your recent projects will appear here"

Why It Matters

"Projects help you organize your work and collaborate with your team"

How to Get Started

[Create project] or [Import from template]

Visual Interest

Illustration or icon (not just text on blank page)

Contextual Help

"Need help getting started? [Watch 2-min tutorial]"

Empty state types:

  • First use: Never used this feature (emphasize value, provide template)
  • User cleared: Intentionally deleted everything (light touch, easy to recreate)
  • No results: Search or filter returned nothing (suggest different query, clear filters)
  • No permissions: Can't access (explain why, how to get access)
  • Error state: Failed to load (explain what happened, retry option)

Implementation Patterns

Technical approaches:

Tooltip libraries: Tippy.js, Popper.js Tour libraries: Intro.js, Shepherd.js, React Joyride Modal patterns: Focus trap, backdrop, ESC to close Progress tracking: LocalStorage for "seen" states Analytics: Track completion, drop-off points

Storage patterns:

// Track which onboarding steps user has seen
localStorage.setItem('onboarding-completed', 'true');
localStorage.setItem('feature-tooltip-seen-reports', 'true');

IMPORTANT: Don't show same onboarding twice (annoying). Track completion and respect dismissals.

NEVER:

  • Force users through long onboarding before they can use product
  • Patronize users with obvious explanations
  • Show same tooltip repeatedly (respect dismissals)
  • Block all UI during tour (let users explore)
  • Create separate tutorial mode disconnected from real product
  • Overwhelm with information upfront (progressive disclosure!)
  • Hide "Skip" or make it hard to find
  • Forget about returning users (don't show initial onboarding again)

Verify Onboarding Quality

Test with real users:

  • Time to completion: Can users complete onboarding quickly?
  • Comprehension: Do users understand after completing?
  • Action: Do users take desired next step?
  • Skip rate: Are too many users skipping? (Maybe it's too long or not valuable)
  • Completion rate: Are users completing? (If low, simplify)
  • Time to value: How long until users get first value?

When users hit the aha moment fast and don't drop off, hand off to {{command_prefix}}impeccable polish for the final pass.