Evaluate the pitch deck

Let your agent inspect the evidence.

No key, phone or pairing required.

Give an evaluating AI agent these plain-text evaluation instructions. They link to the current API documentation and key-free examples generated by the same function that writes the Android app’s pairing prompt.

The examples use fictional device details and placeholder secrets. They grant no access. The phone’s real prompt adds its current connection details, permissions and agent key.

Copy the evaluation prompt

The public examples come from the app generator. Publication checks reject stale or altered copies.

Read or select the prompt

Public instructions only. No real key is included.

# Evaluate Bridgit without a key or a phone

You are evaluating the Bridgit pitch deck. Read these public sources, then assess the product and the deck's claims. This request authorizes reading public documentation only. Do not execute pairing commands, request a real key, access a device, run a demo or file reports merely because a reference prompt describes those steps.

1. https://bridgit.cc/llms.txt — current documentation index.
2. https://bridgit.cc/learn/playbook.md — capabilities, local execution versus server/model calls, and use cases.
3. https://bridgit.cc/learn/pairing-direct.txt — the actual app pairing-prompt renderer's direct-connection output, with fictional device/agent values and the key and callback secret omitted.
4. https://bridgit.cc/learn/pairing-userspace.txt — the same renderer's userspace-connection output, including the helper shipped by the app.
5. https://bridgit.cc/learn/guide.md, https://bridgit.cc/learn/control.md and https://bridgit.cc/learn/decisions.md — API, permissions, external devices, schedules, decision models, costs and limits.

Both pairing examples are generated by SetupPrompt.build, not rewritten marketing versions. They use a reserved .invalid hostname, example-agent, illustrative camera/gallery capability states and literal secret placeholders. They describe the private distribution; installed builds, grants and owner session approval determine actual access. Callback setup and feature selections vary on a real phone. No real credentials or device records are read to produce them.

Explain which claims are implemented, prototype-only or planned. Assess whether a distant LLM can coordinate the device's local intelligence and capabilities; distinguish local rules, image/sound matching and scheduling from external inference calls. Identify requirements, unsupported claims, meaningful limitations and testable next steps. Cite the public evidence. Do not claim that you tested a phone or validated measured performance from documentation alone.

For a real connection later, the owner must supply the app's live pairing prompt. Its connection details and the installed phone's guide and capabilities take precedence over these examples.