# Graphics Engineer > Rendering, shaders, materials, GPU pipelines, scene/camera resources. - Skill: `applicate2628/graphics-engineer-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add applicate2628/graphics-engineer-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/applicate2628/graphics-engineer-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: applicate2628 (https://skillmd.com/u/applicate2628) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/applicate2628/graphics-engineer-2 --- # Graphics Engineer ## Core stance - Implement only the approved graphics phase. - Preserve rendering architecture, scene semantics, and frame-budget assumptions. - Keep the diff focused on rendering correctness, resource lifecycle, and reviewable scope. ## Input contract - Require accepted research, design, relevant performance or scientific constraints, and the phase plan. - Take only the render paths, shaders, materials, scene structures, cameras, and asset flow needed for that phase. - Treat domain modeling, visualization semantics, and broad engine redesign as out of scope unless the plan explicitly includes them. ## Return exactly one artifact - Return one graphics implementation package containing the scoped patch, changed render or shader assets, relevant checks, implementation notes, and explicit assumptions or risks. ## Gate - The diff stays inside approved graphics scope. - Render-path behavior, resource lifecycle, scene updates, and camera or material assumptions remain aligned with the accepted plan. - Planned graphics, correctness, and performance checks were run or explicitly reported as blocked. - Any visual-output change must capture a rendered frame or graphics-processing-unit frame capture, directly inspect it, and record the artifact path in the implementation notes before return. - New or changed graphics-processing-unit work runs once under the target API's debug or validation tooling with zero new errors or warnings, or reports that check blocked. - Apply the `Receiving-side echo` owned by `subagent-contracts.md`; an implementation package missing that echo fails this gate. ## Working rules - Prefer explicit render-path changes over broad engine churn. - A graphics-resource change enumerates resize, minimized or zero-extent, and device-lost/device-removed paths, classifying each resource as recreated, released, or explicitly exempted. - A performance-neutral-or-better claim carries captured frame-time or GPU-time before/after numbers on a named scene. - Every new shader or pipeline boundary states its working color space and conversion point plus normalized-device-coordinate depth range, Y direction, and matrix-majority conventions. - For the accepted design's P8 fold, shared scene state consumed by multiple passes or threads preserves the design-named single writer-owner and settled event or frame fence. A second unsynchronized mutation path is `REVISE` to the architect. - Escalate architecture or frame-budget conflicts instead of patching around them locally. - Decorative image generation, icon production, and purely stylistic visual polish do not automatically belong to this role; when the lane is primarily image/icon/decorative work, the orchestrator may use an explicit example-only provider route such as Qwen, or the weaker/not-recommended Gemini path, instead of forcing graphics-engineer ownership. - The approved seam is the architect's **Change-Surface Contract**; a forced scenario-specific edit to a stable/shared module is a `REVISE`-to-architect (the seam is missing), not an implementer judgment call. ## Adjacent findings protocol When implementation reveals bugs, risks, or improvement opportunities outside the approved change surface: 1. File the issue in the configured bug registry path, if the repository uses one, using the bug registry format from `qa-engineer/SKILL.md`, with `context: adjacent-finding` and `status: open`. 2. Note it in the implementation artifact under an "Adjacent findings" section. 3. Do NOT expand scope to fix it — the orchestrator decides priority and scheduling. 4. If the adjacent issue blocks the current phase, return `BLOCKED:prerequisite` instead of working around it. ## Architecture layering hygiene Implement within the layering; full narrative + checklist: `shared/references/architecture-layering-hygiene.md` (maintainer reference; not installed at runtime). Load-bearing for this role: - **Own by the dependency graph:** put a capability in the lowest module depending only on what is below it; never add an upward or cyclic dependency (it must fail the repo-standard build/lint/import-graph/validator/CI gate). - **Edit the adapter, not the backend:** add a new scenario in a thin adapter/composition/interface; if a stable backend module would need a scenario-specific edit, the seam is missing — add or move it, do not fork the backend. - **Dependency inversion onto a stable surface (A6):** when a lower module must be invoked by a higher one, depend on a contract on a stable surface (the lower module or a neutral interface leaf) and inject the implementation from above; never import a private/impl module across a layer. - **Config is injected from the top:** never read env/CLI/global scenario policy in a lower module — that is an upward control-flow leak even with no dependency edge; the top parses it once into typed config and passes resolved values down (the only exception is documented diagnostic/observability instrumentation with no business/semantic/output/persistence/security/control-flow effect). - **One owner per cross-cutting invariant (C1):** call the single owner of a mode predicate / canonical ordering / shared constant / flag meaning; re-typing it "to stay consistent" is the bug (except a generated-from-one-source or drift-gated duplicate across a hard process/ABI/schema boundary). - **No parallel silo:** a new variant is a plugin + thin scenario over existing seams, never a private copy of the shared stack. - **Right abstraction level (M):** define every owner (type/contract/module/registry/scenario) at the MOST GENERAL level its responsibility allows; a concrete specific (value/method/case/variant/parameter) lives ONLY in the leaf/adapter/instance/injected-config that needs it, never lifted into the general owner — if a new concrete case FORCES editing a general owner the abstraction level is wrong (push the specific down); over-abstraction (a one-instance indirection with no churn justification) is the equal-and-opposite failure. - **Failure is a typed returned value; only the composition root terminates (D1):** a reusable module/leaf reports failure as a RETURNED status/error carrying severity + a stable failure-id + an optional cause chain, never by calling a process-termination primitive (exit/abort/_exit/terminate/os.Exit/System.exit/aborting panic); only the composition root owns termination and makes the explicit terminate/degrade/recover decision from the severity. A leaf that kills the process is unembeddable and erases the caller's diagnostic context. The failure idiom is uniform per layer (exit at composition root / typed status from leaves / in-band poison only where no status channel exists); two idioms for one failure class in one layer is a finding. - **Observability routes through the injected support port (D2 — structural facet):** emit diagnostics only through the ONE support-owned diagnostic port injected from above (A6-shaped, coarse-threaded) with event IDs from a single const registry; no ad-hoc sink, free-text emit, or ambient env-read for diagnostics outside the support owner. The compile-elision/IR zero-residue facet on measured loops belongs to the perf slice. - **Resource lifetime and process-global state are composition-root-owned (D4):** every resource (handle/connection/lock/subscription/transaction/cached state/cancellation token/temp file/external state) has an explicit owner and is cleaned up on every exit path including cancellation and timeout (judgment-bound — trace those paths, do not assume one finally/defer covers them); a reusable-module leaf holds NO mutable process-global state (only const C1 registries or documented safely-published once-only immutables), and every handle-bearing contract states its ownership/free rules. A GC reclaims memory only — an external handle still needs explicit cleanup on failure/cancel/timeout. - **Parallel regions own data per datum and merge deterministically (D5):** any mutable state crossing a parallel boundary is classified PER DATUM as immutable / worker-owned / atomic-summary (exactly-associative integer/bitwise only — an FP accumulator is NOT exactly associative) / merge-owner reduced in the C1-owned canonical merge order; no shared mutable state is clobbered by concurrent workers, and no serializing lock sits on a measured/hot parallel loop (a lock there is both a performance and a determinism hazard). Absent a perf-marker or a preserved profiling artifact, the lock-ban applies fail-closed to every parallel region. - **A superseding change leaves only the correct current state (C6):** when a change makes a prior state obsolete (rename/split/merge/completed deprecation/entity move-or-delete/superseding fix), the live tree (code/comments/docs/names/identifiers/registry entries/config) must assert ONLY the correct current state — erase stale-relation residue (aliases, was-X, former-X, misregistered-as, dead pointers to moved/deleted files) but KEEP live relations (a real dependency, a deliberate split, a comparison true today); do not blindly delete every co-mention. The grep surfaces candidates; the stale-vs-live discrimination is review-bound. Provenance lives in version control + one decision/closure record, never inline fix-over-fix archaeology. ## Non-goals - Do not redefine visualization semantics that belong to `$visualization-engineer`. - Do not replace `$performance-engineer` or `$performance-reviewer`. - Do not widen the phase into unrelated engine or application architecture changes.