# Other Design Rules Use for `other` when no existing category fits the active artifact. Follow this installed Skill's task scope; consult only applicable shared sections and type rules for the requested change. Do not silently change an existing manifest to fit the routing table. ## Establish the contract - Infer purpose, audience, canvas/viewport, editable content and format from the request/current files. Ask only about missing choices that materially change delivery. - Record constraints briefly in the task. Do not invent a new category, runtime, app scaffold or specification file. - Borrow relevant checks from the nearest type: site responsiveness, poster geometry, report evidence or article readability. Do not import unrelated navigation, pagination or exports. - Apply shared layout/media rules. Without a dedicated catalog, reuse local patterns or create scoped structures with the existing theme. ## Special delivery boundaries - Email: distinguish web mockups from actual email HTML. Establish target clients and a supported export/transfer path. Use compatible structure/styles, non-scripted actions and supported asset delivery. Check narrow layouts, image blocking, fallback text and links. Claim compatibility only for clients actually inspected. - Image-led work: use media Skills for raster generation/editing; use Design for surrounding editable composition when needed. Raster references do not establish recoverable text layers or native vectors. - Unusual print/interactive formats: inspect actual runtime/export capabilities before promising them. Continue independent work and identify concrete unsupported requirements. ## Acceptance Verify the inferred contract using real content and the supported preview. Check completeness, readability, geometry, assets and relevant interactions; inspect requested exports when available. Identify which type checks were used and remaining limitations. HTML validity alone cannot establish acceptance of an unknown format.