What does Unified Design System do?
A single entry point covering all design domains.
Resource Loading Rules
Load the manifest at start. Load phase-specific resources on demand during each stage. Do not generate based on user preference profiles; see
skill-architecture.htmlfor skill architecture,skill-workflow.htmlfor operational routes, andCHANGELOG.mdfor version changes.
Loading at Startup
| Resource | Why |
|---|---|
manifest.md | Know which domains and resources exist |
Loading Budget (Hard Cap)
This skill has 125 files; reading everything before acting = task failure.
| Constraint | Value |
|---|---|
| Startup load (not counted in budget) | manifest.md—registry must-read, doesn't use quota |
| Rule files outside the main file, max additional | 4 |
| Total lines in these files combined | ≤1200 lines (real total ceiling) |
| Single file >400 lines | Only read the named § section, not the entire file |
Why 4: The real cost is lines, not file count (the 3 mandatory Web files use only 37% of the 1200-line budget). The file count limit is a heuristic to prevent "reading a bit here and a bit there"—4 files × ~300 lines ≈ 1200 lines, so both constraints are self-consistent. Don't treat the 4th slot as a default spare to use casually—use the following placement decision first.
The budget is spent in order: ① Domain main file (domains/web/distilled-playbook.md / domains/poster/MODE.md / domains/brand/MODE.md) ② The mandatory file in that domain (e.g., domains/web/anti-slop/MODE.md) ③ Read only the relevant § section of shared/ when exact values are needed.
With the current structure, a single Web task's mandatory reads are 3: distilled-playbook.md + domains/web/anti-slop/MODE.md + references/flow.md. Asset tiers, local font lists, and engineering pitfalls P1–P11 are all in this file—no need to dive deeper. Design purpose of the 4th slot: Stage ④ reads shared/react-bits-assets.md (§0 + §3, reading the full 1626 lines is forbidden). Otherwise, it is a spare reserve (use when a 4th file is truly needed—see "Where to place new rules").
Domain principles are split by domain (reference level, not counted toward mandatory read quota): Cross-domain common core shared/design-principles.md (§1.1–§1.12) + domain subsets shared/design-principles-web.md / shared/design-principles-brand.md / shared/design-principles-poster.md. Loading method: Load only the subset corresponding to the current domain; use on demand (e.g., read the relevant section of design-principles-web.md only during Stage ① competitive analysis / Stage ③ memory point design for a Web task); reference level, not counted toward the mandatory 3-file quota, no need to read the entire common core.
references/gates.md and constraints.md are optional references (criteria details / boundary cases), do not count toward the 3-file quota—check when needed, skip otherwise.
Forbidden: Reading all referenced files to "understand the big picture"; reading the entire shared/react-bits-assets.md (1626 lines; for component selection, see §3 categories / §5 detailed explanations) or shared/design-philosophies.md (for philosophy selection, see §Selection Guide); reading 4+ files sequentially without taking action.
Where to Place New Rules (Placement Decision—Use This First, Then Spend Budget)
When adding a new rule, evaluate in order. If a step is true, do not create a new file:
- Needed by all domains, all tasks? → Place in the main file (the main file doesn't count toward the budget—this is the correct cost for a mandatory rule: if it's needed every time, it should be there every time). Criteria: Both a poster task and a Web task would get it wrong without this rule.
- Only belongs to the workflow of a specific domain? → Merge it into an existing mandatory file for that domain (e.g., for web, merge into
distilled-playbook.md), don't add a new file. SSoT: Prefer using subsection headings over creating new files. - Just values / details / lookup tables? → Place in the corresponding
shared/file, keep as reference level (not counted toward mandatory read quota, check when needed). If the main file is relevant, leave a one-line pointer. - None of the above, and truly required every time? → Only then allow a new 4th mandatory read file. Register which domain line it belongs to in the "Domain Quick Reference" and confirm the 1200-line total gate still holds (currently the Web line uses 439/1200).
Main file warning line: ≤400 lines. If exceeded, prioritize moving "non-every-time-use" content down to references (leave a one-sentence criterion) instead of continuing to bloat—every line added to the main file costs every task.
Exhaust and stop: Produce output with what has been read; at delivery, add one line stating "Skipped X (loading budget)." A complete solution based on 3 files > reading 10 files without output.
Pre-Delivery Self-Check (Doesn't Count Toward Loading Budget)
After producing HTML, it's recommended to run a headless browser render (npx playwright screenshot / local Chrome·Edge --headless --screenshot), taking screenshots at 1440 and 390 widths at minimum, and verify three things:
- Is the above-the-fold area blank?—If animations depend on JS/IntersectionObserver to appear, slow machines and screenshot scenarios will show all white; above-the-fold content must be directly visible.
- Is there horizontal overflow or text touching edges?—Check if block-level
paddingshorthand covers the container's left/right inner spacing. - Is the title overflowing?—If a title exceeds 3 lines at desktop width, the
clamp()upper limit or font size is wrong.
Fix issues found on the spot; do not deliver pages that haven't been rendered. Looking at the code won't reveal these three types of problems.
Self-check budget (has a cap, to prevent infinite rework): Maximum 2 rounds, 2 screenshots per round (1440 / 390), ≤90 seconds per round. If issues remain after two rounds, stop and document the remaining issues in the delivery notes—self-checks are a means to find three types of structural problems, not to perfect the page.
7 Core Design Principles
These 7 principles are the soul-guiding compass for design. They are not a checklist, but a direction for thinking.
| Principle | Core Inquiry Question | Meaning |
|---|---|---|
| Grounded | Know who you are designing for and what problem you are solving | Before starting, figure out: Who is the target user? What do they need to do after viewing the page? What is the single core message to convey? Design without foundation = self-indulgence |
| Soulful | Has a unifying tone to which all decisions serve | "If this page were a person, what would their temperament be?" Define it with one word (e.g., "refined"/"powerful"/"rebellious"). All subsequent colors, fonts, spacing, and animations revolve around this word. |
| Systematic | All elements obey a single visual grammar | Colors, fonts, spacing, animation durations, interaction feedback—establish a unified rule; then every new element automatically inherits this system without needing individual decisions. See shared/system-design.md §2 Design starting point selection + §3 Three-parameter impact matrix |
| Memorable | At least one thing that makes someone stop and look | Could be a unique interaction method, a kind of texture, a way of handling typography, a spatial relationship. Doesn't need to be complex—a well-executed simple idea is better than ten rough complex effects. |
| Warm | Convey emotion, not just stack information | What feeling does the page give? Calm, energetic, warm, mysterious, high-tech, natural? Emotion is not decoration; it's the underlying driver of design |
| Quality | Delivery must be complete and usable, not half-finished | Every state is accounted for (loading/empty/error/success), mobile adaptation is complete, prefers-reduced-motion is supported, CSS variables are used |
| Craftsmanship | Did you take this design seriously? | Don't omit important content, don't be sloppy, don't substitute inferior materials, don't make things carelessly. Every detail is treated with respect, give it your all, don't cut corners |
Single Source of Truth Covenant (SSoT · Must Read Before Modifying This File)
The main failure mode of this file in the past: the same rule was copied to 3–4 places—copied into the process table, a hard checkpoint, a quality gate, and then again into constraints. The consequence is not "more safety" but being treated as a repetitive empty checkbox: checking one box counted as passing, while the rule was actually ineffective. This is precisely the mechanism behind "paper compliance ≠ code-level compliance."
Hierarchy of Responsibilities (add new content according to this; misplacement is considered a defect):
| Layer | Location | Place Only This | Forbidden to Place |
|---|---|---|---|
| Definition Layer | "Work Style Constraints" 0–9, "Universal Bottom Lines" | The single definition of a rule | — |
| Process Layer | Adaptive design process stage tables | When to do what + which file to check + pointers ("per Constraint X") | Forbidden to restate constraint definitions |
| Gate Layer | Stage 4 Execution Gate, Quality Gate, Engineering Pit Gate | Verification actions / PASS thresholds / inspection questions | Forbidden to restate institutional definitions |
Placement Test (ask when adding a rule): Is this defining a rule or verifying a rule? → Definition goes in the Definition Layer, verification goes in the Gate Layer; it can only land in one place. → Further: Judgment-type (taste/coherence/richness, cannot be mechanically determined) belongs to Quality Gate; Fact-type (verifiable with grep/ls/assertion) belongs to Engineering Pit Gate. If mis-placed, that rule becomes invalid.
Design Process (6 Stages)
| Stage | What to Do | Deliverable |
|---|---|---|
| ① Research & Requirements | Extract implicit requirements, determine domain, set three parameters | Requirements restatement (used for CP1) + three parameters |
| ①.5 Proactive Reasoning | Extend a one-line requirement into a complete brief | Extended brief |
| ② Inspiration Lock | Directly lock 1 highest-level direction (one of four axes) | Direction + core tension (used for CP2) |
| ③ Concept & Narrative | Information architecture, scroll narrative, intention mapping | Intention Map (mandatory; Stage ④ must not proceed without this output) |
| ④ System Design | Design grammar, animation inventory, capability inventory; for animation/interaction components, first check shared/react-bits-assets.md §0 (settlement status: 11 local ✅, rest 🌐 require network) + §3 screening, use only ✅ or create equivalents | System design table + capability list ≥8–10 items (must note component source: react-bits ✅ / 🌐 / self-created) |
| ⑤ Visual Implementation | Font / color / layout / asset implementation | Page output (HTML/CSS/JS, format per shared/code-generation-strategy.md §3.1; includes implementation or fallback declarations for fonts and assets) |
| ⑥ Interaction & Delivery | Interaction, performance, three gates | Final product past gates (used for CP4) + append one line to usage-log.md (date / task / seed / mouse family / component) |
Read only the corresponding section of
references/flow.mdfor the stage you are in—no need to read the whole thing. Each section contains a three-column table: "What to Do / Specific Content / What to Consult."
Domain Branching (Important): The 7 steps above are the full Web process. The other two domains follow their own lines—do not apply the Web stages and gates to them:
- Poster →
domains/poster/MODE.md§8's 5 steps: Set dimensions → Set proposition → Select family → Arrange three layers → Thumbnail self-check - Brand →
domains/brand/MODE.md's B1–B5: Strategy (9-question method) → Visual mode → Logo → Brand board → Output
Video → domains/video/MODE.md: First determine if it should be used (§1) → Determine role and volume (§2) → Select route (§3) → Integrate (§4, 90% of non-cohesion is at seams) → Pass V1–V9 delivery checks.
Tools are a bypass, not in the main loop: PPT / Video export / Renovation audit / Design thinking are triggered independently (see "Domain Quick Reference"), parallel to the 6 stages, not numbered as stages.
Work Style Constraints 0–9 (Quick Reference)
| # | Rule | Criteria / Exception |
|---|---|---|
| 0 | Explicit user instruction > General default | If in conflict with a hard rule point out and offer an alternative; if user insists, comply |
| 1 | Lock the highest-level direction directly; do not present parallel options | One of the four axes (Ultimate Restraint / Density / Motion / Material); go all the way; do not downgrade based on implementation difficulty (difficulty only affects the implementation path, not the solution) |
| 2 | Expansion of Constraint 1's scenario | "Anything" → 1 solution; "Give 2–3 options for comparison" → only then provide multiple solutions |
| 3 | Ask only one question per change | Multiple questions = user cannot attribute |
| 4 | Polish quality over speed | Animation without motivation / rhythm completely flat / missing states → stop and fix |
| 5 | Number of sections is determined by planning | If <5, must explain "why minimalism fits this brief"; forbids padding, forbids laziness |
| 6 | Patterns are seeds, not skeletons | Forbidden to "select a style → apply a skeleton"; must reassemble on the spot |
| 7 | Seed-driven coherence covenant | Every dimension either resonates with the seed or explicitly states "intentionally omitted" |
| 8 | Anti-conservative generation discipline | ≥3 technical languages; interactions must be real; text must also move |
| 9 | Asset library usage discipline | Lock seed first → ≤1 from the same family on this page → write a usage statement |
| 10 | Freeze the plan; forbid grabbing ready-made items casually | First list "what the plan needs" then check "what's on hand"; replacements must be documented as "planned / implemented / why not equivalent"; silent replacement = failure |
For full rules, boundary cases, and rationale (including conflict resolution details for Constraint 0), see
references/constraints.md. Constraint 0 has the highest priority, overriding all other constraints and gates (except engineering bottom lines).
Gate Quick Reference (Must Pass Before Delivery)
| Gate | Timing | What to Check | What to Do If Not Passed |
|---|---|---|---|
| Execution Gate | Before entering Stage ⑤ | Capability inventory ≥8–10 items (must include ≥1 text animation / ≥1 WebGL·Canvas / ≥1 GSAP·scroll orchestration); duplicates of the same family must provide a seed reason (check usage-log.md); network fetch records (what was fetched → from where → result, A3); when delivery format is restricted, provide up to the achievable limit and note the reason; forbids fabrication and silent omission | Fill inventory before proceeding |
| Quality Gate 7 Principles | End of Stage ⑤ · Before Stage ⑥ | Delivery must provide PASS/HOLD decision (taste-rules.md §8, forbids "overall not bad"-style clearance); critique 10 dimensions + media/animation/layout checking if "restrained yet rich" + seed coherence + anti-conservatism 7 questions | Go back to the corresponding stage to fix; forbid delivering half-finished work |
| Engineering Pit Gate P1–P11 | Before delivery | Mechanical verification with grep / ls: font implementation, CDN fallback, horizontal overflow, italic descender alignment… | Fix until PASS; forbid delivering with FAIL |
Criteria details for the Execution Gate and Quality Gate are in
references/gates.md; Engineering Pit P1–P11 are below, mandatory for every task, not moved down.
Engineering Pit Gate P1–P11 (Run Each One Before Delivery)
Division of labor with the Quality Gate above (Critical): The Quality Gate judges "Is it good?"—taste/coherence/richness, a judgment type, based on aesthetics, not mechanically determinable; This gate judges "Is it broken?"—known engineering defects that actually harm usability/appearance, a fact type, based on verification. Inclusion Criteria: Only include items that can be mechanically verified using grep / ls / runtime assertions. Judgment-type rules must never enter this gate (stay in the Quality Gate), or they will degrade into a self-certifying empty checkbox. Execution: Run each one before delivery; any FAIL → fix and retest; forbid delivering with FAIL.
| # | Pit (Real mistakes encountered) | Verification Method | PASS Condition |
|---|---|---|---|
| P1 | Only background animates, content does not (most common, most damaging to "overall feel") | grep every content section's scroll animation binding | Content containers exist with scroll-linked translateZ/scale/rotate, not only opacity/clip-path; and background and content are driven by the same progress |
| P2 | Depth/decorative layers obscure content | Check z-index stacking + pointer-events | Near-scene/decorative/noise layers have z-index lower than content layers, and all have pointer-events:none |
| P3 | Transition flicker/glare frames | Check flicker element opacity peak and duration | Peak ≤ .4 and duration ≥ .3s (quantifiable threshold, exceeding = glare) |
| P4 | prefers-reduced-motion not properly degraded | grep for the media query branch | Branch exists and turns off WebGL/heavy animation/flashes within it, not just shortens duration |
| P5 | Font/JS referenced but file not implemented | ls the output directory assets/fonts/ and .js | The files pointed to by @font-face's src and <script src> physically exist (single-file delivery is an exception: instead check if the delivery contains @font-face snippets + a list of TTF files); if interactive-editing.js is used, the file is also present and the page fully uses CSS variables (otherwise the panel can't adjust parameters) (co-inspected with Quality Gate 6; this is the verification action) |
| P6 | CDN dependencies have no fallback; library failure leads to white screen/no cursor | grep whether CDN <script> has fallback branches | When critical libraries fail to load, the page remains readable and the cursor does not disappear (system cursor must be hidden only after JS confirms readiness) |
| P7 | Animation animates non-GPU properties | grep transition/animation/GSAP properties | Only transform/opacity/filter (+ camera parameters), no width/top/left |
| P8 | Mobile not degraded | Check WebGL toggle at breakpoints | At ≤820px, turn off heavy WebGL, use CSS 3D fallback |
| P9 | Uses AI-slop fonts | grep font-family / @font-face | Display font is not Inter / Fraunces / Instrument Serif (these three have been overused, see anti-slop MODE.md) |
| P10 | Animation speed out of range / curve out of family | grep -oE "transition:[^;]*[0-9]+m?s" and grep -oE "cubic-bezier\([^)]*\)"; if transition: all appears, mark as an issue | All durations fall within the four tiers of motion-rules.md §1, all curves within the four families of §2, no all |
| P11 | Focus not visible / widget semantics missing | Tab through (or headless page.keyboard.press("Tab") then screenshot); grep outline://s*none, role="dialog" (must have aria-modal), <th (must have scope) | Every element has focus-visible (≥2px, contrast 3:1); dialog has focus trap + Esc; table headers have scope/caption (WCAG 2.4.7 / 1.3.1) |
Sedimentation loop (let the gate evolve itself): Every time an engineering pit is fixed, convert it into a one-line verifiable assertion and add it to this table (write down the verification method + PASS threshold), rather than just noting "next time be careful." Judgment-type lessons go into the Quality Gate; fact-type lessons go into this gate—if classified incorrectly, that rule becomes invalid.
Known Limitations (honest labeling): This gate can only block known and verifiable pits; it cannot block taste failures or brand new pits. Taste relies on the Quality Gate + human eye acceptance; brand new pits are gradually incorporated through the sedimentation loop above.
Post-Delivery: Feedback → Which Stage to Return To
This is the closed-loop return edge. First determine "which layer is wrong," then decide how many steps back to go—restarting from the beginning is the most expensive fix.
| User Feedback | Where the Real Problem Lies | Return To |
|---|---|---|
| "Not what I wanted / misunderstood" | Requirements | ① Re-align |
| "Too flat / too conservative / looks like a template" | Insufficient direction ambition | ② Re-lock the highest-level direction (one of four axes) |
| "Structure is messy / don't know where to look" | Information architecture and narrative | ③ Redo the Intention Map |
| "Not cohesive / sections don't look like a set" | System design (inconsistent grammar) | ④ Redo design grammar |
| "Just doesn't look good" | Visual execution | ⑤ Adjust fonts/colors/layout/assets |
| "Redo / start over / redesign / give me another option" | Clear request for a new version | Completely new redo (see three hard rules below) |
Change only colors / fonts / spacing → No need to return to a stage; modify directly and skip the Stage ④ Execution Gate (see references/gates.md, item D).
Multiple rounds of minor tweaks (continuation of the same task): After the first round of delivery, the user says "adjust a bit more / try a different feel"—this is a continuation of the same task; go directly to the corresponding stage (color adjustment → Stage ⑤, direction change → Stage ② relock); no need to redo Stage ① or repeat CP1; merge multiple rounds of changes before unified delivery, to avoid confirming every time and annoying the user.
Major direction change mid-process (after Stage ③): User says "change the style / wrong direction" → return to Stage ② to re-lock (requirements haven't changed, only the direction is wrong, don't return to Stage ①); refactor rather than patch the already written code according to the new direction; forbid continuing to pile details in the wrong direction (treating "direction is too flat" as "visual is not good" and adjusting font size will fail after ten rounds).
Cost of Misdiagnosis: Treating "direction is too flat" as "visual is not good" and adjusting font size—will never be correct even after ten rounds—first attribute the cause, then act.
Redo vs. Patch (Three Hard Rules)
① Clear request for a redo → Must be a completely new version, no reskinning When the user says "redo / start over / redesign / give me another option":
- Must re-select the seed (Constraint 7), rewrite the Intention Map; do not reuse the previous version's code structure
- The delivery notes must include a "List of Issues from the Previous Version": what was wrong in the previous version on which points → how this version avoids them, proving it's not the same plan with a different color scheme
- Criteria: If the old and new versions share two of the three items—"layout family / animation layer count / font role"—this is a patch, not a redo, and must be redone
② "Unacceptable" without specification → Choose from three; don't ask open-ended questions When the user only says "unacceptable / not satisfied / not good," do not ask "What kind of feel do you want?" (the user can't answer). Give three options for them to point to:
- Direction is wrong (tone/feel is off) → Return to Stage ② to re-lock the seed
- Structure is wrong (the things to look at aren't visible) → Return to Stage ③ to redo information architecture and narrative
- Execution is bad (direction is right, but didn't do it in detail) → Return to Stage ⑤, adjust item by item according to
shared/taste-rules.md§1's six variables
Ask only this one question at a time (Constraint 3); once the user points, go directly to the corresponding stage.
③ Patch cap: 2 rounds max; if exceeded, force a redo If the accumulated patches for the same page are still "unacceptable" after 2 rounds → forbid a third patch; must escalate to a redo. Reason: If two rounds of patching haven't solved it, the problem lies in the direction or structure layer; continuing to tweak the visuals is just wasteful patience—"treating 'too flat' as 'not good looking' and fixing it ten times" is a recorded failure mode.
🛑 CHECKPOINT (Only Ask What Should Be Asked)
This skill defaults to not asking about direction (Constraint 1), but the following 5 nodes require a pause. Aside from these, do not seek intermediate permission—frequent interruptions are another form of dereliction.
| # | Node | Reason to Pause | What to Give the User | What NOT to Do |
|---|---|---|---|---|
| CP1 | After requirement interpretation is complete | Highest cost of misunderstanding | A one-sentence restatement: page type + target audience + tone + three parameters (or default 8/6/5) | Make the user choose between 2–3 directions (violates Constraint 1) |
| CP2 | After the highest-level direction is locked | Wrong direction means everything is wasted | A figurative description of the direction (≤3 sentences), ask "Is this direction correct" | Only report professional terms (font name/color values), which the user won't understand |
| CP3 | When the user requests a change | Changing multiple things at once = cannot attribute cause | Ask only one question at a time, confirm before asking the next (Constraint 3) | Fire off 5 questions at once |
| CP4 | Before delivery | Cannot deliver if gates are not passed | Verification results for Quality Gate 7 items + Engineering Pit Gate P1–P11 (which ones PASS, which ones skipped and why) | Verbally claim "checked" without providing results |
| CP5 | User says "it's fine / almost done" | Know when to stop | A closing sentence + what's still missing (if any) | Continue adding features, unilaterally start the next round of optimization |
Signs of Violation (Self-Check): 3 consecutive stages with no user input and no pause at CP1/CP2—means you are making decisions for the user; fall back to CP1.
Things that are NOT checkpoint items (will worsen things if asked): Which font to choose, which color value to use, how many sections to have, which animation component to use—these are your judgments, not the user's job.
User Intent Routing
| What the User Says | Starting Point | Explanation |
|---|---|---|
| "Write a page/component" (clear requirement) | ① Requirement analysis → ② Lock direction → ③ Intention Map → ④ System design → Delivery | The brief is based on the user's explicit requirements; general constraints (including Constraint 8) only act as a safety net in dimensions not specified by the user, without overriding explicit instructions (Constraint 0) |
| "Quick output" / "Use an existing theme" / "Reskin / Change theme" | Theme quick track: Read assets/themes/README.md quick reference table (light/dark → scene → accent, three steps) select 1 theme → copy its :root variables → tweak --accent per brand → deliver | Only when the user actively requests or explicitly indicates they are short on time; in this case explicitly exempt Constraint 6 (per Constraint 0: user instruction > general default). Delivery notes must state which theme was used and which variable was changed. Flagship tasks default to not using this track |
| "Help me design a landing page" (direction needs exploration) | Lock the highest-level direction directly after Stages ① and ② and continue | Do not ask the user to confirm the direction |
| "Change the style of this page" (existing code) | Start from Stage ⑤ Visual Design | Diagnosis + minimal change; for new/replacement animations, must supplement a "local Intention Map motivation table" (only covering the changed section); pure color/font/spacing changes exempt from Stage ④ Execution Gate (see references/gates.md item D) |
| "Don't know what style to use" | Directly give the highest-level direction solution after Stages ① and ② | Do not list 2–3 parallel directions for the user to choose from (Constraint 1) |
| "Do brand design" / "Make a poster" | Load the corresponding domain file | Brand → domains/brand/MODE.md; Poster → domains/poster/MODE.md |
| "Add a background video / put a video in the hero section" | Load domains/video/MODE.md | First pass §1 (is video truly necessary?) → §2 Role and volume cap → §4 Integration → §9 V1–V9 checks |
| "Create an admin panel / management console / data dashboard" | First determine the skeleton and table; don't start with the dashboard | design-patterns.md §6.4 Delivery order: skeleton → table filtering → form modal → dashboard |
| Not sure | Ask the user | Design from scratch / Modify existing / Need style suggestion |
Domain Quick Reference
Overview and selection of tools (Critique / Renovation / Design Thinking / Slides / Video Export) are in
tools/README.md.
| Domain | Trigger Words | Loading Path |
|---|---|---|
| Web Page | landing page / official site / marketing page | domains/web/distilled-playbook.md (reasoning layer, read first) + domains/web/anti-slop/MODE.md (anti-AI baseline); domains/web/integrated-rules.md (rule index → shared/) + domains/web/common-exceptions.md (exception adjudication); exact values check shared/, CSS check domains/web/design-patterns.md / shared/css-patterns.md |
| Admin / Management Console | Admin / management console / dashboard / data dashboard / CRM | domains/web/design-patterns.md §4 Widget specifications + §6 Admin interface (skeleton/four template types/density) + domains/web/integrated-rules.md §4 Token contract + shared/interaction-rules.md §7 Keyboard efficiency |
| Brand Design | Logo / Brand board / Brand design | domains/brand/MODE.md + domains/brand/brand-protocol.md + domains/brand/logo-concept-methods.md + domains/brand/visual-modes.md |
| Poster Design | Poster / poster / promotional image / display stand | domains/poster/MODE.md (first set size §1 → set proposition → select family §3 → arrange three layers §4) |
| Web Embedded Video | Background video / hero video / product demo video / scroll video | domains/video/MODE.md (first determine §1 whether video is needed → §2 role → §3 route → §4 integration → §9 delivery check) |
| Design Critique | Review / critique / revision | tools/critique.md |