Web MCP Design

Instrumented Monochrome Router

This skill applies the source-independent Instrumented Monochrome language. The package root is the active skill folder: SKILL.md sits beside DESIGN.md. “Web MCP” affects naming only; it does not introduce browser, protocol, server, network, developer-tool, or AI motifs.

Procedure

1. Read DESIGN.md first before creating, reviewing, or repairing any output.
2. Identify the real deliverable, content, platform, state, and consequence. Do not derive a product model from the package name.
3. Load only the support files needed for the current task.
4. Apply documented foundations, semantic tokens, components, patterns, accessibility, applications, and prompt rules.
5. Use proofs, sources, and handoff only for validation, disputed drift, provenance, readiness, rights, or evidence questions.
6. Inspect rendered output in applicable widths and modes. Structural checks alone do not prove typography, crop, hierarchy, texture, interaction, or accessibility.
7. Reject invented components, raw values where semantic tokens exist, unsupported states, fake data, and prompt details outside DESIGN.md.

Support Files

• DESIGN.md: always read first; it is the full source-free build manual and review contract.
• foundations/: load the relevant file for palette, typography, space, motion, surface, interaction, icons, imagery, voice, or brand-expression decisions.
• tokens/: load for implementation values, modes, platform output, transforms, or drift repair; components consume semantic/component tokens, not primitives.
• components/: load the relevant action, form, navigation, sequence, feedback, content/data, or product-neutral domain-shell contract before generating UI.
• patterns/: load when choosing state behavior, perceptual recognition, taxonomy, relationships, or platform/domain adaptation.
• accessibility/: load for contrast/CVD, keyboard/focus/motion, target, zoom/reflow, and alternative requirements.
• applications/application-rules.md: load when selecting a composition for identity, editorial, interface, data, progress, campaign, image, presentation, or print work.
• outputs/prompt-pack.md: load for generated-image or asset prompting; outputs/ai-readiness-audit.md for AI-generation controls; outputs/documentation-as-context.md for retrieval/maintenance.
• sources/: load only to examine source inventory, custody, rights, or extraction modes.
• proofs/: load only for evidence mapping, ontology coverage, validation, caveats, or disputed fidelity.
• handoff/: load for readiness, provenance, residual risks, and release boundaries.

Guardrails

• DESIGN.md is the reconstruction contract. Proof files validate traceability and gaps; they are not creation guidance.
• Do not reopen or require original references for ordinary creation. Ask for a new extraction only when the user requests one or materially changes the corpus.
• Do not copy reference assets, marks, lettering, copy, or compositions into production output.
• Use JetBrains Mono for every designed text role. Preserve the neutral palette, quiet/signal density, one-rupture limit, meaningful path/node grammar, matte surface, causal motion, and factual state language.
• Do not infer product entities, states, screens, or metaphors from “Web MCP.” Use the name only in a real naming position.
• Do not invent components, raw values, unsupported states, fake measurements, or prompt details outside the package.
• Preserve accessibility obligations and mark material product/content gaps instead of guessing.

Output Contract

Return the created or reviewed artifact, the Instrumented Monochrome rules applied, support files consulted, rendered or structural validation performed, unresolved product/content gaps, and residual risks. Distinguish what was observed from what was merely specified.

Constraints Reminder

Before responding, verify:

1. DESIGN.md was read first and treated as the primary design-language contract.
2. Support files were loaded only when needed for the task.
3. Components, tokens, patterns, prompts, and accessibility rules were not invented outside the package.
4. Proof, provenance, and rights limits stayed in validation/support files; production guidance stayed source-free.
5. Validation evidence is reported only when making readiness or proof claims.