Skip to content
cccskills
FreePublished on GitHub

audio-video-capture

Plan and use user-consented local camera and microphone observations for an explicitly authorized physical target. Use when a capture can establish a bounded physical-state observation such as whether a test fixture changed state, an instrument reading changed, or equipment noise changed relatively.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md5.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Audio / Video Capture

Status: not yet shipped. The user-facing media controls described below (Capture photo / Record video / Record audio) are not implemented in the product UI yet — the capture adapter exists only as a library (src/lib/media-capture) with no renderer wiring. Until that lands, do not direct users to media controls that do not exist; treat this document as the design reference for the planned flow.

Use this skill only for an explicitly authorized physical Target. Capture is a user-driven feature of the visible browser or packaged Electron renderer: the renderer uses navigator.mediaDevices, owns permission prompts and recording controls, and uploads accepted media through the normal Evidence path. It is not an MCP or autonomous agent capability — the browser tool policy classifies capturePhoto/startVideoStream/startAudioStream as mutating agent actions, so they are intentionally unavailable to the agent. Capture is an observation capability, never a physical-control capability.

Preconditions

  1. Record the physical Target, location or fixture identifier, owner/authorization, purpose, allowed camera or microphone source, observation window, retention expectation, and stop condition.
  2. Ask the user to initiate this exact capture in the visible media controls. The saved Evidence record must bind the authorized Target; a generic “watch/listen” instruction is insufficient.
  3. Confirm that people are not unintentionally captured. Do not capture private conversations, neighboring property, credentials, screens, faces, or bystanders. Reposition, mask, or stop when the scene is not suitable.
  4. State the hypothesis in observable terms. Example: “the latch is visibly disengaged” or “fan noise is lower relative to the pre-change baseline.” Do not infer a physical action succeeded merely because a control endpoint reported success.

Renderer Controls

The user selects the exact authorized physical target locator/fixture ID and a locally permissioned device. The agent may explain what evidence would be useful, but it cannot select a device, grant media permission, or start recording.

ControlUseBound
Capture photoOne still frame to document a visible state or instrument reading.Prefer one frame; capture another only when the state changed.
Record videoShort, bounded observation of a transition.1–60 seconds; stop as soon as the proof bar is met.
Record audioShort, bounded relative acoustic observation.1–60 seconds; report relative change, not identity or speech content.

Do not use capture controls to actuate locks, doors, alarms, appliances, or other physical equipment. Remote physical control is a separate, explicitly approved integration and is outside this skill.

Capture Procedure

  1. Capture a baseline only if it is necessary to compare the same source, placement, and environmental conditions.
  2. Use the smallest capture that can test the hypothesis. Start with capturePhoto; use video only for motion/state transitions and audio only for a non-speech relative signal.
  3. Save media as an Evidence Artifact with capture time, source ID/label, target, capture duration, MIME type, hash, relevant placement notes, and any framing/cropping applied at capture. Preserve the original media exactly; never save an altered copy in its place. Uploads route through the Evidence Interface (src/server/evidence/artifact-service.ts), which enforces custody byte caps: verify an artifact ID comes back; if the capture exceeds the cap or the upload fails, treat it as unsaved evidence and say so.
  4. Describe what is directly observable, separate from interpretation. Example: “the frame shows the door gap unchanged at the end of the 15-second window”; not “the door is locked.”
  5. Stop immediately on unexpected people, speech, scope drift, a safety concern, or sufficient evidence. Do not keep a continuous stream running.

Interpretation

  • Treat a honeypot or control-system acknowledgement as a separate signal, not proof of a physical outcome.
  • For temperature/infrared instruments, record the instrument type, emissivity/range settings when relevant, angle/distance, timestamp, and baseline conditions. Do not claim calibrated measurements from an uncalibrated camera.
  • For fan/equipment audio, compare only relative level or spectral change under matched placement and ambient conditions. Do not identify speakers, transcribe speech, or derive health/identity inferences.
  • Report uncertainty, alternate explanations, and the next lowest-risk observation if evidence is ambiguous.

Evidence Record

Include: target and authorization ID, user capture confirmation, source ID, capture type, started/ended timestamps, duration, content type, artifact hash/ID, direct observation, environmental notes, and stop reason. Link the artifact to the relevant task or finding rather than embedding raw media in a chat summary.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Plan vulnerability research using conventional bug-hunting and pentest stage names, specialty playbooks, and a research-hypothesis-experiment loop. Use when designing a bug bounty workflow, selecting tools and strategies, building a decision tree, or turning a target/scope into a staged hunting plan.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Passive code-review lane for authorized repositories, local checkouts, uploaded source archives, and diffs. Use when the security research agent needs deterministic candidate discovery before expensive AI investigation, scoped PR-style review, append-only evidence records, or independent revalidation of code findings.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Run independent, task-matched expert attempts, select a base, and synthesize the strongest result.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Select established CTF and security-research tools for authorized artifact triage, web inspection, reversing, crypto, forensics, networking, and exploit validation. Use when a user provides a CTF-style tool catalog, asks which tools to use, or needs safe usage instructions for common offensive/security tools.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Autonomous driver loop for ExploitHunter vulnerability-research campaigns. Runs breadth-first waves of research lanes on rented hosts with no per-request human approval, steers lanes via the shared Investigation Graph (demoting dead ends, respawning on high-signal priorities), saturates host capacity, and enforces wave/budget/safety discipline. Use when driving a multi-target bug-hunting campaign, launching parallel research lanes, or resuming a campaign from a state snapshot.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

See all skills by justsml

Report a problem with this skill