#86 Portability feedback: framework coupling in §3, semantic-color vs one-accent lock, and a question on the all-hard-ban framing

Title: Portability feedback: framework coupling in §3, semantic-color vs one-accent lock, and a question on the all-hard-ban framing

First, thanks for this. The v2 rewrite is genuinely strong: the brief-inference step, the honest design-system routing, and the pre-flight checklist are the parts most AI-design guides skip, and the anti-tell list is clearly written from real production pain rather than aesthetics-as-vibes.

I have been using it as a base and have three pieces of feedback offered constructively. Two are concrete and I think uncontroversial; the third is a genuine open question, not a correction.

1. §3 couples the skill to a single React/Next stack, which fights the README's "framework-agnostic" claim

The README and FAQ say the rules target design intent and work across React, Vue, and Svelte. But §3 (and parts of §5, §6) hardcode one stack as the default: RSC / "use client" isolation, Tailwind v4 @tailwindcss/postcss, next/font, motion/react, GSAP ScrollTrigger skeletons. An agent applying the skill to a Vue, Svelte, SolidStart, or vanilla project inherits instructions that do not fit, and either silently mis-applies them or has to discard a chunk of the document.

Suggestion: separate the framework-agnostic design intent (which is most of the value) from the React/Next-specific implementation notes. For example, keep §4/§9 stack-neutral and move the RSC/Tailwind/Motion specifics into a clearly labeled "React and Next reference" section that an agent uses only when the project is actually that stack. The canonical GSAP skeletons in §5.A/§5.B are great; they just want a label that says "React example, port the concept to your framework."

2. The one-accent lock (§4.2) collides with semantic status color

"Max 1 accent color" plus the Color Consistency Lock is exactly right for a marketing hero. But even in-scope surfaces (landing pages with forms, pricing pages, anything with validation or toasts) legitimately need semantic colors for error, warning, success, and info. Read literally, the lock tells the agent to suppress a red validation state because the page accent is emerald.

Suggestion: an explicit carve-out that semantic/status colors are exempt from the one-accent lock. One brand accent, plus a small reserved semantic set, is not the same failure mode as a page that randomly swaps its brand accent between sections.

3. Open question: has the all-hard-ban framing been weighed against a two-tier structure?

This is a question, not a correction. §9.G makes the em-dash ban binary on purpose, and the stated rationale (agents historically ignore "use sparingly") is sound and matches my experience. I am not arguing that specific ban should soften.

The question is about the aggregate. §9 plus §4 accumulate a large number of hard bans, several of which are aesthetic rather than objective (specific font pools, the beige/brass palette family, serif discipline, decorative dots). Two risks I have seen when a document is mostly hard bans:

Over-suppression of legitimate uses. A genuinely editorial serif brand, or a real semantic status dot, gets banned-by-default and the agent needs the override path to even reach the correct answer.
Once the agent hits one ban it must override, it can start treating the whole document as advisory, which weakens the bans that should be absolute.

Have you tested a two-tier split: a short objective core that is always hard (em-dash, div-based fake screenshots, filler identity like "Acme"/"Jane Doe", unlabeled fake metrics, contrast failures) versus the larger set framed as strong defaults with explicit override paths? Curious whether production testing showed the uniformly-hard framing outperforms that, because intuitively I would expect a small hard core plus judged defaults to both enforce better and mis-fire less. Happy to be wrong if the data says otherwise.

If any of these are useful, I am glad to open a scoped PR for #1 or #2 specifically (I would not bundle them). #3 is just for discussion. Thanks again for the work.