frida-mcp-workflow

name	frida-mcp-workflow
description	Enforce safe Frida 17 MCP operations with strict phase gating. Use when attaching/spawning sessions, writing or loading scripts, applying Java/native hooks, troubleshooting instrumentation failures, or interpreting Frida MCP output. Require docs-first usage and run the mandatory workflow: Idea -> Scripting -> Execution -> Notes.

Frida MCP Workflow

Run these phases in order. Do not skip phases.

Phase 1: Idea

• Define target: process/app identifier, platform, and session type.
• Define objective: what signal/result must be observed.
• Query docs before function use: call search_frida_docs for each non-trivial API/runtime assumption.
• Record 2-5 Doc facts used bullets before scripting.
• Assume Frida 17 semantics only. Do not use Frida 16 assumptions.

Hard stop:

• If docs are missing or ambiguous, narrow the query and retry before scripting.

Phase 2: Scripting

• Prefer saved files over inline scripts.
• Allow inline only for short, read-only probes.
• For hook scripts, require file-based scripts and load_script.
• Declare script_id, purpose, and explicit target list (module/symbol or class/method).
• Add idempotence guard to prevent duplicate install.
• Define teardown path (uninstall RPC export or equivalent).

Script policy:

• If script is more than 25 lines or writes hooks, save it to a file.
• If modifying existing behavior, include rollback logic in the script.

Phase 3: Execution

• Preflight checks before load/execute:
  • session exists and is alive
  • loaded scripts are listed
  • target overlap is checked
• If overlap exists, unload/replace old script before loading new one.
• Do not attach multiple scripts to the same target unless explicitly intentional.
• Prefer one script per purpose (probe, hook, tracer).

Failure handling:

• On Java is not defined, stop retries and re-check docs/runtime assumptions.
• On attach/spawn failures, run diagnostics before retrying instrumentation.
• On oversized docs output, reduce query scope or paginate; do not guess.

Phase 4: Notes

• Persist notes to file after each execution cycle.
• Record:
  • doc facts used
  • script ledger (loaded/unloaded/current active)
  • observed output and verification status
  • errors and root cause
  • cleanup status and next action
• Confirm teardown is complete when ending work.

Required Response Shape

For each task, output four sections in this order:

1. Idea
2. Scripting
3. Execution
4. Notes

Do not run tool calls in Execution before Idea and Scripting are present.