Address review: soften palette guidance, drop redundant local prompt rules

- block-content: "prefer palette over hex" instead of "never hardcode hex";
  custom hex stays available for deliberate one-offs
- system-prompt: remove the local palette additions now that the loaded
  block-content/visual-design skills carry the guidance; keep the remote
  content bullet since the remote path loads neither skill

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: youknowriad

apps/cli/ai/skills/block-content/SKILL.md

@@ -18,7 +18,7 @@ Use this skill before writing or editing page content, post content, templates,
 - No custom class names on inner DOM elements. Put custom classes only on the outermost block wrapper via the block `className` attribute.
 - Style buttons via `.wp-element-button` — the inner element WordPress applies the button's padding, background, and border to (shared by the button block and buttons from other blocks). A custom class on a button block sits on the `.wp-block-button` wrapper, so descend to `.your-class .wp-element-button`; never style the wrapper directly, or its padding stacks on top of the default and the button doubles in size.
 - No inline `style` attributes or block `style` attributes for styling. Use `className` plus the theme's `style.css`.
-- Color from the theme palette, not hardcoded hex. Apply block colors with palette **slug** attributes — `{"backgroundColor":"accent-1","textColor":"base"}` — and in `style.css` reference palette colors as `var(--wp--preset--color--<slug>)`. Never write raw hex color values (e.g. `#1a1a1a`) into block markup or section CSS. Discover the available slugs from the active theme's `theme.json` `settings.color.palette` (for a theme you are building, the palette you defined there). If a section needs a color the palette lacks, add an entry to the `theme.json` palette and reference its new slug — do not inline a hex value. This keeps sections in sync with Global Styles, theme switching, and light/dark variations. Custom hex is a deliberate exception, not the default.
+- Prefer theme palette colors over hardcoded hex. Apply block colors with palette **slug** attributes — `{"backgroundColor":"accent-1","textColor":"base"}` — and in `style.css` reference palette colors as `var(--wp--preset--color--<slug>)`. Discover the available slugs from the active theme's `theme.json` `settings.color.palette` (for a theme you are building, the palette you defined there); when you want a color the palette lacks, prefer adding it to the palette and referencing its slug. Keeping colors on the palette keeps sections in sync with Global Styles, theme switching, and light/dark variations. A raw hex value is fine for a deliberate one-off, but it should be the exception, not the default.
 - Use `core/spacer` for empty spacing elements, not empty `core/group` blocks.
 - No emojis anywhere in generated content.
 

apps/cli/ai/system-prompt.ts

@@ -116,7 +116,7 @@ For any request that involves a WordPress site, you MUST first determine which s
 Then continue with:
 
 1. **Get site details**: Use site_info to get the site path, URL, and credentials.
-2. **Plan the design**: Before writing any code, review the site spec (from the \`site-spec\` skill) and load the \`visual-design\` skill to plan the visual direction: layout, colors, typography, and spacing. Decide the color palette up front, define it in \`theme.json\`, and drive every section from those palette colors by slug rather than hardcoding hex (reuse the existing palette when the site already has a theme).
+2. **Plan the design**: Before writing any code, review the site spec (from the \`site-spec\` skill) and load the \`visual-design\` skill to plan the visual direction: layout, colors, typography, and spacing.
 3. **Write theme/plugin files**: For a brand new theme, call \`scaffold_theme\` first — it drops an unopinionated block-theme baseline (style.css with only the theme header, theme.json with appearanceTools only, functions.php with frontend + editor style enqueue, default templates and parts, empty assets/fonts and patterns dirs) and activates it by default. Then use Write and Edit to fill the scaffold (one part/template/file per turn). For plugins or for editing an existing theme, use Write and Edit directly under the site's wp-content/themes/ or wp-content/plugins/ directory.
 4. **Configure WordPress**: Use wp_cli to activate themes, install plugins, manage options, create posts and pages, edit and import content. The site must be running. Note: post content passed via \`wp post create\` or \`wp post update --post_content=...\` need to be pre-validated for editability, follow the \`block-content\` skill, and validated/fixed with validate_blocks. The \`wp_cli\` tool takes literal arguments, not shell commands: never use shell substitution or shell syntax such as \`$(cat file)\`, backticks, pipes, redirection, environment variables, or host temp-file paths to provide post content. Pass the literal content directly in \`--post_content=...\`, make \`--post_content\` the final argument in the command, and Studio will rewrite large content to a virtual temp file automatically.
 5. **Check and fix block validity**: Run validate_blocks on block content, with filePath whenever the content lives in a file. It first runs a static core/html policy check: if that reports invalid core/html blocks, editor validation is skipped — rewrite only those blocks as editable core or plugin blocks and call validate_blocks again. Once the policy passes it validates in the live editor. If it says an auto-fix was applied, the file already contains the fixed block content; do not manually replace markup or call validation again unless you intentionally change block markup afterward. Use the diff only to inspect class/nesting changes and update CSS selectors if needed. For inline content, use any returned fixed block content exactly as the replacement content.
@@ -161,7 +161,6 @@ ${ studioPresentToolBullet }${ automaticArtifactSection }
 ## General rules
 
 - Design quality and visual ambition are not in conflict with using core blocks. Custom CSS targeting block classNames can achieve any visual design. The block structure is for editability; the CSS is for aesthetics.
-- Color sections from the theme's palette by default. Define colors once in \`theme.json\` (\`settings.color.palette\`) and reference them by slug — block color attributes like \`{"backgroundColor":"accent-1","textColor":"base"}\` or \`var(--wp--preset--color--<slug>)\` in CSS. Do NOT hardcode hex color values in block markup or section CSS. When working on a site that already has an active theme, reuse its existing palette; add a new palette entry only when a needed color is genuinely missing, then reference its slug. (See the \`block-content\` skill.)
 - Do NOT modify WordPress core files. Only work within wp-content/.
 - Before running wp_cli, ensure the site is running (site_start if needed).
 - When building themes, always build block themes (NO CLASSIC THEMES).