ui-iteration
Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).
- License 许可
- MIT
- 最近更新
- 2026-08-16
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- ui-iteration
- description
- Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).
03 SKILL.md 正文
<!-- platform-assumptions: markdown skill guidance for VS Code custom agents in Agent Orchestra; assumes the calling agent owns browser-tool applicability, invocation boundaries, and implementation handoff decisions. --> <!-- markdownlint-disable-file MD041 MD003 -->
UI Iteration
Reusable methodology for screenshot-based UI polish.
When to Use
- When a page or component feels visually off but needs targeted refinement rather than redesign
- When repeated screenshot comparison is the fastest way to validate polish work
- When the work is mostly spacing, hierarchy, theme coherence, or interaction feedback
- When Tailwind or presentation-layer tweaks should be applied in bounded iterations
Purpose
Improve the UI through short, measurable polish loops. Each pass should identify a small set of visual issues, apply focused changes, and confirm that the after state is visibly better than the before state.
Iterative Polish Workflow
- Capture a baseline screenshot of the target page or component state.
- Assess the current UI against the evaluation criteria below.
- Select 3-5 concrete improvements for the pass.
- Implement the smallest set of presentation changes that address those issues.
- Capture a follow-up screenshot.
- Compare before and after, and record whether the pass produced measurable improvement.
- Repeat until the planned iteration count is complete or additional changes stop producing clear gains.
Screenshot Requirements
- Use a representative populated state rather than empty placeholders
- Prefer standard desktop browser width unless the task is explicitly mobile-first
- Keep captures focused on the target surface, not the full desktop
- Use programmatic screenshots when browser tools are available; otherwise follow the repo's fallback process
Screenshot output: save screenshots to .tmp/ per skills/terminal-hygiene/SKILL.md ## Scratch & Temp-File Hygiene.
Aesthetic Evaluation Criteria
Generic UI Principles
| Principle | What to Check |
|---|---|
| Readability | Text contrast, font sizes, line height |
| Visual Hierarchy | Clear focal points and emphasis |
| Spacing | Consistent padding, margins, and breathing room |
| Alignment | Grid alignment and edge consistency |
| Consistency | Similar elements styled similarly |
| Feedback | Hover, active, loading, and empty-state clarity |
Product-Facing Checks
| Criterion | What Good Looks Like |
|---|---|
| Information Clarity | Primary data and actions are obvious at a glance |
| Theme Coherence | Colors, typography, and surfaces feel intentionally related |
| Data Legibility | Statuses, values, and labels remain easy to parse |
| Motion Restraint | Motion supports comprehension rather than distracting |
| Pattern Benchmark | New surfaces fit the product's established visual language |
Tailwind And UI Polish Heuristics
- Prefer design tokens and semantic utilities over arbitrary values
- Use spacing scales consistently before introducing custom exceptions
- Improve hierarchy with contrast, weight, grouping, and whitespace before adding more chrome
- Fix misalignment at the container or layout level before patching individual elements
- Keep motion subtle and purposeful
- Prefer utility composition over custom CSS when the design system already supports the need
Iteration Parameters
| Parameter | Default | Typical Override Example |
|---|---|---|
| Iterations | 5 | Polish Dashboard 3 times |
| Scope | Full page | Polish just the SummaryCard component |
| Focus | All | Focus on spacing and alignment |
Output Formats
Per-Iteration Analysis
## Iteration N/5 Analysis
**Target**: [Page/Component]
**Assessment**:
- ✅ [What is working]
- ⚠️ [Minor issues]
- ❌ [Significant issues]
**Proposed Improvements**:
1. [Specific change] - [Rationale]
2. [Specific change] - [Rationale]
3. [Specific change] - [Rationale]
**Files to Modify**:
- `src/...`
Final Session Summary
## UI Polish Complete
**Target**: [Page/Component]
**Iterations**: N/N
**Changes Made**:
1. [Change] (Iteration 1)
2. [Change] (Iteration 2)
**Before/After Summary**:
- Spacing: [Before] -> [After]
- Hierarchy: [Before] -> [After]
- Feedback: [Before] -> [After]
**Remaining Suggestions**:
- [Optional future polish]
Related Guidance
- Load
frontend-designwhen the polish work needs a stronger visual point of view - Use browser-tool instructions from the current repo for navigation, startup, and cleanup details
Gotchas
| Trigger | Gotcha | Fix |
|---|---|---|
| The before and after screenshots look alike | The pass changed code without producing visible improvement | Reduce scope and choose 3-5 changes with clearer visual impact |
| Trigger | Gotcha | Fix |
|---|---|---|
| Tailwind tweaks pile up element by element | The layout becomes inconsistent and harder to maintain | Fix spacing and alignment at the layout or container level first |
04 同仓库更多 Skills
webapp-testing
Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).
verification-before-completion
Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any "I'm finished" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).
validation-methodology
Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).
upstream-onboarding
Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.
ui-testing
Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).
tracking-format
Tracking-file frontmatter and coordination format guidance. Use when creating or reviewing local tracking files and related handoff conventions. DO NOT USE FOR: session-memory plan authoring rules outside the documented references here.