Portabrief
Portabrief turns a WordPress page (or the whole site) into a portable rebuild package: a single BRIEF.md that describes the design system, components, content, and navigation, plus bundled assets, fonts, a manifest.json, and a per-module breakdown. The goal is a self-contained handoff you can rebuild from on a different stack — Next.js, Astro, Nuxt, Eleventy, Hugo, a native WordPress block theme, a headless front-end, an LLM coding agent, or Claude Design.
It is built for developers and agencies who are escaping page-builder lock-in, re-platforming a site, or handing a design off to another team or an AI.
What it produces
BRIEF.md— a synthesis-first, human- and LLM-readable brief: design tokens (colour, typography, spacing), an inferred component inventory with token bindings, the content outline, navigation, rebuild instructions, a gaps list, and a transparent portability score with its composition.- Bundled
assets/,fonts/,logos/(self-hosted resources are copied; remote ones are recorded by URL). manifest.json— the machine-readable mirror of everything.- Destination-specific scaffolding (the chosen target gets a tailored starting point and a “recommended stack & elements” section).
Key features
- Whole-site or single-page export from a Tools → Portabrief screen.
- Real portability score computed server-side, with a Coverage / Fidelity / Risk-headroom breakdown.
- Secret redaction — credentials and API keys are never written to the package; only their existence is noted, masked as
***REDACTED***. A pre-flight scan blocks the download if any residual secret is detected. - PII safeguards — user records are off by default; when an admin includes them, the UI states plainly that real email addresses are exported, and a bundle headed to an external AI must be explicitly acknowledged.
- Export history — a local, append-only audit log of every export (who, scope, destination, whether PII was included and acknowledged). Stays on your site.
- Feedback box — request a feature or report a bug from inside the admin.
External services
Portabrief works fully offline by default. Three optional integrations may contact an external service, each only when you choose to use it:
- Feedback email — when you submit the in-admin feedback form, your message, the email you enter, your site URL, and basic environment info (WordPress/PHP/plugin versions) are emailed via your site’s own mailer to the Portabrief developer (
connect@1click2open.com) so they can respond — or to an address you configure with thePORTABRIEF_FEEDBACK_EMAILconstant /portabrief_feedback_recipientfilter. Nothing is sent unless you click “Send feedback”. - Portabrief Hub (optional) — if you configure a central Hub (via the
PORTABRIEF_HUB_URL/PORTABRIEF_HUB_KEYconstants), feedback tickets are sent to it and their status is synced back. Off unless those constants are set. - Usage analytics (opt-in) — if you tick “Share anonymous usage analytics” in Tools → Portabrief, an anonymous payload (a random install ID, plugin/WordPress/PHP versions, and aggregate counts — never your URL, content, emails, secrets, or any export data) is sent to the configured Hub. Off unless you turn it on; the exact payload is previewable before you opt in.
Detection only (no connection): to document your site, Portabrief scans your own pages and options for third-party services already present (e.g. Stripe, Intercom, Google Tag Manager, Meta Pixel, Tawk.to, Hotjar) and records which ones it finds. These are local detection patterns — Portabrief does not connect to any of these services and sends them no data.
