What is a vibe-coded app?

A vibe-coded app is software built quickly with AI coding assistants. That speed often ships risky defaults: hardcoded API keys, wildcard CORS, debug mode left on, and missing security headers. Wardloom is a defensive launch checker made to catch those oversights before launch.

What does Wardloom check before deployment?

Wardloom covers twelve security check families: secrets, CORS, security headers, dependency CVEs, config exposure, auth and session flaws, IDOR and ownerless endpoints, debug artifacts, deployment readiness, LLM and agent security, plus advisory traffic-readiness and legal/privacy signals. On live URLs it also runs deterministic SEO and GEO/AEO audits, Core Web Vitals, and a light crawl. Verify control of your domain and eight read-only live deployment checks unlock on top.

Is Wardloom safe? Does it store my code?

Yes. Wardloom is a strictly benign, read-only tool for reviewing code and deployments you own. It never executes your code, never runs exploits, and never fuzzes your application. Submitted code goes to the analyzer transiently and is never written to a database, and secret values are redacted before anything is stored or displayed.

What is the Ship-Readiness score?

Ship-Readiness is the headline of every Wardloom report: one number that answers whether an app is finished and safe to launch. On repository scans it combines the deterministic Vibe-Check Security Score (0 to 100, weighted 65%) with a Completion Score (35%), and it can never read higher than the security score while a critical or high finding is open, coverage was truncated, or the authorization surface went untested. Alongside it sits a pass, warn, or block gate and Launch Confidence, which weights security, SEO, health, and GEO.

What are verified-deployment checks?

Verified-deployment checks are eight live checks that run only after you prove you control the domain, using a DNS TXT record or a file at a /.well-known path. They cover dangling DNS records, exposed administration routes, directory listings, GraphQL introspection, public API documentation, HTTPS enforcement, TLS certificate health, and verbose error pages. All of them are read-only GET requests and DNS lookups against a fixed path list — never fuzzing, never an exploit attempt.

Can Wardloom run inside Claude Code, Cursor, or another AI coding agent?

Yes. Wardloom ships an MCP server — npx -y wardloom-mcp — that connects to Claude Code, Cursor, and any MCP client. It exposes seven tools: local_precheck for a fast scan that stays on your machine, start_scan and get_scan_status, check_deploy_ready for the ship gate, get_findings, get_remediation_roadmap, and get_handoff_prompt. Create an API key from your dashboard, paste one config block, and tell your agent to check the app before it ships. API access is available on every plan.

Can Wardloom gate my CI pipeline?

Yes. The Wardloom Ship-Readiness Gate is a GitHub Action that scans a repository or a deployed URL on every pipeline run and fails the build when the result falls below your score threshold. The same endpoints are available directly as an authenticated HTTP API, with idempotency keys, stable error codes, and a scan-to-scan delta so you can see what changed since the last run.

How do I fix the issues Wardloom finds?

Every report includes a phased remediation roadmap ordered by severity and effort, plus a copy-pasteable Dev/AI handoff prompt — a benign, defensive refactoring request you can paste into Cursor or Claude, or hand to a teammate. On Pro, Guided Fixing proposes validated diffs and rescans afterwards to confirm the issue is actually gone. Reports export to PDF and HTML, and every one states plainly what was not tested.

Does Wardloom keep checking after I launch?

Yes. Turn on monitoring for a project and Wardloom re-scans it daily or weekly, emails you when something regresses, and sends a monthly summary. Scan-to-scan comparison shows what was fixed, what is new, and what is still open, and Pro and Team can publish a shareable Ship-Readiness certificate that carries scores and coverage honesty without exposing any finding detail.

Field notes

Safe handoff prompts: fixing vibe-coded apps with Cursor and Claude

2026-07-15 · 7 min read

A good remediation prompt is precise, calm, and defensive. It names the file, the issue, and the intended fix without wandering into exploit language or destructive requests. That is what makes it useful to a coding tool and safe for a team workflow.

What belongs in a defensive handoff

Start with context. State the stack and confirm that this is your own application.

Then state the finding clearly: severity, file or route, and why it matters in plain language.

Close with the expected fix and any constraints that matter, especially least privilege, read-only intent, and a ban on echoing secret values back into the conversation.

What to avoid

Do not ask a model to prove the issue against production with a payload. That is not remediation; it is drift.

Do not paste live secrets into the chat for confirmation. Rotate the credential instead.

Do not accept broad, convenient refactors that quietly relax auth or widen CORS just to make the warning disappear.

A steward’s loop

The healthiest loop is simple. Scan first. Prioritize the critical work. Send a focused handoff. Review the diff with a senior eye. Then scan again. That rhythm keeps AI-assisted delivery fast without letting the quality drift.

Questions builders ask

Can I use the same prompt in Lovable or Bolt?

Yes if the tool accepts a natural-language change request. Keep the defensive constraints intact.

Does Wardloom apply fixes automatically?

Guided fixing and human-reviewed paths exist on higher tiers; the handoff prompt is the universal, copy-pasteable bridge for any coding agent.

Ready for the last gate?

Run a defensive Wardloom scan, security, SEO, GEO, and health, then leave with a roadmap and handoff prompt.

Scan your app