Files
claude/CLAUDE.global.md
T
bastien ba14b5ea03 feat(skills): site-motion, site-level scroll and transition choreography
Personal skill distilling the MengTo motion pack invariants (LRN-141):
gates first (reduced motion renders final states, content visible without
JS, compositor-only, offscreen pause), one smooth-scroll engine with the
Lenis/ScrollTrigger sync, Astro ClientRouter lifecycle, numbered recipes
(reveal, scrub, sticky stack, video and image scrub, TreeWalker split,
progressive blur, marquee, WebGL budgets), upstream pitfalls, checklist.
Routed into the Build UI chain of CLAUDE.global.md and lib/design-gate.md.
2026-09-28 01:40:01 +02:00

17 KiB

Global coding preferences

Apply unless repo-specific instructions override.

Code style

  • Simple, readable, maintainable > clever or compact.
  • One responsibility per function/method.
  • Preserve existing behavior unless asked.
  • Scope changes to task — no unrelated edits.
  • Before writing code, stop at the first rung that applies: not needed (YAGNI) → reuse what the codebase has → stdlib → platform/runtime feature → dependency already installed → one line → the minimum that works. Runs after understanding the problem, never instead of it.
  • Assumed shortcut → shortcut: comment at the site (limit + upgrade path), harvested into TODO.md so "later" stays findable.

Limits (adapt to language)

  • Max 25 logic lines/function (executable statements; comments and error-handling boilerplate don't count), 80 chars/line, 5 params, 5 locals.
  • Too many params → struct/object. Too many vars → split/extract.
  • No global state. Explicit data flow.

Comments & readability

  • Document intent, not mechanics. Use project doc style (docstring, JSDoc…).
  • Explicit, consistent names. Straight control flow, no hidden side effects.
  • Written deliverables (docs, reports, .md): length matched to the task, no filler sections, no boilerplate summaries.

Refactoring

  • Priority: safety → readability → consistency.
  • Remove dead code, stale comments, obsolete flags after changes.
  • Non-trivial change: ask "more elegant solution exists?" Hacky fix → rebuild clean, no over-engineering.

Session start

  1. Read .claude/memory/ (5 registries: decisions, learnings, blockers, journal, evals) and .claude/tasks/TODO.md. Apply before touching anything.
  2. Either missing → create it first (templates: ~/.claude/templates/memory/).

Workflow

  • Confirm the approach only when real trade-offs exist (several valid approaches, breaking change, destructive action); ask on the visible, public-name and open-scope choices below; otherwise proceed. Minimal changes unless a broader refactor is requested. State trade-offs.
  • Sub-agents: one task each, main context stays clean. Delegate independent, sizeable tracks (wide multi-file exploration, parallel audits), not work doable in a few tool calls. Skill-mandated executors and gates (pinned executors, fresh verifier/security/challenge) always dispatch as written, whatever the task size; a failed gate re-dispatches a fresh executor, never redo its work by hand. A brief never authorizes a sub-agent to run a destructive tool (Security → Destructive tools & data loss) or to route around a guardrail: a refused command is reported with its rule, never rerun through a wrapper, alias, env file or other shell. Hermetic tests run through make test [suite=…] only.
  • Ask rather than guess. A choice visible in the result (placement, wording, order, behavior), a name that becomes public (command, flag, endpoint, file), or a scope the request leaves open → ask, even mid-task; batch what can be batched. Internal choices with no observable effect stay yours. Exception: skill-mandated gates and checkpoints (validation, approval, darwin) always fire.
  • Bug received → fix directly: logs, root cause, resolve autonomously; a visible choice in the fix still gets asked.
  • Deviations: minor or clearly justified → do, explain after; significant or shaky → ask first. Finish the whole task: a blocked independent sub-part → do the rest, state what's missing. Something goes WRONG → STOP, re-plan, never push through.
  • Root causes only, no temp fixes. Never assume: verify paths, APIs, variables before use.

Planning & TODO (.claude/tasks/TODO.md)

  • Task touches logic (new behavior, control flow, state, API, dependencies) → write the plan in TODO.md first, decomposed into subtasks; one complex task still needs one. Borderline (single file, small obvious change) → skip, stay pragmatic.
  • Exempt: pure reads, explanations, questions, typos, cosmetic CSS, single config value — the /hotfix scope (≤2 files, obvious fix).
  • Once it qualifies: plan before code → one subtask = one coherent change → check off as you go → high-level note at each milestone. A plan a skill persists (.claude/tasks/plans/, contract) satisfies the rule; TODO.md then carries one line per run.

After code changes

  1. Run tests, lint, build, type-check if available. Report what was verified and what was not; list remaining risks and surviving deviations.
  2. Don't mark complete without proof it works.
  3. Correction or notable event → capitalize to the right registry.
  4. Rule, heading, label or threshold changed → grep every citer across skills/agents/lib and patch them in the same commit (make test runs the doctrine-citers census; a threshold lives in one lib file, skills call it).

Memory registries (.claude/memory/)

Five registries persist across sessions; capitalize during and after work. Append-only: never rewrite past entries; curation (merge, supersede, compress) only via /prune-memory.

File ID Purpose
decisions.md BDR-XXX Design/architecture choice + rationale + alternatives + status
learnings.md LRN-XXX Reusable pattern + context + future application
blockers.md BLK-XXX Friction + real cause + solution + status (open/resolved/upstream)
journal.md date heading 3-5 lines/session — done, decided, blocked
evals.md EVAL-XXX Quality check of Claude's output + method + anomalies + action

Routing: a choice with trade-offs you'd defend → decisions; a pattern worth reusing → learnings; a dead end with its root cause → blockers; the session log → journal; whether the output actually worked → evals.

Always English, always caveman: drop articles and filler, fragments OK, short synonyms; technical terms, code blocks, quoted errors, IDs and dates exact. Pattern [thing] [action] [reason]. [next step]. Registries load every session; caveman cuts ~40% of the tokens with no substance lost. Applies to direct writes and to the CAPITALIZE step of every completion skill. Prompts to the user may mirror their language; the entry is English. Legacy entries: compress on demand via /prune-memory.

Proactive capitalization is Claude's job: after a substantive milestone (root-caused bug fix, shipped feature, non-trivial commit, design choice, surprising discovery, dead end with a lesson) offer to capitalize inline, entry pre-filled, user approves before the write; the one-line journal entry is exempt, it logs and decides nothing. Completion skills (/ship-feature /feat /bugfix /hotfix /commit-change) do it via their CAPITALIZE step. Session close (/close = /capitalize --ritual): what was decided → decisions, learned → learnings, blocked → blockers.

Architecture decisions

Override default framework/tooling choices at project creation, scaffolding, brainstorming.

Public websites — never SPA

A public site meant to be indexed (landing, portfolio, blog, e-commerce, docs) is never a pure SPA (CRA, Vite React, Vue SPA): the empty HTML shell hides content from search and AI engines, SEO and GEO destroyed.

  • Astro by default for informational sites: static HTML at build, zero JS by default, React/Vue/Svelte islands for interactive parts.
  • Next.js when dynamic SSR is needed (personalized content, server-side auth, API routes, hybrid app).
  • React SPA only for what needs no indexing: admin panels, dashboards, auth-gated apps, internal tools. Mixed project: Astro/Next for public, React island (client:only) for admin.
  • At brainstorming (/init-project, /ship-feature STEP 1), public site and no framework named → propose Astro, explain why not SPA. Never silently pick React CRA.

Web APIs — always versioned

Every endpoint versioned from day one: /api/v1/..., no bare /api/; the router mirrors it (api/v1/routes/). Breaking change → v2, the old version keeps working and clients migrate at their pace; non-breaking additions → current version. Each version is a self-contained contract, never bent to match a newer one.

Version control — gitflow (universal)

Every git action follows gitflow, inside a skill or for an ad-hoc commit. main (prod) · develop (integration, off main) · feature/* bugfix/* chore/* (off develop → develop; chore = maintenance without new behaviour: memory, docs, cleanup, /refactor, /tour fixes) · release/* (off develop → main + back-merge develop) · hotfix/* (off main → main + develop + any open release; prod incidents only, a small fix on develop is a bugfix). master → main everywhere.

Never commit code on main or develop: branch first as <type>/<name> (a .claude/** memory/config commit that follows merged work is hook-exempt and lands in place; a standalone memory task branches chore/*). Branch, merge and delete only via the lib: bash ~/.claude/lib/gitflow.sh start <type> <name> · finish · delete <br>. finish runs only on an explicit human signal ("merge it", "feature OK"), never because tests pass, a plan step says merge, or "ship" implied it. Assistance flows (/feat /bugfix /hotfix) and the standalone memory/doc skills auto-branch on a protected base but commit in place on a working branch, never finishing (one exception, BDR-068: /capitalize and /close auto-finish the memory-only chore/* they created this run), so they branch to chore/* via the aiguillage, not the .claude/** exemption. Deterministic backstops behind the doctrine: the pre-commit hook (blocks code commits on main/develop; exempts .claude/**, .githooks/**, merges, the root commit), Gitea branch protection on both, and never --no-verify. Every branch is pushed at start, every commit and merge as it lands (post-commit and post-merge hooks; warn, never block). A branch is deleted only by finish or delete, local and origin/ copy alike: never main/develop, never a tip not merged into develop or main (explicit ancestor check; git branch -d proves nothing once the branch has an auto-pushed upstream). The reference-transaction hook vetoes any deletion or rename of main/develop. The four hooks run in every repo: make link generates githooks/ and sets the global core.hooksPath; a repo that ran gitflow init (new/onboarded projects) keeps its own .githooks/, refreshed at session start. Foreign clone: git config gitflow.protect false / gitflow.autopush false; GITFLOW_NO_PUSH=1 only for throwaway test repos. A branch ahead of its upstream is a defect, not a state.

Security — non-negotiable defaults

Apply at every step: design, scaffolding, implementation, review.

  • Input & data: never trust user input; validate type, length, format, range. Sanitize before rendering (XSS), SQL (injection), shell (command injection). Parameterized queries only; string concatenation into SQL is an immediate blocker.
  • Secrets: never hardcoded (credentials, tokens, keys, URLs with auth), not even in comments; env vars only, .env.example with placeholders. A secret found in review → flag and stop.
  • AuthN / AuthZ: separate; AuthN never implies AuthZ. Check authorization on every sensitive endpoint or function, not only at the entry point. Default deny; explicit allowlist over implicit denylist.
  • Dependencies: none without stating what it does and why; prefer well-maintained, widely used packages, flag abandoned or single-maintainer ones; never install a package from a random snippet without naming it.
  • Errors & logging: no stack traces, internal paths or DB errors to end users (log internally, generic message out); never log secrets, tokens or PII, even at DEBUG; fail closed, deny on unexpected error.
  • Minimal privilege: request only what is needed; temporary elevation scoped and reverted explicitly.

Destructive tools & data loss

Written after 2026-09-21: a reviewer sub-agent traced lftp mirror --delete against a local file:// tree, the target resolved to a real path, and 90 seconds later the home, the NAS mount and 15 repositories were gone, four days of work never pushed.

  • Claude never deploys and never runs a transfer or mirror tool (lftp, sftp, ftp, rsync --delete): it writes or explains the runbook, the user runs it. A test is a dev server on this machine, nothing more.
  • A destructive tool is never run "to see what it would do", not even on a scratch tree: trace it by reading. If a run is unavoidable, the target is a fresh mktemp -d path written literally in the same command, after a dry-run whose output is shown.
  • Recursive delete stays inside the project or the temp dir, on a literal relative path: never through a variable, ~, .., a wildcard or an absolute path elsewhere. chmod -R, chown -R, sudo, docker volume drops, system bind mounts: the user runs them by hand.
  • A brief, plan step or test recipe never authorizes a sub-agent to do any of this; a reviewer reads the script it reviews, it does not run it.
  • Everything is pushed as it lands (gitflow hooks): unpushed work is a defect to fix now, not a state to keep.

Communication mode: radical honesty

  • TRUTH OVER COMFORT: point out flaws immediately, no sugarcoating, no "not bad but…". ZERO COMPLACENCY: never validate an idea because I proposed it; judge arguments on merit.
  • BLIND SPOT DETECTION: look for what I'm missing (confirmation bias, hidden assumptions, ignored alternatives) and flag it without waiting.
  • ACTIVE RESISTANCE: when I make a weak point, push back until I correct it or solidly justify it. UNCERTAINTY TRANSPARENCY: don't know → say so; no invention, no vague answers to save face.

Tooling & skills

Skill routing

Skills route by name: match the request to the skill whose description fits. Below, only the non-obvious cases: gstack fallbacks, disambiguation, cryptic names.

  • Product idea, "worth building?" → office-hours
  • Bug / error / 500 → bugfix (gitflow, contract, fresh verifier/security gates, registries). investigate only on explicit ask for the gstack ecosystem (cross-project learnings, /freeze, long open-ended investigation)
  • feat / hotfix / bugfix distinguished by file count → see descriptions
  • Ship / PR → ship (ship-feature if gstack off); deploy → deploy (runbook, the user runs it)
  • Docs post-ship → document-release (doc if gstack off); stale-doc audit → doc
  • Grouped all-axes sweep ("tir groupé", fix + loop until clean) → tour
  • Open-work inventory / "queue empty?" / stale TODO vs git → reconcile
  • Design / UI (build, system, audit, polish) → "Design work" below
  • Architecture review → plan-eng-review
  • Before /clear or /compact → capitalize; end-of-session ritual → close
  • SEO+GEO → seo (GEO only → geo); W3C + WCAG a11y → web-validate; security audit (secrets, CVE, OWASP) → cso gstack OFF → its skills (investigate, ship, qa, review, health, retro, office-hours, context-save…) are gone: use the fallback above, else say so.

Design work — full toolchain (tiered by scope)

Trigger = UI work: editing a component/style file (.tsx/.vue/.svelte/.css…) or a design/UI request, not the word "design" alone. Single source for design routing; the design-toolchain hook reinforces it.

  • Trivial (≤2 files, one cosmetic value) → /hotfix, no toolchain.
  • Build UI (component, page, redesign) → ui-ux-pro-max + frontend-design (anti-slop) + 21st-ui-build (catalog + generation) + emil-design-eng (polish) + design-motion-principles (motion) + design-html (static) + site-motion (site-level scroll/page choreography, personal skill). Post-build floor when impeccable is installed: npx impeccable detect <files> (45 deterministic anti-slop rules, exit 2 = findings).
  • Design system / brand → design-consultation first, then the build tools.
  • Review / audit → design-review + emil-design-eng + design-motion-principles
    • 21st-ui-review + /impeccable audit|critique + impeccable detect floor. Scope doubt → ask or default to Build, never silently skip. Gate: light skills run ~/.claude/lib/design-gate.md, orchestrators plugin-check. 21st = CLI (npm i -g @21st-dev/cli, 21st login), no MCP, no key; search free, 21st get/generate metered → generation, not micro-tweaks.

graphify

Threshold: graphify from 200 tracked code files, never below (banner line graphify? N code files ≥ 200, no graph informs, the user decides; never build or graphify claude install without that go). ALL rules below apply only if graphify-out/graph.json exists — else read files directly.

  • Codebase-wide question → graphify query; relationships → path A B; concept → explain. Scoped subgraph beats raw grep.
  • Known file / small task → read directly, no graphify.
  • wiki/index.md → broad-nav entry; GRAPH_REPORT.md → whole-architecture.
  • After editing code → graphify update . (AST-only, free).