What to send when asking for help with a broken AI app
The request "can you help with my broken AI app" is honest but unhelpful. The rescuer can't triage what they can't see. The conversation that follows is back-and-forth about basic facts: what's the app, what's broken, what have you tried, where's the code. Each round trip delays the actual rescue.
A well-formed rescue request includes the information the rescuer needs to triage without further back-and-forth. The triage might still be "I need to look at this before I can scope it," but at least the rescuer can give that response usefully on the first reply rather than after three rounds of clarifying questions.
I want to walk through the eleven items that constitute a complete rescue packet, why each one matters, and what the minimum viable packet looks like when you can't send everything immediately. The discipline turns a vague help request into actionable triage.
Item one: project goal
What the app is supposed to do, in one or two sentences.
This is the most fundamental context the rescuer needs. "The app is broken" doesn't help if the rescuer doesn't know what it's supposed to do. The repair has to restore the correct state, which requires knowing what correct looks like.
Format: a brief description of the app's purpose and intended users. "A web app that lets small businesses upload customer receipts and automatically categorize them for tax purposes" is enough. The rescuer can ask follow-ups about specifics; they need the high-level frame to start.
Item two: current failure
What's specifically wrong right now.
Concrete, specific, and observable. Not "the app is broken" but "after the AI's last session, submitting the upload form shows a success message but the file doesn't appear in the user's receipt list." The format covered in the ai-coding-agent-broke-my-app post applies: specific behavior, when it started, what the AI claimed it did.
If multiple things are broken, list them in priority order. The rescuer can address them in order without having to guess which one matters most.
Item three: last known working state
The most recent state where the app was working correctly.
Often a commit hash, a deployment URL, a date, or a description of the state. "The app was working correctly yesterday at 3pm before the AI session that was supposed to add the email notification feature. The previous deployment is still available at staging-prev.example.com." gives the rescuer a baseline to compare against.
This item is critical because it lets the rescuer identify the gap between working and broken. Without it, the rescue has to reconstruct what working looked like, which is much harder than diffing against a known-working state.
Item four: repo access or exported files
The code itself, in a form the rescuer can read.
Format options: GitHub repo link with read access granted, a cloned repo sent as a zip, exported files from the AI tool's workspace, deployment package contents. The format depends on what's practical for your situation; the requirement is that the rescuer can actually see the code.
For sensitive code, scope the access appropriately. The rescuer needs to read the code to triage; they don't necessarily need write access until they're actively repairing.
Item five: deployment target
Where the app runs in production (or where it should run).
The hosting platform, the deployment process, the environment configuration. "The app is deployed to Vercel via GitHub auto-deploy on push to main. The deploy uses the production environment with the env vars listed in vercel.json comments." gives the rescuer the operational context.
This matters for the runtime-layer diagnostics covered in ai-build-keeps-failing. The rescuer needs to know what runtime to test against and how the deployment chain works.
Item six: screenshots
Visual evidence of the broken state.
Screenshots of error messages, of broken UI, of the expected versus actual behavior side by side, of any console output that surfaces the problem. The rescuer can read code; they can't see what you're seeing without the visual evidence.
For dynamic behaviors (animations, transitions, loading states), a short screen recording is sometimes more useful than screenshots. The format depends on what the failure looks like.
Item seven: logs
What the system was outputting when things went wrong.
Server logs, browser console output, build output, deployment logs. These show what was happening from the system's perspective at the time of failure. They often surface the actual cause that the visible symptoms only hint at.
If logs aren't available (the system doesn't log enough, the logs got rotated out, you don't have access), that's itself diagnostic. The rescue may need to add observability before it can address the underlying issue.
Item eight: build errors or test failures
The specific outputs from any failing build or test runs.
Copy-paste the actual error messages, not paraphrases. The exact text of the error often matches a known issue with a specific fix; paraphrased descriptions don't match anything.
If multiple errors are firing, include them all. The first one is sometimes the cause and the rest are downstream effects; sometimes the relationship is reversed. The rescuer needs to see the full set to diagnose correctly.
Item nine: protected files or behaviors
What must not change during the repair.
Files that contain working code you don't want touched. Behaviors that must be preserved exactly. Integrations that must keep working. URL structures that other things depend on.
This is the rescue-spec's "protected scope" section from how to write a rescue spec for a broken AI project condensed to its essentials. Without it, the rescuer might fix the immediate problem and break something adjacent.
Item ten: business deadline
When the fix needs to be done and what's tied to that deadline.
"Needs to ship by Friday because of a customer launch dependency" is different from "needs to ship eventually but no specific deadline." The rescuer's approach changes based on the timeline.
If the deadline allows trade-offs ("we can ship without the verification email if signup itself works"), name them. If the deadline is non-negotiable on certain dimensions ("the payment flow must work; everything else can wait"), name those too.
Item eleven: what must not change
The non-negotiable constraints that bound the repair.
Some constraints come from the protected scope (item nine), but this item is broader: regulatory requirements, contractual obligations, customer commitments, internal policy. "The app must continue to comply with GDPR data handling requirements" or "the customer was promised the integration would never log their data" are constraints the rescuer needs to know about even if they're not at risk in the immediate repair.
This item often surfaces things the operator forgot they needed to preserve. Writing it explicitly catches the constraints before the repair accidentally violates them.
The minimum viable packet
If you can't send all eleven items immediately, the minimum that lets useful triage start is:
Project goal (item one).
Current failure (item two).
Last known working state (item three).
Repo access or exported files (item four).
Business deadline (item ten).
With these five, the rescuer can do initial triage and identify what else they need. Without them, even initial triage is blocked.
The remaining items (deployment target, screenshots, logs, errors, protected files, constraints) can come in follow-up messages once the rescuer has had the chance to look at the initial packet. The first message should include at least the five minimums.
Why this discipline matters
A vague help request produces vague help. The rescuer's response is bounded by the information available; less information produces less useful initial response, which produces more rounds of clarification, which produces more delay before actual repair work starts.
A well-formed packet produces useful help quickly. The rescuer can triage on first read. The first response is substantive rather than clarifying. The repair starts immediately rather than after rounds of back-and-forth.
The packet is the same shape as the nav that almost wasn't describes for codified diagnostic discipline: structure the information capture so the diagnosis can be made without exploratory work. Operators who internalize this discipline get faster, better rescues. Operators who don't get the firefighting cycles.
Building the packet from scratch
If you've never structured a help request this way before, the first packet takes some work. You have to gather information you may not have organized: the last working commit, the actual error messages, screenshots of the failure.
The second time is faster because you know what to collect. The third time it becomes routine.
The investment of 30-60 minutes to put together a complete packet often saves hours of back-and-forth that would have followed a vague request. The math favors the discipline.
The intake-as-product framing
For a rescue service, the intake packet is essentially the product spec. Everything that follows depends on what came in. A weak intake produces weak rescue; a strong intake produces strong rescue.
VibeKoded's intake structure matches this packet shape because the same information is needed regardless of who's doing the rescue. Operators who send well-formed intake get scoped responses with actual diagnostic content; operators who send vague requests get a "tell me more about X" response that delays the engagement.
The discipline isn't about VibeKoded specifically. It's about how to ask for help with broken software effectively. The same packet works for any rescue resource.
If you've got a broken AI project and want to start a rescue conversation, send the packet above. VibeKoded can scope a rescue diagnostic, stabilization sprint, or rebuild plan. → Work with VibeKoded