AI Website Cloner Evaluation
AI Website Cloner Evaluation (#1239)
Section titled “AI Website Cloner Evaluation (#1239)”Evaluated 2026-10-01 by reading the repository through the GitHub API; nothing
was cloned, installed or run.
JCodesMore/ai-website-cloner-template
is live and active: MIT, about 35,500 stars, version 0.5.1 (2026-09-26), last
pushed 2026-09-27. It is a Next.js 16 / React 19 / Tailwind v4 / shadcn
template plus one skill, /clone-website, that rebuilds a live page as a
Next.js codebase.
Verdict: borrow two patterns, keep the rest as reference. BoB does not
clone websites and should not ship this skill. Two of its rules make BoB’s
parallel work better and are filed: a swarm worker gets its whole brief
inline, kept as a file and held to a size budget (#3557), and a worker runs
its own done-check before it finishes, which surfaced a real gap in
bob swarm (#3556). The template’s history is the most useful input for the
multi-harness work: it built AGENTS.md sync scripts, then removed them. That
finding is recorded on #500.
How the skill is built
Section titled “How the skill is built”The canonical skill is one file, .agents/skills/clone-website/SKILL.md
(about 560 lines), with an inspection checklist in references/ loaded on
demand. Claude Code reaches it through a three-line command bridge,
.claude/commands/clone-website.md, that says to read the skill and follow it.
CLAUDE.md is a single @AGENTS.md import.
The skill calls itself a foreman walking the job site: the main agent inspects one section at a time, writes a spec for it, and hands that spec to a builder agent while it moves on to the next section. Its phases:
- Pre-flight. Requires a browser MCP server; checks the base build; inventories existing routes; writes an output plan with collision-resistant keys (a slug plus 8 hex characters of a SHA-256) for every site, page, route and asset folder, so a later run never overwrites an earlier one.
- Reconnaissance. Full-page screenshots at 1440 px and 390 px; fonts,
colours, favicons; a mandatory interaction sweep (scroll, click, hover,
three widths) written to
BEHAVIORS.md; a section map written toPAGE_TOPOLOGY.md. - Foundation. Shared tokens, types, icons and assets, done by the main agent itself, in sequence, because these files are shared.
- Spec and dispatch. For each section: extract computed styles with a
provided script, write
components/<name>.spec.mdfrom a fixed template, then dispatch one builder per section in its own git worktree, or one per sub-component when the section is complex. Builders run while extraction continues; their branches are merged back one at a time with a build after each merge. - Assembly. Wire the sections into the planned route; build.
- Visual QA. Compare the clone with the original at both widths, section by section; for each difference, decide whether the spec or the builder was wrong, and fix that one.
Phases against BoB primitives
Section titled “Phases against BoB primitives”| Clone-website phase | Closest BoB primitive | Reusable? |
|---|---|---|
| Pre-flight: tool check, base build | Warp-drive prerequisites and the preflight gate (bob doctor + bob ready --dry-run) |
Already covered |
| Output plan with collision-resistant keys, never overwrite existing routes | The swarm decompose step’s file-ownership overlap check; serial-only pinch points |
Already covered for files; the hashed namespace idea is site-specific |
| Reconnaissance written to files before any build | /research, bob do (framing → working), docs/research/ notes |
Covered in spirit |
| Foundation built first, in sequence, by the lead | Pinch points labelled serial-only and kept out of bob fork --from-issues |
Already covered |
| A spec file per piece, written before dispatch | Nothing: a swarm subtask carries a title and a one-line deliverable | Borrow (#3557) |
| Builder gets the whole spec inline, “no guessing” | Nothing: the Workflow lane prompt lists id, title, owned files and deliverable | Borrow (#3557) |
| Complexity budget: over about 150 spec lines, split the piece | Fan-out verdict (fewer than three independent pieces → one agent); max_acs_per_commit in chunking |
Borrow as a brief-size warning (#3557) |
Builder verifies (tsc --noEmit) before finishing |
Swarm result gate and grader; warp-drive testing |
Gap found: the plan’s verification is never run (#3556) |
| Merge each worktree, build after each merge | Swarm integrator (#581); bob fork merges per branch |
Already covered |
| Visual QA against the original | webapp-testing skill; warp-drive qa phase |
Already covered for behaviour; pixel comparison is clone-specific |
| “Identify the interaction model before building” | Nothing general | Clone-specific; not taken |
Parallel builders against bob fork and bob swarm
Section titled “Parallel builders against bob fork and bob swarm”The template’s fan-out is the same shape as BoB’s: a lead splits work, each
worker runs in its own git worktree, results merge back one at a time.
bob fork gives each worktree a full warp-drive session that reads its own
issue, so its workers already get a complete brief: the issue body. The gap is
in bob swarm, where the lead splits one free-text instruction and each worker
gets only what the plan carries:
id, title, owned files, deliverableWrite ONLY within your owned files. Include a change-specific test.The plan also carries a verification command, which the schema requires,
but neither stage of the Workflow lane uses it (#3556).
The template’s rule is the opposite: everything the worker needs is pasted
into its prompt (“don’t say go read the spec file”), the same text is saved as
a file so a reviewer can see what the worker was told, and a spec too long to
paste means the piece is too big. That fits BoB’s decompose step, which already
owns the split and already emits a fan-out verdict. Adopt the inline full
brief, the brief file and the size warning for bob swarm (#3557). Do not
change bob fork; its issues are the brief.
Not adopted: the template dispatches builders while the lead is still inspecting. BoB’s swarm approves a whole plan before dispatch, which is the safer order for work that is not as uniform as page sections.
AGENTS.md as the source of truth
Section titled “AGENTS.md as the source of truth”The issue asked about AGENTS.md plus sync-agent-rules.sh and
sync-skills.mjs generating CLAUDE.md, GEMINI.md and per-platform skills.
Those scripts no longer exist. The changelog shows the arc:
- 0.3 (March 2026): the sync scripts and 13 platforms.
- 0.4.0 (2026-08-10): generators hardened against platform schema changes and Windows line endings; a CI gate fails on stale generated files.
- 0.5.0 (2026-09-17): scripts, CI gate and every generated copy removed. One
canonical skill in
.agents/skills/, which Codex, Cursor and OpenCode read directly; a thin bridge for Claude Code; four supported platforms.
The lesson for BoB’s multi-harness work (#498, #500): prefer a pointer or an
import to a generated copy wherever a harness can read the shared file, and
generate only where a harness needs a different format. BoB’s own AGENTS.md
is a hand-kept copy of CLAUDE.md with “Claude Code” replaced by “Codex”;
that is the drift #500 exists to remove. The finding is posted on #500 rather
than proposed here.
Not verified
Section titled “Not verified”- The skill was not run; no page was cloned and no builder was dispatched.
- Whether Codex, Cursor and OpenCode read
.agents/skills/as the README says was not checked against their documentation. - The removed sync scripts were not read; their behaviour is taken from the changelog.