iterating-with-ai-and-mcp — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited iterating-with-ai-and-mcp (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Compose HotSwan ships an embedded HTTP MCP server inside the IntelliJ plugin. Any MCP-compatible AI client (Claude Code, Cursor, any tool that speaks Model Context Protocol) can call its tools to drive the iteration loop. The agent edits a Kotlin file, calls hotswan_reload, captures a screenshot of the running device, evaluates the result against the design intent, and decides the next change. Cycle time is comparable to the human loop, a few seconds per iteration, so the agent can converge on a UI tweak without a human steering each step.
This skill teaches the canonical agent loop, the seven MCP tools (verbatim names), and the safety habits (status check first, snapshot wrapping for rollback, fallback to full install for schema changes) that keep the loop reliable.
../../measurement/generating-baseline-profiles/SKILL.md.../understanding-hot-reload-limits/SKILL.md first to classify the edit before reaching for the MCP loop.../preserving-state-across-reloads/SKILL.md before adding an autonomous loop on top.../setting-up-compose-hotswan/SKILL.md.WATCHING.The HotSwan MCP server exposes exactly these seven tools. The agent MUST NOT invent additional tool names.
hotswan_get_status(): returns device, app, and watcher state. Call once at the start of every loop to confirm the agent has a connected target and that the watcher is WATCHING.hotswan_reload(filePaths): explicit reload trigger for the listed file paths. Returns the tier (1 / 2 / 3) that ran. The agent reads the tier to decide whether the previous edit kept the loop fast.hotswan_take_screenshot(): capture the current device screen. Returns image bytes or a path the agent can read back and inspect.hotswan_start_snapshot(): begin a snapshot session. After this call, HotSwan auto-captures a screenshot and source state after every reload, so the agent can roll back to any intermediate variant.hotswan_stop_snapshot(): end the current snapshot session and finalise the history.hotswan_select_variant(): pick a preferred snapshot from the recorded history. Used to roll the source code back to the chosen variant when the agent decides an earlier iteration was the best one.hotswan_build_and_install(): fall back to a full install. Used when the agent detects a schema change (new parameter, constructor change, new resource ID) that the hot reload pipeline cannot handle. Treat this as a fallback, not a default.The canonical agent loop:
Call hotswan_get_status(). If watcher is not WATCHING, surface the issue back to the human and stop. The reload tool will silently no-op if the watcher is not running and the agent will burn cycles wondering why nothing changed on screen.
Call hotswan_start_snapshot() so the loop has a visual record. Each reload inside the session auto-captures, which lets the agent (or the human reviewing afterwards) compare iterations and roll back to any variant.
Edit the Kotlin file using whatever file-edit tool the agent has. Keep the change inside one composable scope when possible so the reload stays in tier 1 (cross-link ../preserving-state-across-reloads/SKILL.md).
Call hotswan_reload(["app/src/main/kotlin/com/example/Foo.kt"]). Read the returned tier. Tier 1 means the loop stayed fast; tier 2 or tier 3 means state was likely lost and the agent should expect to re-establish navigation or transient UI state before the next screenshot.
Call hotswan_take_screenshot(). Compare the returned image to the design intent. If acceptable, exit the loop. If not, return to step 3 with a refined edit.
If the planned next edit changes a function signature, constructor, interface, or adds a new resource ID, call hotswan_build_and_install() to do a full install before continuing. Do not hammer hotswan_reload on a schema-violating edit; the reload tool will report failure and the loop will stall.
When the iteration is acceptable, call hotswan_stop_snapshot(). Optionally call hotswan_select_variant() to roll the source back to a preferred intermediate variant if the final state was not the best one.
// WRONG
1. Edit file
2. Call hotswan_reload
3. Wonder why nothing happened
// WRONG because: HotSwan needs the app running and the watcher in WATCHING state. If neither is true the reload silently no-ops. Always call hotswan_get_status first.// RIGHT
1. status = hotswan_get_status()
2. require(status.watcher == "WATCHING")
3. edit, reload, screenshot, iterate// WRONG (for visual iteration)
edit -> reload -> screenshot -> discard -> repeat
// WRONG because: the agent loses the ability to roll back to a previous variant. Always wrap visual iteration loops in hotswan_start_snapshot / hotswan_stop_snapshot.// RIGHT
hotswan_start_snapshot()
repeat { edit; hotswan_reload([target]); hotswan_take_screenshot() }
hotswan_stop_snapshot()// WRONG
Edit a composable to add a new parameter, then call hotswan_reload.
// WRONG because: parameter additions are a class-schema change. ART rejects the swap and hotswan_reload reports failure. The agent must detect the schema change first and call hotswan_build_and_install instead.// RIGHT
if (editChangesSchema(plannedEdit)) {
applyEdit(target)
hotswan_build_and_install()
} else {
applyEdit(target)
hotswan_reload([target])
}Cross-link ../understanding-hot-reload-limits/SKILL.md for the full list of schema-violating edits.
// RIGHT
status = hotswan_get_status()
require(status.watcher == "WATCHING")
hotswan_start_snapshot()
repeat {
edit_file(target)
result = hotswan_reload([target])
screenshot = hotswan_take_screenshot()
if (accepts(screenshot, intent)) break
}
hotswan_stop_snapshot()The loop has exactly four moving parts: edit, reload, screenshot, evaluate. Everything else is bookkeeping (status check, snapshot wrapping, optional rollback).
hotswan_get_status() at the start of every loop and confirm the watcher state before issuing edits.hotswan_start_snapshot() and hotswan_stop_snapshot() so the agent can revert.hotswan_get_status, hotswan_reload, hotswan_take_screenshot, hotswan_start_snapshot, hotswan_stop_snapshot, hotswan_select_variant, hotswan_build_and_install.hotswan_build_and_install() inside a tight inner loop. It is a fallback for schema changes, not a default; using it as the default destroys the speed advantage of HotSwan.../understanding-hot-reload-limits/SKILL.md so the agent classifies the planned edit before reaching for hotswan_reload.../preserving-state-across-reloads/SKILL.md so the agent recognises when a reload escalated to tier 2 or tier 3 and loses transient UI state.hotswan_get_status() returns WATCHING before the loop runshotswan_reload call reports the tier (1, 2, or 3)hotswan_take_screenshot() returns image bytes the agent can inspecthotswan_stop_snapshot() finalises the sessionhotswan_build_and_install() instead of hotswan_reload/docs/mcp-server)/docs/agent-skill/docs/snapshot~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.