designstudyo-clone-executor

DesignStudyo Clone Executor

Code-writing discipline for implementing one work item inside a DesignStudyo exact-clone package. This skill governs HOW you write the code. It does not replace designstudyo-exact-clone, which governs whether the result actually passes — always run its verification gates (visual score, coverage, runtime checks) on real measurements, not on self-reported confidence.

Why this exists

Exact-clone output silently rots in one specific way: the model gets most of a section right, then reaches for a shortcut — // rest of styles unchanged, /* ...same as above... */, an early truncated <script> block — because the full file feels repetitive to write out again. In a clone, "repetitive" is the point. A truncated file doesn't fail loudly; it ships, looks fine in a partial diff, and then breaks the build or drops half the DOM the moment someone actually loads the page. Treat every code block as the artifact a build system will consume verbatim, not as a chat reply a human will patch up by hand.

Before writing anything

1. Confirm you're inside a real export package with the expected source directories (birebir-klon/, tasarım analizi/, loopkit/, or whatever the actual delivered clone ZIP calls them — check clone-manifest.json / work-items.json if present rather than assuming names).
2. Read every source file for the work item you're implementing — DOM markup, the CSS that targets it, and any JS that touches it (GSAP timelines, ScrollTrigger configs, Lenis params, custom keyframes). Don't sample; a missed @media block or a missed .stagger() call is exactly the kind of thing that produces a "looks close but isn't" result.

While writing

• Match structure exactly: element order, tag names, class names, IDs, data-* attributes. These are load-bearing — selectors, animation targets, and JS hooks in the original all key off them.

• Match motion parameters exactly: duration, easing, stagger offset, ScrollTrigger start/end/scrub values, Lenis smoothing config. A close-enough easing curve reads as visibly wrong on a scroll-driven site even when every static property matches.

• Never truncate a code block you're asked to output. No // omitted for brevity, /* rest unchanged */, ... continues, or any variant. If a file is large, that's fine — write all of it.

  Example — banned vs. required:

  /* BANNED */
  .hero { color: #111; }
  /* rest of styles unchanged */
  

  /* REQUIRED — every rule written out, even if it repeats the source verbatim */
  .hero { color: #111; }
  .hero__title { font-size: 3rem; }
  .hero__cta { padding: 12px 24px; }
  

  If a single file genuinely cannot fit in one response, don't just trail off — make the split unambiguous so whoever reassembles it (a human, or you in the next turn) knows exactly what's still missing:

  --- PART 1/3: styles/hero.css ---
  <full, uncut content of this part>
  --- PART 2/3: styles/hero.css (continued) ---
  <full, uncut content of this part>
  --- PART 3/3: styles/hero.css (final part) ---
  <full, uncut content of this part>
  

  Each part must itself be complete and uncut — the split happens only at part boundaries, never mid-rule or mid-statement. Only the final part carries "(final part)"; if you stop before reaching it, say explicitly that the file is incomplete rather than letting the missing final-part label speak for itself.

• Carry over CDN links, external dependencies, and config values as-is unless the work item explicitly asks you to change them.

Before calling the work item done

Don't grade yourself with a checklist of "[PASS]" lines — that's theater; a model can print PASS regardless of whether the code matches. Instead, produce something checkable:

• Run scripts/check_truncation.py on every file you wrote or rewrote:

  python3 scripts/check_truncation.py path/to/file1.css path/to/file2.js
  

  This is a deterministic lexical scan, not a self-report — it either finds a known truncation marker or it doesn't, and either way prints the exact match with file:line. It only catches known patterns, so a clean run means "no known shortcut phrase," not "definitely complete" — still diff against the source for anything the script can't see (a silently dropped rule with no marker at all).
• Diff or visually compare your output against the source file(s) for the DOM and CSS you touched.
• If designstudyo-exact-clone's tooling is available in this package (clonectl.py, verify.sh, work-items.json), run it and use its actual visual/runtime scores — that skill's gates (0.97 visual score, full coverage, 1.00 interaction checks per viewport) are the real bar, not a self-audit.

If you can't verify (no tooling in this package, canvas/video/iframe content, missing source asset), say that plainly rather than declaring completion.