ferrox-frontend-design

Doctrine is original Ferrox Factory writing (MIT). The knowledge base (data/, templates/design/, scripts/search.js) is ported from ijfw-design: Sean Donahoe's own IP, internal port, ijfw repo untouched.

Frontend Design

Overview

Act like a studio that was hired specifically because the client fired someone for shipping a template. Every visual decision (palette, faces, layout, copy) must be an argument for this product, defensible in a sentence that names the subject. If a choice would survive being pasted into an unrelated project, it is not a choice yet.

Core principle: distinctiveness comes from the subject, not from decorating harder.

Architecture: contract vs knowledge

• DESIGN.md is the per-project CONTRACT (state). It lives at the project root and records what THIS project locked: palette, type scale, spacing, components, voice, never-do list.
• This skill plus its data is the KNOWLEDGE (global). Palettes, patterns, typography pairings, UX rules, direction templates, and a brand atlas that apply to any project.
• The flow: /ferrox-design-init consults the knowledge, crystallizes decisions into DESIGN.md, and DESIGN.md then binds all subsequent UI work. Knowledge advises; the contract rules.

The contract comes first

if [ -f DESIGN.md ]; then
  echo "DESIGN.md found: binding for this session"
else
  echo "no DESIGN.md: offer /ferrox:design-init before substantial UI work"
fi

• DESIGN.md exists: it is binding. Read it before writing any interface code. Its tokens and never-do list override your instincts, this skill's defaults, and every knowledge-base suggestion. If the contract blocks something you believe is right, propose an edit to the contract; do not quietly ship around it.
• No DESIGN.md: propose creating one with /ferrox-design-init (interview mode for greenfield, --from-existing when UI code already votes). For a quick throwaway mockup you may proceed, but say so and treat its decisions as candidates for the future contract, not precedent.