Frequently asked questions

In the default presentation-only mode it may change the README, the generated site in docs/, the site sources under site/, the site builder, the site requirements file, the site CI workflow, and append-only lines in .gitignore. Everything else is frozen, and a boundary diff proves it.

No. Product code, tests, manifests, existing workflows, the licence and existing images are frozen. If a page seems to need a product change, the agent stops and reports it. A rebuild is a separate, explicitly opted-in mode with its own pull request.

One row per factual statement on the site, quoting the exact wording, with evidence that resolves to a file, a line or a command and its output. A claim without evidence is removed. The ledger lives outside the repository because it is internal.

It cannot make an unverified claim true, invent a screenshot, or fix a product defect under a presentation-only scope. It cannot merge without the owner's go, and it cannot guarantee indexing or ranking. It reports CONFIRMED, UNVERIFIED and NOT DONE separately.

Claude Code with plugin support, git, an authenticated gh for the GitHub steps, and Python 3.12 for the scripts. Perceptual clustering and contact sheets also need Pillow and imagehash, installed in a scratch environment rather than the repository.

The plugin itself is free and MIT licensed. A revamp consumes model usage in Claude Code, and the installed plugin reports its own always-on token cost. The playbook does not quote a per-revamp figure, because it would depend on the repository and the session.

Refresh the marketplace and reinstall the plugin to update. Uninstall the plugin and remove the marketplace to remove it. The version is declared only in the plugin manifest, so the marketplace and the plugin cannot disagree about it.

Open an issue on the GitHub repository. The project is public, and the issue tracker is the contact channel. There is no email address, and the site does not publish one.

It depends on the repository, not on the plugin. INTAKE and SPEC are quick. BUILD dominates, because every page needs verified content, reviewed images and a green gate. The playbook does not publish a time estimate, because an estimate that is not measured is a guess.

It makes the work sequential and testable. Each phase has an exit gate someone else can check, and the state file records where the work stopped so a fresh session resumes instead of starting over. It is also what prevents building before the spec is agreed.

The owner's answers to the spec's numbered questions, appended to the spec with a timestamp. It is binding: where the spec and a habit conflict, the spec wins. An unanswered question is a stop, not a default.

The worktree keeps PROGRESS.md and HANDOFF.md from the first edit, and work in progress is committed early. A resumed session reads the handoff and continues from the recorded state. If the resume fails, a fresh agent gets the complete brief.

Run the revamp command again on the same repository. It reads the state file, reports the phase, the gates and the open questions in five lines, and continues from the current phase only. It does not restart the earlier phases.

Yes, in batch mode: one agent per repository, launched together in one message, with the coordinator deploying one repository at a time. Never two agents on one repository, and never two agents touching the same DNS zone at once.

Because GitHub Pages can serve a branch and a folder with no build step, and because a committed output can be byte-compared with a fresh build. The builder owns docs/ entirely; nothing else writes there.

So that the committed output can be proven to match a fresh build on any machine, on any day. That rules out the wall clock, git history, random identifiers and unordered iteration. The check mode compares every file byte for byte.

No. The builder owns docs/ and the next build overwrites it. Edit the content, the templates, the styles or the tokens under site/, then run the builder and commit the regenerated output.

The build stops before anything is written. It prints the file and the line for the failure, and never prints a matched secret value. Nothing is published from a failed build, and the failure is fixed at the source rather than waived.

Every tracked image is inventoried with its hash and dimensions. Exact duplicates and perceptual near-duplicates are removed. Every remaining candidate gets a verdict after a visual review. Sensitive regions are covered on a copy, with the rectangles recorded, and the derivative is reviewed again.

Then the pages show no image slots. The playbook is explicit: a feature area with no approved image shows no frame waiting for a picture, and no caption is written for an image that does not exist. Original diagrams can carry the page instead.

A public repository with no need for previews goes to GitHub Pages from the default branch, output docs/. A private repository with a public site, or an owner who wants preview deployments, goes to Cloudflare Pages. The choice is made in INTAKE and recorded in the spec.

GitHub Pages wants a CNAME to the GitHub Pages hostname set to DNS-only, the grey cloud. Cloudflare Pages creates the record itself and keeps it proxied, the orange cloud. Getting them backwards causes HTTPS failures that look like certificate faults.

Yes. The custom domain is a subdomain of the owner's zone, written bare in docs/CNAME for GitHub Pages and attached through the Pages project for Cloudflare. The certificate is approved before HTTPS is enforced.

The SEO phase submits the sitemap to Search Console, sets the repository description and homepage, and adds topics. Submission is recorded with the tool's response. Crawling and indexing are the search engine's decision, and a new site can take days.

Yes. The playbook documents a private-repository posture: a public site generated from a private source, hosted on Cloudflare Pages from the site branch, with the source never published. That behaviour is documented rather than exercised on this site's own repository, which is public.

No. repo-revamp is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude and Claude Code are trademarks of Anthropic.