Design Feedback to Rule

Convert one feedback set into an implementation-ready decision contract. Preserve the reviewer's intent without inventing a design solution.

Enforce the boundary

• Work read-only.
• Inspect only the artifacts, screenshots, annotations, files, and states within the user's scope.
• Do not edit or create project files, design files, code, copy, tokens, prototypes, or assets.
• Do not apply the feedback, propose visual directions, or choose an implementation technique.
• Stop after delivering rules, preserved elements, change boundaries, open decisions, and a validation checklist.
• Treat a solution named in the feedback as a suggested tactic until the intended outcome is clear.
• Return a handoff boundary when the same request also asks for implementation.

Read the evidence

1. Identify the exact feedback source and preserve its meaning.
2. Identify the referenced artifact, component, route, state, viewport, and audience.
3. Inspect available source material before interpreting the comment.
4. Separate each item into:
   • direct observation;
   • stated impact or concern;
   • desired outcome;
   • suggested tactic;
   • missing decision.
5. Label every inference as an inference. Never present an assumption as reviewer intent.

Normalize the feedback

Rewrite each concern as an outcome that can be observed or tested. Replace adjectives with variables such as:

• information density and scan order;
• hierarchy and emphasis;
• spacing and alignment;
• contrast and legibility;
• image crop and visual continuity;
• motion sequence, duration, and state continuity;
• control affordance and interaction feedback;
• brand token or component compliance.

Read feedback-rule-schema.md when the feedback contains vague adjectives, multiple comments, contradictions, or preserved states.

Keep the rule at the outcome level. Exclude layout inventions, styling prescriptions, component selections, and code instructions unless the reviewer explicitly made them mandatory.

Bound the change

Record four separate sets:

• Preserve: elements, content, states, behaviors, or qualities that must remain.
• Allowed to change: the smallest surface that may change to satisfy the rule.
• Excluded: adjacent surfaces and behaviors that remain outside this feedback.
• Open decisions: ambiguities that can materially change the result.

Do not silently expand the scope. Ask at most one high-leverage question when an unresolved ambiguity changes the rule or boundary. If no answer is available, state the assumption and keep the affected decision open.

Resolve contradictions by preserving both source statements, explaining the conflict, and identifying the decision owner. Do not choose a side without evidence or authority.

Write testable rules

Write one rule per concern. Include:

• rule ID;
• source feedback;
• observed issue and context;
• desired outcome;
• observable rule;
• preserve, allowed, and excluded sets;
• evidence or rationale;
• confidence and open decision;
• validation checks.

Use qualitative checks when the source gives no numeric threshold. Do not invent measurements and present them as requirements. Make every check answerable through inspection, interaction, comparison, or measurement.

Return the contract

Return sections in this order:

1. Feedback scope — source, artifact, state, viewport, and assumptions.
2. Normalized intent — concise outcome without implementation language.
3. Rule table — one row per atomic concern.
4. Change boundary — preserve, allowed, excluded, and open decisions.
5. Validation checklist — observable checks tied to rule IDs.
6. Handoff boundary — state that no design or implementation change was made.