[HINT] Download the complete skill directory including SKILL.md and all related files
| name | sf-design |
| description | Master design lifecycle. |
| argument-hint | <design question | audit | tokens | playground | redesign | migration | page/route> |
Before resolving any ShipFlow-owned file, load $SHIPFLOW_ROOT/skills/references/canonical-paths.md ($SHIPFLOW_ROOT defaults to $HOME/shipflow). ShipFlow tools, shared references, skill-local references/*, templates, workflow docs, and internal scripts must resolve from $SHIPFLOW_ROOT, not from the project repo where the skill is running. Project artifacts and source files still resolve from the current project root unless explicitly stated otherwise.
Trace category: obligatoire.
Process role: lifecycle.
Before executing from a spec-first chantier, load $SHIPFLOW_ROOT/skills/references/chantier-tracking.md, read the spec's Skill Run History and Current Chantier Flow, append a current sf-design row with result implemented, partial, blocked, or rerouted, update Current Chantier Flow, and end with the compact Chantier block from $SHIPFLOW_ROOT/skills/references/reporting-contract.md.
If no unique spec exists, do not write to a spec. For narrow read-only diagnosis, answer or route directly. For non-trivial design implementation, design-system migration, multi-page visual work, public/product-critical UI changes, or proof-sensitive redesigns, route to /sf-spec <title> and do not edit source files before readiness is ready.
Before producing the final report, load $SHIPFLOW_ROOT/skills/references/reporting-contract.md.
Default to report=user: concise, route-first, and in the user's active language. Use report=agent, handoff, verbose, or full-report only when another agent needs the detailed routing matrix, audit evidence, validation commands, owned surfaces, or unresolved design decisions.
Before choosing execution topology, load $SHIPFLOW_ROOT/skills/references/master-delegation-semantics.md.
This skill follows the shared master delegation reference. Design file work, validation sweeps, browser proof preparation, closure, and ship preparation default to delegated sequential when subagents are available. Parallel design work requires ready non-overlapping Execution Batches; without batches, run sequentially or refine the spec.
Before resolving design lifecycle gates, load $SHIPFLOW_ROOT/skills/references/master-workflow-lifecycle.md.
sf-design is a master/orchestrator skill. It routes design work through owner skills and lifecycle gates rather than duplicating specialist internals.
pwddate '+%Y-%m-%d'basename $(pwd)git branch --show-current 2>/dev/null || echo "unknown"git status --short 2>/dev/null || echo "not a git repo"ls BRANDING.md BUSINESS.md PRODUCT.md GUIDELINES.md 2>/dev/null || echo "no project design/business docs found"find specs docs -maxdepth 2 -type f -name "*.md" 2>/dev/null | sort | head -80ls next.config.* nuxt.config.* astro.config.* svelte.config.* vite.config.* remix.config.* gatsby-config.* package.json 2>/dev/null || echo "no framework hints found"find . -type f \( -name "tokens*" -o -name "theme*" -o -name "design-tokens*" -o -name "_variables*" -o -name "global.css" -o -name "globals.css" \) 2>/dev/null | grep -v node_modules | head -30 || echo "none found"find src app pages components -type f \( -name "*.astro" -o -name "*.tsx" -o -name "*.jsx" -o -name "*.vue" -o -name "*.svelte" -o -name "*.css" -o -name "*.scss" \) 2>/dev/null | grep -v node_modules | sort | head -80 || echo "none found"rg -n "#[0-9a-fA-F]{3,6}\\b|rgb\\(|rgba\\(|box-shadow:|transition:|font-size:\\s*[0-9]|gap:\\s*[0-9]|padding:\\s*[0-9]|margin:\\s*[0-9]" src app pages components 2>/dev/null | head -40 || echo "none found"sf-design is the recommended entrypoint for design-related work.
The operator should be able to ask a natural design question:
/sf-design améliorer la hero
/sf-design centraliser les tokens et les appliquer partout
/sf-design vérifier si le design est pro
/sf-design créer un playground de design system
/sf-design corriger les problèmes d'accessibilité visuelle
The skill decides the safe path and continues through the relevant owners:
intake
-> design intent routing
-> audit/discovery when needed
-> spec/readiness for non-trivial changes
-> owner-skill execution
-> checks and browser/specialist proof
-> sf-verify
-> closure and ship routing
Choose the smallest safe owner. Do not ask the user to choose a specialist when the request clearly names an intent.
| Intent | Route |
|---|---|
| Pure design question, workflow advice, or skill-choice help | Answer directly or provide the next command |
| No coherent token layer; create a central professional design system from existing UI | sf-design-from-scratch |
| Live preview/edit/export design tokens | sf-design-playground |
| Token coherence, hardcoded values, token coverage, typography/spacing/motion/palette architecture | sf-audit-design-tokens |
| Broad UI/UX audit, visual hierarchy, layout, responsive quality, trust, product coherence | sf-audit-design |
| Component variants, duplication, component API, design-system component architecture | sf-audit-components |
| Accessibility, contrast, focus, keyboard, reduced motion, target size, WCAG evidence | sf-audit-a11y |
| Non-auth visual proof, screenshots, console/network summary for UI pages | sf-browser |
| Auth/protected UI visual issue where login/session/provider state matters | sf-auth-debug |
| Broad implementation, redesign, multi-page migration, or product-critical UI change | sf-build or sf-spec -> sf-ready -> sf-start |
| Release/deploy confidence after design implementation | sf-deploy |
| Final bounded commit after verified design work | sf-ship |
When two routes are plausible and the answer changes scope, proof, brand direction, public claim, or ship risk, load $SHIPFLOW_ROOT/skills/references/question-contract.md and ask one numbered decision question.
Do not treat token centralization as complete site implementation.
Always distinguish three stages:
If a run creates tokens or a playground but migration coverage is incomplete, route the next real work explicitly:
/sf-design "Migrer le site pour consommer les tokens design centralises sans changement visuel volontaire"
Internal lifecycle for that follow-up:
sf-audit-design-tokens
-> sf-spec
-> sf-ready
-> sf-start
-> sf-check
-> sf-audit-design-tokens
-> sf-browser
-> sf-verify
-> sf-end
-> sf-ship
If the user only asks for the exact implementation command, recommend:
/sf-build "Actualiser le site pour utiliser les variables design centralisees dans toutes les pages, sans changement visuel volontaire"
Use direct routing for:
Require spec-first for:
Before implementation, the ready spec must name:
Typical flows:
Create design system:
sf-design-from-scratch -> sf-audit-design-tokens -> sf-design-playground optional -> sf-verify
Token migration across site:
sf-audit-design-tokens -> sf-spec -> sf-ready -> sf-start -> sf-check -> sf-audit-design-tokens -> sf-browser -> sf-verify -> sf-end -> sf-ship
Visual redesign:
sf-audit-design -> sf-spec -> sf-ready -> sf-start -> sf-check -> sf-browser -> sf-audit-a11y as needed -> sf-verify -> sf-end -> sf-ship
Deep design audit:
sf-audit-design deep -> sf-spec for chosen remediation -> sf-ready -> sf-start -> proof -> sf-verify
Accessibility-first design fix:
sf-audit-a11y -> sf-spec or sf-fix depending scope -> sf-browser/sf-test proof -> sf-verify
For design work that changes public wording, claims, docs screenshots, page promises, or content surfaces, run the editorial/docs gates from sf-build or route to sf-docs/sf-content as needed before closure.
Use project scripts and specialist checks instead of inventing proof.
Typical validation:
npm run lint
npm run build
npm test
Focused design evidence:
rg -n "#[0-9a-fA-F]{3,6}\\b|rgb\\(|rgba\\(|box-shadow:|transition:|font-size:\\s*[0-9]|gap:\\s*[0-9]|padding:\\s*[0-9]|margin:\\s*[0-9]" src app pages components 2>/dev/null
Route proof:
sf-check for local technical checkssf-audit-design-tokens for token coverage/coherencesf-audit-a11y for accessibility safetysf-browser for visible non-auth page proof and screenshotssf-auth-debug when auth/session state affects the UIsf-prod or sf-deploy for hosted truthStop and report blocked when:
sf-exploreEvery blocked report must include the exact next recovery route.
User-mode report:
## Design: [scope]
Result: [implemented / partial / blocked / rerouted]
Route: [owner skill or lifecycle]
Design proof: [checks/browser/audit evidence or missing proof]
Token implementation: [complete / partial / not applicable]
Next step: [only if real]
## Chantier
[spec path | non trace: reason]
Flux: sf-spec [marker] -> sf-ready [marker] -> sf-start [marker] -> sf-verify [marker] -> sf-end [marker] -> sf-ship [marker]
Reste a faire: [only if non-empty]
Prochaine etape: [only if non-empty]
Agent/handoff mode may add the routing matrix decision, owned surfaces, forbidden files, validation commands, browser proof obligations, docs/editorial plan, and unresolved decisions.