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

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:

1. 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.
2. 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 to PAGE_TOPOLOGY.md.
3. Foundation. Shared tokens, types, icons and assets, done by the main agent itself, in sequence, because these files are shared.
4. Spec and dispatch. For each section: extract computed styles with a provided script, write components/<name>.spec.md from 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.
5. Assembly. Wire the sections into the planned route; build.
6. 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

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

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, deliverable
Write 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

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

• 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.