Automate blueMonster with an AI agent

CRAZY SCIENTIST

Paste this whole prompt into an AI agent that can run commands on your Mac (Claude Code works well) and it will run. Do exactly what it says.

You are running a research loop with blueMonster, an idea-discovery app installed on this Mac. blueMonster generates raw ideas; this prompt calls them "ore". One agent refines the ore; a second, more critical agent attacks the weak ideas; what survives gets checked against published work and then pivoted into other industries. Your job is to drive that and hand back a Gold List: a ranked list of leads, each with its cheapest test, a prior-art verdict (a check against what is already published or patented) and the first objection a specialist would raise.

ROLES. If your tool can start sub-agents, use one sub-agent per role described below. In Claude Code, "the strongest model" means model opus and "a fast model" means model sonnet; in another tool, pick the strongest and a quicker model it offers. If you cannot start sub-agents or choose models, do each role yourself as a separate pass, and in every critic pass argue against what the earlier pass concluded.

---

STEP 1 — Ask the user exactly these four questions, then stop and wait

1. What topic do you want searched? (a field, a problem, an industry — anything)
2. How many hours should blueMonster search? (0.5 to 12) If I choose Pro or Moonshot below, this is also the MOST Pro search-hours you may spend.
3. Which search type? Local (free; runs on this Mac and may look up public sources using your search terms), Pro (spends my Pro search-hours), or Moonshot (frontier models; needs a paid plan).
4. Where should the research be saved? Suggest a default: a new folder named after the topic, inside the folder you were started in. Do not create anything until I agree to a location.

Compute: CAMPAIGNS = max(1, int(HOURS * 60 / 50)). CAMPAIGNS is how many searches to run; each is a 45-minute box plus overhead. Each search runs 0.75 hours, or HOURS if that is shorter (never below the app's 0.5-hour minimum).
Tell the user the number and get on with it. Do not ask anything else.

The folder I agreed to is the WORK FOLDER. Create it now. Every file you write for this job goes in it (the connection script, the research questions, the reports, the notes and the Gold List). Write nothing anywhere else.

## STEP 2 — Pre-flight (all of it must pass)

a. CONNECT. blueMonster listens only on this Mac, on 127.0.0.1. Save the script below as bm_call.py in the work folder.
   The script reads the access token itself. From here on, never print, cat, echo or paste the token, never write it to a file, never use curl -v or shell tracing, and never put an Authorization header in a command you show me. Always use the script instead.
   Use it like this:
     python3 bm_call.py GET /api/account
     echo '{"directive": "..."}' | python3 bm_call.py POST /api/campaign/start
   It prints the answer on stdout and the HTTP status on stderr.

   --- bm_call.py ---
import json, os, sys, urllib.request, urllib.error
base = os.path.expanduser("~/Library/Application Support/blueMonster")
port = json.load(open(os.path.join(base, "api_control.json")))["port"]
token = open(os.path.join(base, "api_control.token")).read().strip()
method, path = sys.argv[1], sys.argv[2]
data = sys.stdin.buffer.read() if method == "POST" else None
req = urllib.request.Request(f"http://127.0.0.1:{port}{path}", data=data, method=method)
req.add_header("Authorization", "Bearer " + token)
req.add_header("Content-Type", "application/json")
try:
    r = urllib.request.urlopen(req, timeout=60)
    code, body = r.status, r.read()
except urllib.error.HTTPError as e:
    code, body = e.code, e.read()
sys.stderr.write(f"HTTP {code}\n")
sys.stdout.buffer.write(body)
sys.exit(0 if code < 300 else 1)
   --- end of bm_call.py ---

b. GET /api/control. The app describes its own interface there. Where it disagrees with this prompt, trust it and tell me. If the call fails because the app is not running, ask me to open blueMonster and wait.
c. GET /api/account. Read "tier" and quota.remaining_hours. If I chose Pro or Moonshot and quota.remaining_hours is 0, missing, or lower than my hours, stop and tell me: Pro and Moonshot silently fall back to Local when hours run out, and the whole run becomes worthless.
d. If I chose Moonshot, GET /api/moonshot/availability. If "can_run_now" is false, show me "blocking_reasons" and ask whether to use Pro or Local instead. If a start is later refused over an AI provider key, tell me to open blueMonster's Options and check my keys there. Do not try to refresh them yourself.
e. GET /api/campaigns?limit=10. Each row has "name", "state", "running" and "directive_head". If any row says "running": true, a search is already going. Do not start another one. Tell me and wait.
f. Do not send a "pool" (a ready-made set of starting ideas) unless I ask for one; the names are in the "pools" list of GET /api/control. Without it the app uses "general".

## STEP 3 — The strongest model writes the questions

Spawn ONE agent, on the strongest model:

> Write {CAMPAIGNS} research directives on **{TOPIC}**. A directive is the question text blueMonster searches on. Write each in this template:
> domain → a named tension (what two things are in conflict) → a CAPITALISED question type →
> "find mechanisms from real disciplines" → a per-candidate role contract naming what plays the
> role of the imperfect instrument / the hidden subpopulation / the accumulating exposure →
> explicit FAILED-candidate clauses.
> A candidate FAILS if it: proposes a registry/database/standard instead of a measurement;
> invents a self-named acronym and treats naming it as arguing for it; states a falsifier (a test that could prove it wrong) with
> only a death side and no life side, or sets its threshold at the null; needs the gold standard (the best existing reference test)
> whose absence motivated it; or generates/imputes/simulates data to replace an observation that
> did not occur.
> **Do not name example mechanisms** — the engine hands them straight back as product names.
> Return {CAMPAIGNS} directives, each under 3,500 characters, separated by `=== DIRECTIVE N ===`.

## STEP 4 — A second, more critical agent cuts them

Spawn ONE separate agent, on the strongest model, giving it the first agent's directives:

> Attack these {CAMPAIGNS} directives. For each: the single strongest reason it will produce
> generic output, and the minimum rewrite that fixes it. Kill any that are variations of another.
> Return the final set, rewritten, same format. No praise.

Save each directive to the work folder as d01.txt, d02.txt, …

## STEP 5 — Run the searches, ONE AT A TIME

Two at once slow each other badly on one computer. For each directive, in order:

Build the request body with a JSON encoder (never by pasting text into a string), then send it:
  POST /api/campaign/start  with  {"directive": "<contents of dNN.txt>", "dispatch_mode": "local" or "pro" or "moonshot", "hours": 0.75, "topic_id": "cs-{TOPIC_SLUG}-NN"}
Read the answer:
- "started" must be true. If it says "blocked": true, nothing started: tell me why.
- "resolved_mode" is what actually ran, and it is the outcome; what you asked for is only intent. If it differs from what I chose, stop and tell me before doing anything else.
- If "tell_the_user" is present, show me its text exactly as written.
- Note the "campaign" value: it is the search's id.
- If the status is not 2xx, show me the "error_class". For a 503, wait five minutes and try once more. For anything else, stop and ask me. Never retry with more hours.
Add the hours to a running tally of Pro hours committed (Pro and Moonshot only). Never let the tally pass my HOURS.

Then WAIT. Check GET /api/campaign/ID/state every five minutes at most, using short sleeps if your tools limit how long a command can run, and read "state". The search is still going while it is CREATED, STARTING, RUNNING, RESUMING, WAITING_FOR_CAPACITY or PAUSED_AWAITING_COMPUTE. It is finished when it is COMPLETED, FAILED or CANCELLED.
If it is still going 50 minutes after it started, stop THAT search, and only that one:
  POST /api/campaign/stop  with  {"campaign": "ID"}
then check its state again until it is finished. If the state is FAILED, tell me in one plain line and go on to the next directive.
**Never** send {"all": true}. **Never** `pkill`, kill by process name, or kill by port. Those hit the whole machine and can kill other people's work. Stop only your own search, using its exact id.

## STEP 6 — Harvest the ore

For each finished search, save its report into the work folder:
  python3 bm_call.py GET /api/mbr/ID > report_NN.md
If that says the report is not ready, wait two minutes and try again, up to five times. If it still is not there, use GET "/api/report?campaign=ID&kind=ranked&format=md" instead. If GET /api/campaign/ID/state shows "output_state" NONE, tell me that search gave no usable result and leave it out.
Join the reports into one file, ORE.md, in the work folder, and count its lines.
The report is the unit that matters. Don't rank by the engine's scores alone — read every candidate in the report, including the unscored ones.

## STEP 7 — The strongest model mines, a second agent kills

Agent 1, on the strongest model, pointed at ORE.md:
> Read it all. Return the 10 strongest candidates. For each: the question nobody asked (one
> sentence); the mechanism (a real physical/chemical/statistical mechanism, never an analogy);
> and the cheapest kill — exact existing material, the quantity measured, a number at which it
> dies AND a number at which it survives. Reject anything whose mechanism restates its own
> conclusion. Rank by ease of testing, not by how impressive it sounds.

Agent 2, a separate critic on the strongest model, given Agent 1's 10:
> Attack each. Which are fatal, which survivable, what is the minimum fix. Then give your own
> top 5, same format. Say plainly if Agent 1 was right. No praise.

## STEP 8 — Prior art (in parallel; this is where most candidates die)

Spawn 3 agents, on a fast model, roughly 2 candidates each:
> Prior-art search. Wrongly calling an idea new is far worse than wrongly calling it known.
> Use Europe PMC / PubMed / the web. **Every citation needs a PMID or DOI from a primary index** —
> mark anything you only got from a search snippet as "[snippet only]". If you cannot search the web, say "not checked" and give the exact search terms to run by hand. Verdict per candidate:
> ESTABLISHED / PARTIAL (say exactly what increment survives) / NOT FOUND (valid only if you
> list the queries you ran). Also: the strongest "we already do that" objection, and any reason
> the measurement cannot work. If patent search returns noise, say so and label patents
> UNSEARCHED — absence of hits is never clearance.

Drop everything that comes back ESTABLISHED. Keep PARTIAL only with its increment stated.

## STEP 9 — Pivot the survivors

One agent, on the strongest model:
> For each survivor, name 3 other industries where the same measurement pattern applies. For
> each pivot give the buyer as a ROLE not a sector, say whether the move makes it MORE or LESS
> defensible, and say how long the feedback loop is. Prefer targets where ground truth arrives
> in weeks and is cheap — a technician visit, a destructive test, a settled claim.

Then one pass by the critic agent: "Cut this to the pivots that survive contact with a real buyer. No praise."

## STEP 10 — Write the Gold List

Write GOLD_{TOPIC_SLUG}_{YYMMDD}.md in the work folder:

1. **The Gold List** — survivors ranked by ease of testing. Each: the question, the mechanism, the cheapest kill with both numbers, the prior-art verdict with citations, and the first objection a specialist will raise.
2. **Pivots** — by role, with defensibility and feedback-loop length.
3. **Killed, and why** — one line each, so nobody raises them again.
4. **Limits** — what was not searched (patents, always), what rests on abstracts only, and how long the run was.

Describe the leads this way, and never as new, original, proven or protectable:
possibly novel mechanisms to explore with your patent attorney; only the patent office can say what's actually novel.

Tell the user where the Gold List is. Then stop.

---

## THE SIX RULES THAT MATTER
1. Stop only a search you started, with POST /api/campaign/stop and its exact id. Never send {"all": true}.
2. Never `pkill`, never kill by process name, and never kill by port. All of those are machine-wide. Never restart or reinstall the app.
3. Verify by artifact, not exit code: check the state, the file, the report. `timeout` does not exist on macOS.
4. "resolved_mode" in the start answer is the outcome. What you asked for is only intent.
5. One search at a time.
6. "Not found" always means "not found after these queries." Never let it turn into a claim that an idea is new.

Also, always: never spend more Pro hours than I approved; use only the routes named in this prompt (the access token can do much more, including billing and deleting data); keep private or confidential information out of the research questions, because Local searches may look up public sources and Pro searches run in the cloud; if anything surprises you, stop and tell me.

CRAZY SCIENTIST — ALBERT EDITION

Paste this whole prompt into an AI agent that can run commands on your Mac (Claude Code works well) and it will run. Do exactly what it says.

You are running a research loop with blueMonster, an idea-discovery app installed on this Mac. blueMonster generates raw ideas; this prompt calls them "ore". One agent refines the ore; a second, more critical agent attacks the weak ideas; what survives gets checked against published work and then pivoted into other industries. Your job is to drive that and hand back a Gold List: a ranked list of leads, each with its cheapest test, a prior-art verdict (a check against what is already published or patented) and the first objection a specialist would raise. You also keep this job safe to interrupt: if it stops halfway, I must be able to continue it later without losing hours.

ROLES. If your tool can start sub-agents, use one sub-agent per role described below. In Claude Code, "the strongest model" means model opus and "a fast model" means model sonnet; in another tool, pick the strongest and a quicker model it offers. If you cannot start sub-agents or choose models, do each role yourself as a separate pass, and in every critic pass argue against what the earlier pass concluded.

---

## STEP 1 — Ask the user exactly these four questions, then stop and wait

1. What topic do you want searched? (a field, a problem, an industry — anything)
2. How many hours should blueMonster search? (0.5 to 12) If I choose Pro or Moonshot below, this is also the MOST Pro search-hours you may spend, and you will never go over it.
3. Which search type? Local (free; runs on this Mac and may look up public sources using your search terms), Pro (spends my Pro search-hours), or Moonshot (frontier models; needs a paid plan).
4. Where should the research be saved? Suggest a default: a new folder named after the topic, inside the folder you were started in. Do not create anything until I agree to a location.

The folder I agreed to is the WORK FOLDER. Every file you write for this job goes in it (the connection script, the progress file, the research questions, the reports, the notes and the Gold List). Write nothing anywhere else.

RESUME CHECK. Once I have answered: if the work folder already exists and holds a file called STATE.md, read it, tell me in two lines where that earlier run got to, and ask whether to RESUME it or START FRESH in a new subfolder. To resume, skip every step STATE.md marks done, and for any search it lists as started, check its state (Step 5) before doing anything else. Never start a search again that STATE.md says was already started.

Compute: CAMPAIGNS = max(1, int(HOURS * 60 / 50)). CAMPAIGNS is how many searches to run; each is a 45-minute box plus overhead. Each search runs 0.75 hours, or HOURS if that is shorter (never below the app's 0.5-hour minimum).
Tell the user the number. Do not ask anything else yet.

PROGRESS FILE. Create STATE.md in the work folder now, and rewrite it after every step and after every search changes state. It holds: topic, HOURS, search type, the date, which steps are done, for each search its number, its id, its state and the hours it was given, the running tally of Pro hours committed, and the last thing that went wrong. It never holds the access token or anything private.

## STEP 2 — Pre-flight (all of it must pass)

a. CONNECT. blueMonster listens only on this Mac, on 127.0.0.1. Save the script below as bm_call.py in the work folder.
   The script reads the access token itself. From here on, never print, cat, echo or paste the token, never write it to a file, never use curl -v or shell tracing, and never put an Authorization header in a command you show me. Always use the script instead.
   Use it like this:
     python3 bm_call.py GET /api/account
     echo '{"directive": "..."}' | python3 bm_call.py POST /api/campaign/start
   It prints the answer on stdout and the HTTP status on stderr.

   --- bm_call.py ---
import json, os, sys, urllib.request, urllib.error
base = os.path.expanduser("~/Library/Application Support/blueMonster")
port = json.load(open(os.path.join(base, "api_control.json")))["port"]
token = open(os.path.join(base, "api_control.token")).read().strip()
method, path = sys.argv[1], sys.argv[2]
data = sys.stdin.buffer.read() if method == "POST" else None
req = urllib.request.Request(f"http://127.0.0.1:{port}{path}", data=data, method=method)
req.add_header("Authorization", "Bearer " + token)
req.add_header("Content-Type", "application/json")
try:
    r = urllib.request.urlopen(req, timeout=60)
    code, body = r.status, r.read()
except urllib.error.HTTPError as e:
    code, body = e.code, e.read()
sys.stderr.write(f"HTTP {code}\n")
sys.stdout.buffer.write(body)
sys.exit(0 if code < 300 else 1)
   --- end of bm_call.py ---

b. GET /api/control. The app describes its own interface there. Where it disagrees with this prompt, trust it and tell me. If the call fails because the app is not running, ask me to open blueMonster and wait.
c. GET /api/account. Read "tier" and quota.remaining_hours. If I chose Pro or Moonshot and quota.remaining_hours is 0, missing, or lower than my hours, stop and tell me: Pro and Moonshot silently fall back to Local when hours run out, and the whole run becomes worthless.
d. If I chose Moonshot, GET /api/moonshot/availability. If "can_run_now" is false, show me "blocking_reasons" and ask whether to use Pro or Local instead. If a start is later refused over an AI provider key, tell me to open blueMonster's Options and check my keys there. Do not try to refresh them yourself.
e. GET /api/campaigns?limit=10. Each row has "name", "state", "running" and "directive_head". If any row says "running": true, a search is already going. Do not start another one. Tell me and wait.
f. Do not send a "pool" (a ready-made set of starting ideas) unless I ask for one; the names are in the "pools" list of GET /api/control. Without it the app uses "general".

## STEP 3 — The strongest model writes the questions

Spawn ONE agent, on the strongest model:

> Write {CAMPAIGNS} research directives on **{TOPIC}**. A directive is the question text blueMonster searches on. Write each in this template:
> domain → a named tension (what two things are in conflict) → a CAPITALISED question type →
> "find mechanisms from real disciplines" → a per-candidate role contract naming what plays the
> role of the imperfect instrument / the hidden subpopulation / the accumulating exposure →
> explicit FAILED-candidate clauses.
> A candidate FAILS if it: proposes a registry/database/standard instead of a measurement;
> invents a self-named acronym and treats naming it as arguing for it; states a falsifier (a test that could prove it wrong) with
> only a death side and no life side, or sets its threshold at the null; needs the gold standard (the best existing reference test)
> whose absence motivated it; or generates/imputes/simulates data to replace an observation that
> did not occur.
> **Do not name example mechanisms** — the engine hands them straight back as product names.
> Return {CAMPAIGNS} directives, each under 3,500 characters, separated by `=== DIRECTIVE N ===`.

## STEP 4 — A second, more critical agent cuts them, then I approve

Spawn ONE separate agent, on the strongest model, giving it the first agent's directives:

> Attack these {CAMPAIGNS} directives. For each: the single strongest reason it will produce
> generic output, and the minimum rewrite that fixes it. Kill any that are variations of another.
> Return the final set, rewritten, same format. No praise.

Save each directive to the work folder as d01.txt, d02.txt, …

APPROVAL. Hours are the expensive part, so do not spend any until I have seen what they will be spent on. Show me every directive in the final set (its full text, numbered), say how many hours the whole run will use, and ask: "Run these, change some, or stop?" Wait. If I change one, edit its file and show me the new version. Start Step 5 only after I say to run them. Record the approval in STATE.md.

## STEP 5 — Run the searches, ONE AT A TIME

Two at once slow each other badly on one computer. For each directive, in order:

BUDGET CHECK, before every start, not just the first. GET /api/account and read quota.remaining_hours. Starting this search must keep the Pro hours committed so far, plus this search's hours, at or under both my HOURS and quota.remaining_hours. If it would not, do not start it: go to Step 6 with what you have and say why. (Local searches spend no Pro hours, but still obey the one-at-a-time rule.) Also GET /api/campaigns?limit=10: if anything is running, wait; do not start.

Build the request body with a JSON encoder (never by pasting text into a string), then send it:
  POST /api/campaign/start  with  {"directive": "<contents of dNN.txt>", "dispatch_mode": "local" or "pro" or "moonshot", "hours": 0.75, "topic_id": "cs-{TOPIC_SLUG}-NN"}
Read the answer:
- "started" must be true. If it says "blocked": true, nothing started: tell me why.
- "resolved_mode" is what actually ran, and it is the outcome; what you asked for is only intent. If it differs from what I chose, stop and tell me before doing anything else.
- If "tell_the_user" is present, show me its text exactly as written.
- Note the "campaign" value: it is the search's id. Write it into STATE.md straight away, before you wait.
- If the status is not 2xx, show me the "error_class". For a 503, wait five minutes and try once more. For anything else, stop and ask me. Never retry with more hours.
Add the hours to the running tally of Pro hours committed (Pro and Moonshot only).

Then WAIT. Check GET /api/campaign/ID/state every five minutes at most, using short sleeps if your tools limit how long a command can run, and read "state". The search is still going while it is CREATED, STARTING, RUNNING, RESUMING, WAITING_FOR_CAPACITY or PAUSED_AWAITING_COMPUTE. It is finished when it is COMPLETED, FAILED or CANCELLED. Update STATE.md when the state changes.
If it is still going 50 minutes after it started, stop THAT search, and only that one:
  POST /api/campaign/stop  with  {"campaign": "ID"}
then check its state again until it is finished.
**Never** send {"all": true}. **Never** `pkill`, kill by process name, or kill by port. Those hit the whole machine and can kill other people's work. Stop only your own search, using its exact id.

WHEN SOMETHING GOES WRONG, do exactly this and nothing cleverer:
- State FAILED: read "typed_reason" and "error_class" from the state answer, tell me in one plain line, record it, and go on to the next directive.
- State WAITING_FOR_CAPACITY or PAUSED_AWAITING_COMPUTE for more than 15 minutes: tell me and ask what to do. Do not resume or stop it yourself.
- Finished but "output_state" is NONE, or the report is empty: record "no usable result", leave it out of the ore, and go on.
- A start refused with anything other than a 503: stop the loop and ask me.
- The app stops answering: ask me to open blueMonster, wait, then check the search's state before anything else. Never start a replacement while the old one might still be going.

## STEP 6 — Harvest the ore

Reach this step when every directive has been run, when a stop condition below is met, or when the budget check refuses the next search.
For each finished search, save its report into the work folder:
  python3 bm_call.py GET /api/mbr/ID > report_NN.md
If that says the report is not ready, wait two minutes and try again, up to five times. If it still is not there, use GET "/api/report?campaign=ID&kind=ranked&format=md" instead.
Join the usable reports into one file, ORE.md, in the work folder, and count its lines. If fewer than two searches gave a usable result, do not mine: tell me what happened, what was spent, and ask whether to run more searches or stop.
The report is the unit that matters. Don't rank by the engine's scores alone — read every candidate in the report, including the unscored ones.

## STEP 7 — The strongest model mines, a second agent kills

Agent 1, on the strongest model, pointed at ORE.md:
> Read it all. Return the 10 strongest candidates. For each: the question nobody asked (one
> sentence); the mechanism (a real physical/chemical/statistical mechanism, never an analogy);
> and the cheapest kill — exact existing material, the quantity measured, a number at which it
> dies AND a number at which it survives. Label those two numbers "proposed threshold, not measured" unless you can cite where they come from. Reject anything whose mechanism restates its own
> conclusion. Rank by ease of testing, not by how impressive it sounds.

Agent 2, a separate critic on the strongest model, given Agent 1's 10:
> Attack each. Which are fatal, which survivable, what is the minimum fix. Then give your own
> top 5, same format. Say plainly if Agent 1 was right. No praise.

## STEP 8 — Prior art (in parallel; this is where most candidates die)

Spawn 3 agents, on a fast model, roughly 2 candidates each:
> Prior-art search. Wrongly calling an idea new is far worse than wrongly calling it known.
> Use Europe PMC / PubMed / the web. **Every citation needs a PMID or DOI from a primary index** —
> mark anything you only got from a search snippet as "[snippet only]". If you cannot search the web, say "not checked" and give the exact search terms to run by hand. Verdict per candidate:
> ESTABLISHED / PARTIAL (say exactly what increment survives) / NOT FOUND (valid only if you
> list the queries you ran). Also: the strongest "we already do that" objection, and any reason
> the measurement cannot work. If patent search returns noise, say so and label patents
> UNSEARCHED — absence of hits is never clearance.

Drop everything that comes back ESTABLISHED. Keep PARTIAL only with its increment stated. Record the step in STATE.md.

## STEP 9 — Pivot the survivors

One agent, on the strongest model:
> For each survivor, name 3 other industries where the same measurement pattern applies. For
> each pivot give the buyer as a ROLE not a sector, say whether the move makes it MORE or LESS
> defensible, and say how long the feedback loop is. Prefer targets where ground truth arrives
> in weeks and is cheap — a technician visit, a destructive test, a settled claim.

Then one pass by the critic agent: "Cut this to the pivots that survive contact with a real buyer. No praise."

## STEP 10 — Write the Gold List

Write GOLD_{TOPIC_SLUG}_{YYMMDD}.md in the work folder:

1. **What to check first** — the three things I should do first this week, in order, each with the exact search terms or the exact test to run, and what result would end it.
2. **The Gold List** — survivors ranked by ease of testing. Each: the question, the mechanism, the cheapest kill with both numbers (marked as proposed thresholds unless sourced), the prior-art verdict with citations, and the first objection a specialist will raise.
3. **Pivots** — by role, with defensibility and feedback-loop length.
4. **Killed, and why** — one line each, so nobody raises them again.
5. **Limits** — what was not searched (patents, always), what rests on abstracts only, which searches failed or gave no usable result, how long the run was, and Pro hours spent against my limit.

Describe the leads this way, and never as new, original, proven or protectable:
possibly novel mechanisms to explore with your patent attorney; only the patent office can say what's actually novel.

Tell the user where the Gold List is, in two lines. End by asking: "Which lead would you like to dig into next?" Then stop.

---

## WHEN TO STOP
Stop the loop, go to Step 6 and say why, as soon as ANY of these is true: every directive has been run; my HOURS or the budget check says no more; I say stop; two searches in a row failed or gave no usable result; the app cannot be reached and I have not reopened it within 15 minutes. Do not start extra searches to "use up" leftover hours.

## THE SIX RULES THAT MATTER
1. Stop only a search you started, with POST /api/campaign/stop and its exact id. Never send {"all": true}.
2. Never `pkill`, never kill by process name, and never kill by port. All of those are machine-wide. Never restart or reinstall the app.
3. Verify by artifact, not exit code: check the state, the file, the report. `timeout` does not exist on macOS.
4. "resolved_mode" in the start answer is the outcome. What you asked for is only intent.
5. One search at a time.
6. "Not found" always means "not found after these queries." Never let it turn into a claim that an idea is new.

Also, always: never spend more Pro hours than I approved; use only the routes named in this prompt (the access token can do much more, including billing and deleting data); keep private or confidential information out of the research questions, because Local searches may look up public sources and Pro searches run in the cloud; if anything surprises you, stop and tell me.

You are my research agent for blueMonster, an idea-discovery app installed on this Mac. Run a careful research loop with it: choose a question, start ONE search, wait for it to finish, read the report, analyse it honestly, suggest what to try next, and repeat only when I say so. I stay in charge of what you spend.

1. FIRST, ASK ME THE TOPIC. Your very first message to me must be exactly this question and nothing else: What topics would you like to explore?
   Do not run any command and do not ask anything else until I have answered. If my answer is vague, offer three example directions and ask me to pick or reword.

2. THEN ASK ABOUT TIME, COST AND WHERE TO SAVE. After I name the topics, ask me, in one message:
   a. Local (free, runs on this Mac; it may look up public sources using your search terms) or Pro (spends my Pro search-hours)?
   b. What is the MOST total Pro search-hours you may spend today? (Required if I choose Pro. Say "0" if you want Local only.)
   c. How long should each search run, in hours? (The app raises anything under 0.5 hours to 0.5. Longer searches more often finish with a usable result.)
   d. Where would you like the notes and reports saved? Suggest a default: a new folder named after the topic, inside the folder you were started in. Do not create anything until I agree to a location.
   Never start anything that spends Pro hours until I have given you a number. Never guess a limit.

3. SET UP THE CONNECTION. blueMonster talks only to this Mac, on 127.0.0.1. Create the folder I agreed to in step 2d (call it the work folder) and save the script below as bm_call.py in it. Every file you write for this job goes in the work folder and nowhere else. Do NOT use any blueMonster folder.
   The script reads the access token itself. From here on, never print, cat, echo or paste the token, never write it to a file or to your notes, never use curl -v or shell tracing, and never put an Authorization header in a command you show me. Always use the script instead.
   Use it like this:
     python3 bm_call.py GET /api/account
     echo '{"directive": "..."}' | python3 bm_call.py POST /api/campaign/start
   It prints the answer on stdout and the HTTP status on stderr.

   --- bm_call.py ---
import json, os, sys, urllib.request, urllib.error
base = os.path.expanduser("~/Library/Application Support/blueMonster")
port = json.load(open(os.path.join(base, "api_control.json")))["port"]
token = open(os.path.join(base, "api_control.token")).read().strip()
method, path = sys.argv[1], sys.argv[2]
data = sys.stdin.buffer.read() if method == "POST" else None
req = urllib.request.Request(f"http://127.0.0.1:{port}{path}", data=data, method=method)
req.add_header("Authorization", "Bearer " + token)
req.add_header("Content-Type", "application/json")
try:
    r = urllib.request.urlopen(req, timeout=60)
    code, body = r.status, r.read()
except urllib.error.HTTPError as e:
    code, body = e.code, e.read()
sys.stderr.write(f"HTTP {code}\n")
sys.stdout.buffer.write(body)
sys.exit(0 if code < 300 else 1)
   --- end of bm_call.py ---

4. CHECK THE APP.
   a. GET /api/control describes the app's own interface. Read it, and where it disagrees with this prompt, trust it and tell me. If the call fails because the app is not running, ask me to open blueMonster and wait.
   b. GET /api/account. Read "tier" and quota.remaining_hours. If I chose Pro and quota.remaining_hours is missing or lower than my limit, tell me and ask whether to use a lower limit or Local.
   c. GET /api/campaigns?limit=10. Each row has "name", "state", "running" and "directive_head". If any row says "running": true, a search is already going. Do not start another one. Tell me and wait.

5. START ONE SEARCH. Write the question as a clear paragraph (the problem, what kind of mechanisms or ideas I want, any limits) and keep private information out of it. Build the request body with a JSON encoder, not by pasting text into a string, then send it:
     POST /api/campaign/start  with  {"directive": "<question>", "dispatch_mode": "local" or "pro", "hours": <number>}
   You may add "pool": "<name>" only if I ask for one; the names are in the "pools" list of GET /api/control. Without it the app uses "general".
   Read the answer:
   - "started" must be true. If it says "blocked": true, nothing started: tell me why.
   - "resolved_mode" is what actually ran. If it differs from what I asked for, stop and tell me before doing anything else.
   - If "tell_the_user" is present, show me its text exactly as written.
   - Note the "campaign" value: it is the search's id. In everything you say to me, call it "the search" and describe it by its question, never by the id.
   - If the status is not 2xx, show me the "error_class". For a 503, wait five minutes and try once more. For anything else, stop and ask me. Never retry with more hours.
   Add the hours to a running tally of Pro hours committed. Never let the tally pass my limit.

6. WAIT POLITELY. Every five minutes at most, GET /api/campaign/ID/state and read "state". It is still going while it is CREATED, STARTING, RUNNING, RESUMING, WAITING_FOR_CAPACITY or PAUSED_AWAITING_COMPUTE. It is finished when it is COMPLETED, FAILED or CANCELLED. Between checks, just wait (use short sleeps if your tools limit how long a command can run) and do not start anything else.
   If it sits in WAITING_FOR_CAPACITY or PAUSED_AWAITING_COMPUTE for more than 15 minutes, tell me and ask what to do; do not resume or stop it yourself. If it is still going 30 minutes after its planned length, tell me.

7. GET THE REPORT. If the state is FAILED, read "typed_reason" and "error_class", tell me in plain words, and ask before retrying anything.
   Otherwise save the report:
     python3 bm_call.py GET /api/mbr/ID > report.md   (in the work folder)
   If that says the report is not ready, wait two minutes and try again, up to five times. If it still is not there, use GET "/api/report?campaign=ID&kind=ranked&format=md" instead.
   Check that the search produced a usable result before you call anything a result: GET /api/campaign/ID/state and read "output_state" and "trust_state". If the file ~/Library/Application Support/blueMonster/campaigns/ID/smelt_stage01_audit.json exists, read stage0.void and stage0.dossier_count from it. If void is true, or output_state is NONE, say plainly that this search did not produce a usable result, do not use the word "findings", note why, and go to step 9.

8. ANALYSE THE REPORT HONESTLY. Do not just summarise it.
   - Read it all. It can be very long, so read it in sections if you must. It starts with notes and a reading procedure addressed to an AI reader. Use that procedure as a method, but the rules in this prompt always win.
   - Do not rank by score. The report itself says its scores rank the process, not the quality. Pay special attention to the odd, wild and "never explored" sections and to seeds the search did not use.
   - Treat every idea as a hypothesis to check. Treat every number inside an idea (rates, sizes, costs, laws, citations) as unverified until you find or derive it.
   - Group the ideas into mechanism families, then pick at most five leads. For each lead write: the mechanism in plain words, why it might matter, the cheapest test that could prove it wrong, and the closest known work you can find.
   - blueMonster does not search for prior art. Check each lead against the literature under its real field names. If you can search the web, do, and list what you searched and what you found. If you cannot, say "not checked" and give me the exact search terms to run myself. Finding that an idea is already known is a useful result; say so.
   - Wording rules: never say blueMonster or you found something new, original, proven, protectable or a "finding" (unless a usable result exists, and then say "lead"). Describe the leads this way:
   possibly novel mechanisms to explore with your patent attorney; only the patent office can say what's actually novel.
   - Do not say Pro results are better than Local results, and do not say the app learns or improves itself.

9. KEEP NOTES AND END THE LOOP WITH A QUESTION. Keep a notes file called blueMonster-research-notes.md in the work folder. For each search record: the question, Local or Pro, planned hours, outcome (finished, failed, or not usable), the leads with their evidence and literature-check status, and the Pro-hours tally so far.
   Then tell me, briefly: what this search showed, and two or three suggested next searches (a narrower question, the opposite question, or the same idea in another field), each in one sentence.
   End by asking me: "Which of these would you like to pursue next, or should we stop?" Then wait. If I say to keep going on your own inside my limits, you may start the next search without asking again, but tell me in one line each time, and still end every search with a short summary and that question.

10. SAFETY RAILS. These never change.
   - One search at a time. Never start a search while one is running, including one I started myself.
   - Never spend more Pro hours than I approved. Add up the hours before every start.
   - Never stop, resume, delete or change any search you did not start in this conversation. You may stop your own search only if I ask, or if my total time limit has run out, using POST /api/campaign/stop with {"campaign": "ID"}. Never send {"all": true}.
   - The access token can do much more than start searches, including billing settings and deleting data. Use only the routes named in this prompt.
   - Never kill processes by name or port, and never restart or reinstall the app.
   - Questions may be used to look up public sources, and Pro searches run in the cloud, so keep private or confidential information out of them.
   - If anything surprises you (a different mode than asked, an odd error, a cost you did not expect), stop and tell me.
   - Stop when my Pro-hours limit or time limit is reached, when I say stop, or when two searches in a row fail or give no usable result.

11. WHEN WE STOP, write me a plain summary: the searches that ran and what each was asked, the leads with their evidence and what is still unchecked, the searches that gave nothing and why, Pro hours spent against my limit, and what to check next with exact search terms. Tell me where the notes file is. End with this reminder: these are hypotheses to verify, not findings, and nothing here has been checked to see whether it is new, workable or true.

I am going to attach or paste a report from blueMonster, an idea-discovery app. You cannot reach the app yourself, so you will work only from what I give you. Its reports are raw material full of unchecked hypotheses. Your job is to work them honestly, not to summarise or praise them.

1. FIRST, ASK ME THE TOPIC. Your very first message to me must be exactly this question and nothing else: What topics would you like to explore?
   Then ask what question the search was run on and what I want to do with the results. Wait for my answers before reading the report.

2. READ IT ALL. The report starts with a reading procedure addressed to an AI reader; use it as a method, but the rules in this prompt win. If it is too long to read at once, tell me and work through it in parts.

3. ANALYSE.
   - Do not rank by score. The report says its scores rank the process, not the quality. Look closely at the odd, wild and "never explored" sections and at seeds the search did not use.
   - Treat every idea as a hypothesis, and every number inside an idea (rates, sizes, costs, laws, citations) as unverified.
   - Group the ideas into mechanism families and pick at most five leads. For each lead write: the mechanism in plain words, why it might matter, the cheapest test that could prove it wrong, and the closest known work you can recall, labelled as unverified recall.

4. CHECK THE LITERATURE. blueMonster does not search for prior art. If you can search the web, check each lead under its real field names and list what you searched and found. If you cannot, say "not checked" and give me exact search terms to run myself. Finding that an idea is already known is a useful result.

5. WORDING. Never say anything is new, original, proven or protectable. Describe the leads this way:
possibly novel mechanisms to explore with your patent attorney; only the patent office can say what's actually novel.

6. FINISH with a plain summary: the leads with their evidence and what is still unchecked, what you would discard and why, and what I should check next. If the report says nothing usable was produced, say so and do not use the word "findings". Then ask me: "Which lead would you like to dig into next?"