--- a/skills/wiki-component/SKILL.md
+++ b/skills/wiki-component/SKILL.md
@@ -75,6 +75,102 @@
 Register the hero in page.json without duplicating it in the README; open the
 authenticated live page in a work pane, preserve the editor and foreground, and
 verify that the published model and hero have the same correct pose.
+
+## Component creation acceptance contract
+
+Use these Adom presentation defaults for every component, including reused support
+parts; honor a user's explicit overrides and record the chosen values. A polished
+main sensor does not excuse incomplete buffers, supervisors, passives or connectors.
+Keep project-specific implementation and session evidence in the existing project.
+
+- Reuse an exact-MPN component wiki page when one exists; otherwise create one.
+  Prefer validated Adom Basic Parts already on hand, then Mouser for new sourcing
+  under the current InstaPCB guidance. Read `adom-basic-parts`, `instapcb` and
+  `adom-parts-search`; check current stock and provenance, not historical snapshots.
+  Basic Parts' validated manufacturer STEP assets are the preferred reusable source;
+  verify the actual record rather than treating every available model as validated.
+- Retain manufacturer datasheets and original manufacturer STEP files with source
+  links, revision and hashes. Distributor access does not itself establish model
+  authorship. Use the existing chip-fetcher/site skills and `adom-parts-search`.
+  If browser access is required, use one Pup window with multiple tabs. Existing
+  profile logins, approved credential import, Google sign-in and website email codes
+  through `adom-google` are possible authorized access paths; never log secrets or
+  bypass a permission rejection. Preserve provenance after browser downloads.
+- Keep canonical symbol, footprint, pin-pad map and model bindings together in
+  `adom-lbr`. Every IC symbol has intelligent functional pin groups and a central
+  outline of its actual approved chip geometry, including small support ICs. Keep
+  pin names, numbers and electrical types readable and preserve native vector art
+  through exports. Conventional passive symbols must remain electrically recognizable.
+- In each consuming schematic, add ordinary text explaining each chip instance's
+  purpose, selection rationale, direction/power domain and unresolved assumptions.
+  These board-specific explanations belong on the schematic and project page;
+  they do not replace a reusable component description. Verify the comments and
+  central illustration in the real webview and native imports, not only in a file.
+
+### Readable 3D reference artwork
+
+The physical chip remains sourced from the manufacturer. Add reference artwork as
+separate named, nonphysical layers aligned to the verified footprint seating plane
+in Adom Z-up. Preserve units, pin-1 orientation, pad rotations and corner radii.
+Do not confuse copper boundaries with solder-mask or paste apertures.
+
+| Artwork | Required presentation |
+|---|---|
+| Copper-pad boundaries | Teal dashed outlines, 50% transparent (material alpha 0.50). |
+| Silkscreen contours | 70% transparent (material alpha 0.30). |
+| Pad labels | Actual signal/pin names, 50% transparent (alpha 0.50), placed legibly outside the body. |
+| Package MPN | Exact manufacturer part number on the top surface, readable when zoomed in, using `adom-chip-laser`. |
+
+Resolve signal names through the canonical pin-to-pad mapping and datasheet; never
+substitute project net names or guess from pad ordering. Preserve active-low notation
+and multi-function names. Pad numbers remain in the electrical data and pin-map
+inspector; they are not the default 3D label. Omit uninstantiated `REF**` placeholders.
+Unsupported footprint geometry or ambiguous mapping must be reported explicitly.
+
+Read the `adom-chip-laser` skill before etching. If it is missing from the installed
+catalog, find `adom/adom-chip-laser` on the wiki and read its SKILL.md. Use its actual
+STEP-layer workflow for a derived marked STEP and convert that to GLB as appropriate.
+Preserve the untouched manufacturer source separately. Mark the added MPN as a
+virtual identification aid, not a claim about the manufacturer's real marking.
+Do not alter optical windows, leads, seating surfaces or pin-1 evidence. Check the
+etch is on the actual top and remains legible in the published viewer; a successful
+service response is insufficient. Keep lights' off/lit/brightness states and motion
+pivots/joints meaningful where the component participates in a digital twin.
+
+Do not show internal CAD names such as `BODY-SON` as hover tooltips. Preserve useful
+selection, geometry names and inspection capabilities; suppress low-value tooltip
+presentation through the viewer's supported API. The Babylon viewer's `onMeshHover`
+callback can return null to suppress a label. A temporary injected CSS rule is only
+a current-window workaround, not a durable published fix. Report a missing wiki
+integration option on the owning app's existing issue tracker after checking duplicates.
+
+### Verify the visible delivery
+
+Inspect top, oblique and underside views for body presence, seating, pin 1, exact MPN,
+signal labels, dashed boundaries, material alpha and alignment. Verify imported
+materials and actual pixels: a manifest or successful load does not prove appearance.
+Reopen/reload to check persistent settings. Any native KiCad/Fusion/Altium model
+view missing the chip fails component parity even if the footprint or board exists.
+Report bridge omissions on the owning bridge project and request actionable AI hints.
+
+Show the authenticated component page and library in a Hydrogen work pane while
+keeping VS Code visible. Follow `adom-webview-wiki-review` for authentication; keep
+native applications in the background using supported targeted capture controls.
+Compare the same revision in KiCad, Fusion and Altium. Distinguish a verified export,
+a successful import and visually validated parity. Do not claim parity from one alone.
+
+When recording, capture real edits and purposeful inspections: scroll to relevant
+specifications, follow pin groups, zoom into the MPN/pin-1 corner and orbit to pads.
+Wait for model loading and camera-fit animation to settle before inspection shots.
+Avoid arbitrary repetitive motion and interference with the human's camera. Keep
+per-clip artifact revision, actions, useful time ranges, failure/repair labels and
+separate engineering/highlight eligibility so later edits can tell either story.
+
+Keep these conventions in this existing shared skill. Use `wiki-bloat` to decide
+scope; component pages, one project umbrella and independently reusable molecules
+are appropriate, while each artifact or lesson does not need another wiki repo.
+Source submission, merged release, installed skill and an existing AI thread's
+loaded guidance are separate states. Verify and report each honestly.
 
 `component` is a first-class **wiki page type** (alongside `app` and `skill`, see
 **wiki-api**). Structurally a component is usually the **Page** archetype; chip