How the Taste-Skill Redesign Protocol Distinguishes Redesigns from Greenfield Builds

The Redesign Protocol in Leonxlnx/taste-skill automatically classifies projects into greenfield, preserve-redesign, or overhaul-redesign modes through a strict three-stage workflow that audits existing assets before applying any changes.

The Redesign Protocol (defined in Section 11 of the main skill specification) serves as the sole decision engine within the taste-skill repository that determines whether a project should begin from a blank slate or evolve from an existing foundation. According to the source code in skills/taste-skill/SKILL.md, the protocol enforces a rigorous classification system that prevents accidental destruction of brand-critical assets during redesign work.

Three Distinct Modes in the Redesign Protocol

The protocol recognizes exactly three operational modes, each with specific constraints and baseline references:

• Greenfield — Applied when no existing site exists or when a full visual overhaul has received explicit approval. The design baseline derives entirely from the initial dial settings defined in Section 1 of the skill.

• Redesign – Preserve — Maintains existing brand identity and site structure intact. The agent audits the current site, extracts brand tokens, and applies incremental visual upgrades without altering core assets.

• Redesign – Overhaul — Applies a new visual language on top of existing content and information architecture (IA). While visual decisions behave like a greenfield build, the protocol strictly forbids rewriting content or restructuring IA.

In skills/taste-skill/SKILL.md (lines 887-891), the mode detection logic explicitly branches based on whether the existing brand and structure must remain intact versus whether the visual language requires complete replacement.

The Three-Stage Workflow

Once the Redesign Protocol initiates, it executes through three mandatory stages that ensure systematic handling of existing assets.

Stage 1: Mode Detection

The first action classifies the work into one of the three modes defined above. In skills/taste-skill/SKILL.md (lines 887-891), the mode detection step evaluates the brief to determine if the project involves:

• No existing site (greenfield)
• Existing brand preservation requirements (redesign-preserve)
• Visual-only transformation with retained content hierarchy (redesign-overhaul)

Stage 2: Audit Before Touching

After mode identification, the protocol immediately records the current state of brand colors, typography, IA, content blocks, and SEO baseline. This audit phase represents the only point where the agent may ask a clarifying question when mode classification is ambiguous: "Should this redesign preserve the existing brand, or are we starting visually from scratch?"

As specified in skills/taste-skill/SKILL.md (lines 894-902), the audit step executes before any modification occurs, ensuring all preservation constraints are documented and locked.

Stage 3: Preservation Rules and Modernisation Levers

The final stage applies mode-specific constraints:

For Preserve Redesigns: The protocol enforces preservation rules that prohibit changes to URL slugs, navigation labels, form field names, brand logos, and legal copy without explicit approval. These protections ensure SEO continuity and brand consistency.

For Overhaul Redesigns: The agent follows the same visual levers (typography, spacing, color, motion) as a greenfield build but maintains the existing content hierarchy and information architecture. The levers apply in a strict priority order, with the process stopping immediately once the brief requirements are satisfied.

This logic appears in skills/taste-skill/SKILL.md (lines 904-926), which details the interaction between preservation constraints and modernisation levers.

Decision Tree Logic for Classification

The protocol provides a rapid decision framework for agents to classify projects correctly:

• Targeted Evolution (Preserve): Use when IA, content, and SEO are solid but the visual layer requires refinement.
• Full Redesign (Overhaul): Use when structural visual debt is high but the underlying content architecture remains sound.
• Greenfield: Use when the brand itself is changing or no digital foundation exists.

This decision tree is codified in skills/taste-skill/SKILL.md (lines 920-924), providing unambiguous criteria for mode selection.

Implementation Examples

The following prompt patterns demonstrate how to trigger the appropriate path through the Redesign Protocol:

Greenfield Build Trigger:

{
  "skill": "taste-skill",
  "section": "11. REDESIGN PROTOCOL",
  "brief": "Create a brand-new marketing site for a SaaS startup. No existing site."
}

Redesign (Preserve) with Clarification:

{
  "skill": "taste-skill",
  "section": "11. REDESIGN PROTOCOL",
  "brief": "Refresh the existing e-commerce storefront while keeping the brand identity."
}

When processing the second example, the agent executes 11.A Detect the Mode, recognizes the Redesign – Preserve classification, runs the audit (11.B), enforces preservation rules (11.C), and applies modernisation levers in priority order until the brief is satisfied.

Key Source Files

Understanding the Redesign Protocol requires familiarity with these specific files in the Leonxlnx/taste-skill repository:

• skills/taste-skill/SKILL.md — Sections 11.A through 11.F contain the complete protocol specification, including mode detection algorithms, audit procedures, preservation rules, and the decision tree logic.

• skills/redesign-skill/SKILL.md — Provides the concrete design audit checklist utilized during the audit before touching phase of all redesign projects.

• CHANGELOG.md — Documents the protocol's introduction in v2 (experimental), explaining the architectural rationale for separating greenfield and redesign workflows.

• skills/taste-skill-v1/SKILL.md — The legacy skill version shows the previous approach, highlighting why the new protocol adds explicit mode detection and stricter preservation constraints.

Summary

• The Redesign Protocol is the exclusive mechanism in taste-skill for distinguishing greenfield builds from redesign projects.
• Mode detection classifies work as Greenfield, Redesign-Preserve, or Redesign-Overhaul before any design action occurs.
• An audit-before-touching requirement ensures existing brand tokens, IA, and SEO baselines are recorded and protected.
• Preservation rules strictly guard URL slugs, navigation labels, and legal copy in preserve mode, while overhaul mode permits visual liberty but locks content hierarchy.
• The protocol references skills/taste-skill/SKILL.md (lines 887-926) for all classification logic and constraint enforcement.

Frequently Asked Questions

What triggers the Redesign Protocol to classify a project as a greenfield build?

The protocol assigns greenfield classification when the brief indicates no existing site presence or when the project involves a full visual overhaul that has received explicit stakeholder approval. In this mode, the agent uses the initial dial settings from Section 1 as the sole design baseline, ignoring any existing brand assets or site structure.

How does the Redesign Protocol protect existing SEO during a redesign?

During Redesign – Preserve operations, the protocol enforces strict preservation rules that prohibit changes to URL slugs, navigation labels, and form field names without explicit approval. These constraints, detailed in skills/taste-skill/SKILL.md (lines 904-926), ensure that link equity and crawlability remain intact while visual upgrades proceed.

What is the difference between Redesign-Preserve and Redesign-Overhaul modes?

Redesign-Preserve maintains all existing brand tokens and applies only incremental visual upgrades, whereas Redesign-Overhaul permits a completely new visual language but strictly preserves the existing content hierarchy and information architecture. Overhaul mode behaves like a greenfield build for visual decisions but never rewrites content or restructures IA.

Where does the protocol ask for clarification if the redesign mode is unclear?

The audit before touching stage (Section 11.B) represents the sole point in the workflow where the agent may ask a clarifying question. If mode detection yields ambiguous results, the agent queries: "Should this redesign preserve the existing brand, or are we starting visually from scratch?" This ensures correct classification before any assets are modified.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}