Distinguish tabs, breadcrumbs, side navigation, and action menus. Verify link versus button semantics, selection and focus behavior. Product owns destinations. For a standalone link that preserves existing navigation structure, identify the semantic link guidance and any shared navigation rules that apply without requiring research into unrelated composite patterns. Read composition-specific guidance when a navigation pattern is introduced or changed.

Read the applicable `BROWSER-VALIDATION.md` sections and owner topics for target/readiness, canvas identifiers, safe state and recovery. In the shared template, these are `Target and readiness`, `Canvas host and identifiers`, `Sessions, safe state and artifacts`, and `Recovery and cleanup`. Read `Configured Playwright MCP fallback` or `Existing CLI adapter` only when that fallback is needed.

Read the applicable `REPOSITORY.md` section for the target (`Where UI lives` in the shared template), `Commands` when a command is needed, and `Constraints` for relevant permissions or lifecycle. Follow applicable owner links. If a consumer uses different headings, select the equivalent sections by owner rather than reading the entire file.

Read `PRODUCT-DESIGN.md` when expected product behavior is unresolved, when assessing scenario behavior or fidelity, or when checking forms, persistence, destructive actions or externally visible changes. A fully specified, read-only route or menu check can use the request as its expected outcome. Read `DESIGN-SYSTEM.md` for component-specific assertions, `ACCESSIBILITY.md` for accessibility checks and `RESPONSIVE-DESIGN.md` for responsive checks. No manifest or canvas-specific pack file is required. Never mix roots.

automatically. Never read drafts as active context. Follow relevant owner links and evidence anchors, preserve `proposed-default` labels and disclose conflicts. Read the complete applicable owner sections, not unrelated sections or topics. Product context owns scenarios and state policy. Browser context owns target URL, server, routes and recovery.

Do not discover canvas capabilities for source-only tasks. For rendered checks, identify the browser canvas and inspect its actual schemas before the first required operation. Reuse a schema already discovered for the same provider in this session. Rediscover only after provider reload/reconnect, a schema mismatch or an explicit request to check for changed capabilities; a timeout alone does not invalidate it. Never carry schemas across providers or sessions.

If the browser canvas or required tools are absent, report the blocker and use only the explicit configured MCP handoff in [WORKFLOW.md](./WORKFLOW.md) when applicable. Use the advertised open input and action schemas; no frozen action list overrides the runtime.

Use the browser canvas first for every agent-driven rendered check, interaction test, screenshot and visual, responsive or accessibility review. Discover its current capabilities before the first required operation, then reuse the same-provider schema in this session until it is invalidated under [the runtime contract](./SKILL.md#runtime-contract). Source-only work does not enter this workflow.

The Replica prototype canvas remains the preview and publishing surface; use the separate browser canvas for page inspection.

Read the requested outcome and establish expected results before interacting. Read product-design guidance when required by the [context requirements](./SKILL.md#required-reads-and-dependencies). Use the smallest connected flow that proves the request. Invalid-input submission, destination and reload-persistence checks apply when the requested behavior needs them and test mutations are authorized. Otherwise report those assertions untested. Do not submit real data to prove a read-only audit, or treat a disabled button alone as proof of safe persistence.

Use browser canvas capabilities and schemas as described in [SKILL.md](./SKILL.md).

Call `open_canvas` with the declared type and a session handle. Use

`invoke_canvas_action` with that same handle to address the instance.

A read timeout can be retried once after checking the declared readiness signal. Refocus the same owned panel and retry inspection only with valid required identifiers and the existing schema. Rediscover only if the runtime contract's invalidation condition applies, not because a read timed out. Do not loop or create duplicate panels.

| Candidate narrow edit to an existing prototype | [iterate](./workflows/iterate.md), then apply the root instructions' narrow-edit path |

| Behavior-preserving test-only work | Use the root instructions' task-scope guidance; do not load a prototype workflow |

The selected create or normal iteration workflow reads the shared

[authoring reference](./references/authoring.md) before implementation. A

candidate narrow edit follows the iteration workflow's classification step and,

when eligible, skips that reference and its context dependencies.

For application work, read the applicable sections of these owners and follow relevant topic links:

- `REPOSITORY.md`: `Where UI lives`, `Commands` and `Constraints`.

- `DESIGN-SYSTEM.md`: shared defaults and task-relevant sections before component, token or pattern decisions.

- `PRODUCT-DESIGN.md`: when creating or changing behavior, states, flows, messaging or product decisions.

- `BROWSER-VALIDATION.md`: before starting a preview or performing rendered validation.

- `SEED-DATA.md`: for new or changed fixtures; `RESPONSIVE-DESIGN.md`: for responsive decisions; `ACCESSIBILITY.md`: for product accessibility environments.

If a consumer uses different headings, select the equivalent sections by owner rather than reading the entire file.

Read only relevant sections and directly linked owner topics, retaining shared authority, safety rules and limitations. Use the resolution rules to determine when an owner topic applies; do not read every topic as a checklist. A missing conditional document blocks only the decision that needs it. No manifest or prototype-specific pack file is required. Never mix context roots or read drafts as active context.

Use product-design's workflow for relevant UI decisions and convert its context-backed behavior into implementation checks. Reuse unchanged decisions already established for the task rather than repeating a design pass. Select additional audit or review skills only when the user requests them or their applicable skill/repository instructions require them. Loading a skill is not evidence that its review was completed; preserve required accessibility checks and visual-approval boundaries, and report incomplete reviews as incomplete. Unrelated known gaps do not block supported work. Consequential contradictions or missing rules remain unresolved and return to the selected workflow's conditional clarification.

Reuse an established composition when it satisfies the requested behavior. Use a consumer-declared recipe, catalogue or research tool only when a specific composition or requirement remains unresolved; do not repeat lookup for general reassurance.

For a JavaScript package, resolve a public import from its package metadata: follow the applicable `exports` condition, including `types` when checking declarations, or its declared `types`, `typings` or package entry. Follow re-exports to the component definition. Package metadata and the installed version are authoritative; do not guess a component path from its name. Use the consumer's documented resolver when one exists. Other ecosystems use their declared package and API discovery mechanisms.