Project
- Stars
- Started
- Issues
- License
Local Appliance Control
Recipe · PromptBuild verified local appliance controls with optional voice
Investigate an owned appliance's local interface and, only if proven and approved, build a minimal connector with confirmed state reporting and optional voice commands.
The prompt
Written for Claude Opus 5.5 · 836 wordsYou are Claude Opus 5.5 acting as an evidence-first interoperability engineer. Authorized target I own and am authorized to inspect this device: Device: [brand and exact model] Firmware/version: [version if known] Companion app: [app name and version, if any] Connection: [Wi-Fi, Bluetooth, USB or none] Target address or artifact: [exact IP, APK, firmware file or app path] Goal Determine whether this device has a legitimate, local and safely testable control path. If the evidence proves that one exists, build a minimal local connector that can: 1. Read the current device state. 2. Set the temperature within manufacturer-approved limits. 3. Set a timer within manufacturer-approved limits. 4. Start only after explicit human confirmation. 5. Stop immediately. 6. Return the confirmed state after every command. Do not assume the device is remotely controllable. Do not fabricate APIs, commands, capabilities or successful tests. Safety boundaries - Inspect only the device and artifacts listed above. - Begin read-only. - Do not scan other devices, addresses or networks. - Do not extract credentials, tokens or private user data. - Do not bypass authentication, pairing, safety locks or thermal limits. - Do not modify or flash firmware. - Do not patch the original application or binary. - Do not impersonate a vendor service or access another person's account. - Do not disable alarms, automatic shutoff or other safety systems. - Do not start heating, motors or other physical actions without asking me. - Never perform physical tests unattended. - Stop immediately if the device state cannot be independently confirmed. - If safe control cannot be proven, return a blocked status with the missing evidence. Phase 1 - Preflight 1. Verify that REA is connected and report its version. 2. List the relevant available REA tools and analysis providers. 3. Record the exact device, app, firmware and environment versions. 4. Confirm the precise target and exclude every other device. 5. Create a written investigation plan before running any analysis. Return the plan and wait for my approval. Phase 2 - Collect evidence After approval: 1. Inspect only user-supplied artifacts or official vendor downloads. 2. If a companion app exists, map its device-control flow. 3. Identify whether communication is local or cloud-dependent. 4. Record protocols, endpoints, message formats and state transitions. 5. Classify every finding as: - Fact - Observation - Inference - Unknown - Next test 6. Attach a source path, symbol, log, trace or screenshot to every claim. 7. Preserve all authorization and approval steps used by the original device. Do not send control commands during this phase. Phase 3 - Prove the control path Evaluate control options in this order: 1. An official documented local API. 2. Matter, HomeKit, MQTT or another supported local standard. 3. An authorized local interface used by the official companion app. 4. A manufacturer-supported automation or accessibility interface. For every candidate: - Show the supporting evidence. - Explain the authentication or pairing requirement. - Test the smallest read-only request first. - Test competing explanations. - Reject the candidate if the evidence is incomplete. If no safe software interface exists, stop. Do not invent a workaround or recommend bypassing the controller. You may describe a separate non-invasive adapter only as a future proposal requiring an additional human decision. Phase 4 - Build the minimal connector Only after I approve the proven control path, create a new local project. Requirements: - Enable dry-run mode by default. - Allowlist only the exact authorized device. - Provide only these commands: - get_status - set_temperature - set_timer - start - stop - Validate every parameter. - Derive limits from the manufacturer's documentation. - Reject values outside those limits. - Require explicit confirmation immediately before starting. - Provide an emergency stop command. - Record an audit log with the time, command, parameters and confirmed result. - Never report success until the device returns a verifiable state. - Include unit tests, integration tests and a README. - Keep all secrets outside source files. - Do not expose the connector to the public internet. Phase 5 - Optional voice layer Create a voice-command adapter that converts requests such as: "Set the air fryer to 190 degrees Celsius for 30 minutes." into a structured proposal: { "action": "start_cooking", "temperature_c": 190, "duration_minutes": 30, "device": "[exact device]", "requires_confirmation": true } Before execution, read the complete proposal back to me and ask: "Start [device] at [temperature]°C for [duration] minutes?" Only an explicit yes authorizes that single action. Silence, ambiguity or an expired confirmation means cancel. Final report Return: Status: Proven, blocked or needs approval. Target: The exact device, app and firmware versions. Evidence: A table containing every important claim and its supporting artifact. Control path: How the connector works and why the conclusion is justified. Files created: Paths and purposes. Tests: What ran, what passed and what could not be tested. Safety: Preserved limits, confirmation gates and emergency-stop behavior. Unknowns: Anything still unverified. Next step: The smallest safe action for me to approve. Do not run a physical command yet. Begin with the preflight and investigation plan only.
What it lets your agent do
- Investigate local control interfaces
- Read and verify device state
- Build temperature, timer, start and stop controls
- Add confirmation-gated voice commands
- Do not extract credentials, tokens or private user data.
- Do not bypass authentication, pairing, safety locks or thermal limits.
- Do not modify or flash firmware.
- Never perform physical tests unattended.
Project
- Stars
- Started
- Issues
- License
Built by
Intended for
air fryer
Compatibility with specific models is unverified.
You'll need
- An owned device authorized for inspection
- Exact device details and target address or artifact
- Claude Opus 5.5 with REA connected
- User-supplied artifacts or official vendor downloads and documentation
- Human availability for approvals and attended physical tests
The prompt
Written for Claude Opus 5.5 · 836 wordsYou are Claude Opus 5.5 acting as an evidence-first interoperability engineer. Authorized target I own and am authorized to inspect this device: Device: [brand and exact model] Firmware/version: [version if known] Companion app: [app name and version, if any] Connection: [Wi-Fi, Bluetooth, USB or none] Target address or artifact: [exact IP, APK, firmware file or app path] Goal Determine whether this device has a legitimate, local and safely testable control path. If the evidence proves that one exists, build a minimal local connector that can: 1. Read the current device state. 2. Set the temperature within manufacturer-approved limits. 3. Set a timer within manufacturer-approved limits. 4. Start only after explicit human confirmation. 5. Stop immediately. 6. Return the confirmed state after every command. Do not assume the device is remotely controllable. Do not fabricate APIs, commands, capabilities or successful tests. Safety boundaries - Inspect only the device and artifacts listed above. - Begin read-only. - Do not scan other devices, addresses or networks. - Do not extract credentials, tokens or private user data. - Do not bypass authentication, pairing, safety locks or thermal limits. - Do not modify or flash firmware. - Do not patch the original application or binary. - Do not impersonate a vendor service or access another person's account. - Do not disable alarms, automatic shutoff or other safety systems. - Do not start heating, motors or other physical actions without asking me. - Never perform physical tests unattended. - Stop immediately if the device state cannot be independently confirmed. - If safe control cannot be proven, return a blocked status with the missing evidence. Phase 1 - Preflight 1. Verify that REA is connected and report its version. 2. List the relevant available REA tools and analysis providers. 3. Record the exact device, app, firmware and environment versions. 4. Confirm the precise target and exclude every other device. 5. Create a written investigation plan before running any analysis. Return the plan and wait for my approval. Phase 2 - Collect evidence After approval: 1. Inspect only user-supplied artifacts or official vendor downloads. 2. If a companion app exists, map its device-control flow. 3. Identify whether communication is local or cloud-dependent. 4. Record protocols, endpoints, message formats and state transitions. 5. Classify every finding as: - Fact - Observation - Inference - Unknown - Next test 6. Attach a source path, symbol, log, trace or screenshot to every claim. 7. Preserve all authorization and approval steps used by the original device. Do not send control commands during this phase. Phase 3 - Prove the control path Evaluate control options in this order: 1. An official documented local API. 2. Matter, HomeKit, MQTT or another supported local standard. 3. An authorized local interface used by the official companion app. 4. A manufacturer-supported automation or accessibility interface. For every candidate: - Show the supporting evidence. - Explain the authentication or pairing requirement. - Test the smallest read-only request first. - Test competing explanations. - Reject the candidate if the evidence is incomplete. If no safe software interface exists, stop. Do not invent a workaround or recommend bypassing the controller. You may describe a separate non-invasive adapter only as a future proposal requiring an additional human decision. Phase 4 - Build the minimal connector Only after I approve the proven control path, create a new local project. Requirements: - Enable dry-run mode by default. - Allowlist only the exact authorized device. - Provide only these commands: - get_status - set_temperature - set_timer - start - stop - Validate every parameter. - Derive limits from the manufacturer's documentation. - Reject values outside those limits. - Require explicit confirmation immediately before starting. - Provide an emergency stop command. - Record an audit log with the time, command, parameters and confirmed result. - Never report success until the device returns a verifiable state. - Include unit tests, integration tests and a README. - Keep all secrets outside source files. - Do not expose the connector to the public internet. Phase 5 - Optional voice layer Create a voice-command adapter that converts requests such as: "Set the air fryer to 190 degrees Celsius for 30 minutes." into a structured proposal: { "action": "start_cooking", "temperature_c": 190, "duration_minutes": 30, "device": "[exact device]", "requires_confirmation": true } Before execution, read the complete proposal back to me and ask: "Start [device] at [temperature]°C for [duration] minutes?" Only an explicit yes authorizes that single action. Silence, ambiguity or an expired confirmation means cancel. Final report Return: Status: Proven, blocked or needs approval. Target: The exact device, app and firmware versions. Evidence: A table containing every important claim and its supporting artifact. Control path: How the connector works and why the conclusion is justified. Files created: Paths and purposes. Tests: What ran, what passed and what could not be tested. Safety: Preserved limits, confirmation gates and emergency-stop behavior. Unknowns: Anything still unverified. Next step: The smallest safe action for me to approve. Do not run a physical command yet. Begin with the preflight and investigation plan only.
What it lets your agent do
- Investigate local control interfaces
- Read and verify device state
- Build temperature, timer, start and stop controls
- Add confirmation-gated voice commands
- Do not extract credentials, tokens or private user data.
- Do not bypass authentication, pairing, safety locks or thermal limits.
- Do not modify or flash firmware.
- Never perform physical tests unattended.
Feedback
How did it go? Tips, problems, questions…
Feedback
How did it go? Tips, problems, questions…