Awwwards Section Loop

Awwwards Section Loop — build section by section, verify each, lock it

Building a whole page in one pass loses: attention splits across eight sections, an early mistake silently propagates into every later one, and feedback arrives only when everything is finished — too late to trace the drift to the decision that caused it. The section loop fixes all three: one section gets full attention; each section is verified and locked before the next starts; drift is caught where it began.

The tools to run this loop already exist. This skill is the order to run them in, and the judgment calls the tool outputs don't make for you.

The loop

Copy code
PLAN          analyze_page_structure(reference)   → band map = section plan
FOR EACH      capture_component(section selector) → section pack (recipe)
              build that section                  → in your output, fully
              verify_build(yours, reference)      → read THAT band's score
              iterate until the band passes       → then LOCK it
NEXT SECTION  (do not touch locked sections again)
FINALLY       whole-page verify_build             → coherence pass

Step 0 — Plan from the band map

analyze_stack first (one call): the site's framework, CSS framework, and marker libs. A Webflow or WordPress source means conventions you re-skin; a Next source means you can mirror component shapes. Then analyze_page_structure returns ordered bands with top, height, bg, and a text sniff. Treat the band list as the build order:

• Small count, sane heights (≤ ~3,000 px each) → bands map 1:1 to build sections.
• One giant band (5,000 px+) → the band collapsed multiple real sections (repeated <section class="…"> siblings do this). Do not build it as one giant component. Drop to the raw page HTML and pick explicit selectors for the real sections (.section, [role=…], header, footer, or #ids), one per logical section. Real-capture finding: a 20,631 px band held an entire main content area; the four real sections inside it captured fine by class.
• Shared canvas / WebGL hero spanning many bands → the page does not slice. Treat that canvas region as ONE unit: capture_pose_3d for the camera path, rebuild as a single component, then loop normally for everything after it. Slicing a shared-canvas page into per-section captures produces sections that each reference a canvas none of them own.

Step 1 — Capture per section

capture_component(selector) per section, in band order. Selector discipline (learned from real captures, in priority order):

1. Section class or id from the band/HTML (.process, .pricing, .footer) — most reliable.
2. role attributes ([role="banner"], [role="contentinfo"]).
3. Tag names (header, footer, nav) — last resort: real sites frequently have no <header> element at all (a real capture of a Webflow site returned selector not found: header while nav and .footer worked).

If a selector misses, try the alternatives before shrinking the plan. A failed capture with selector not found is a selector problem, not a missing section.

Step 2 — Build one section, completely

Build the section against its pack: layout from the pack's geometry, tokens (fonts/colors/spacing) from its captured computed styles, motion from the census (analyze_scroll_map + analyze_hover_census scoped to the section, per awwwards-motion-study). Content is yours — structure, motion, and tokens are what you're matching.

Finish it. A half-built section pollutes the next verify. No placeholder blocks left "for later" inside a section you're about to lock.

Step 3 — Verify the band, not the page

verify_build compares your in-progress build against the reference and scores per band. After building section N, run it and read band N's score — ignore later bands (not built yet → noisy) and earlier bands (locked).

Iterate on section N until its band passes (typically score ≥ the target you set up front — B+ per the audit doctrine, or "band beat last iteration"). Then stop touching it.

The evidence lines carry the port's instrumented checks: perf: fps=… dropped=… longTasks=… (measured in a real browser) and anti-patterns: N (worst: …). If perf shows dropped frames, the section's animation weight is the usual cause — transitioning filter: blur, infinite loops, or animating layout properties. Fix the prop, not the score.

Why the score gate matters: section-by-section without a verify gate is just chunked guessing. The band score is the loop's contract — it converts "looks close" into a number that either passes or names what's off (geometry, tokens, motion).

Step 4 — Lock before next

Locking = this section's markup/styles/motion are frozen. If a later section reveals a problem that truly requires changing a locked section, make the change as an explicit re-open: fix, re-verify that band, re-lock. Never silently fudge a locked section while building another.

Step 5 — Final coherence pass

After the last section locks: whole-page verify_build, read every band. Also run analyze_page_structure once with compare: "mobile": mobileBands + diff (bandsAdded, bandsRemoved, reordered, heightDelta) name the sections that only exist at 390×844 or changed order — a desktop-only rebuild shows up here before the mobile smoke. You're now checking cross-section things the per-section loop can't see: shared spacing rhythm, consistent header behavior, scroll continuity, one easing family across sections (or an intentional break). Fix coherence issues at the page level (tokens, shared CSS), not by re-opening sections unless a band regressed.

Step 6 — Convert only if the user asks

The single-file rebuild is a valid handoff. When the user asks for a project (or picks a framework), convert: locked sections are exactly what build_project --target vite|astro|next needs — the band split becomes components. If they also want authored motion, add --authored --motion census.json and author per section (see motion-authoring), keeping the same lock discipline: author section N, verify its band, lock, next. Whole-page desktop + 390 mobile parity last.

Failure modes this skill prevents

Companion tools

• awwwards-motion-study — the per-section motion recipe (record → inventory → build → re-record).
• verify_build — the per-band score gate (steps 3 and 5); evidence now includes measured perf (fps, dropped frames, long tasks) and anti-pattern counts from instrumented live probes. Runs a real browser — expect ~2 min per call.
• capture_pose_3d — camera path for shared-canvas units (step 0).
• analyze_scroll_map / analyze_hover_census - per-section motion census to build from. analyze_scroll_map rows now carry keyframe value-pairs and a site-level gsapTriggers list (numeric pixel start/end, live progress, tween vars) — build from measured values, not invented ones. Hover samples include animations captured DURING the hover (activeAnims), which is how event-driven tweens get seen.
• build_gsap_stub - turns the captured censuses into a runnable GSAP+ScrollTrigger stub (durations, easings, scrub/pin, camera from capture_pose_3d, reduced-motion guard) — step 2's motion wiring, generated.
• build_project — build → convert → own the motion: --target vite|astro|next gives native structure (section components, shell, split CSS, ordered libs); --authored --motion census.json drops site logic and emits motion.manifest.json + per-section/page motion hooks to author against (pair with motion-authoring); always re-verify after conversion.
• analyze_bundle - mechanism recovery (step 2 escape hatch): when a section's effect can't be explained from the census evidence, grep the section site's script bundle for mechanism keywords; the censuses say WHAT animates, the bundle says HOW.