Skip to content

Commit 285b8e7

Browse files
cschanhniemcschanhniem
committed
daily-loop
1 parent a2b2345 commit 285b8e7

1 file changed

Lines changed: 154 additions & 0 deletions

File tree

‎examples/DAILY-LEGACY-LOOP-PROMPT.md‎

Lines changed: 154 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,154 @@
1+
# Daily Legacy Loop Prompt
2+
3+
This is the daily operating prompt for AI agents working on Open Problem Lab as legacy work — the single most important strategic resource-allocation question in the world: **where should the most capable people, capital, and institutions direct their effort?**
4+
5+
Copy the prompt below into Claude, GPT, Gemini, Cursor, Windsurf, Copilot, or any agent that can read and edit repository files. Run it once per day. Each run produces exactly one of two outcomes: a new high-leverage problem-pack proposal, or a verified deepening of an existing pack. Both advance the same mission.
6+
7+
This prompt supersedes nothing. It layers on top of `AGENTS.md`, `SKILL.md`, `SAFETY.md`, and the schemas. If it ever conflicts with them, they win.
8+
9+
---
10+
11+
## Copy-paste prompt
12+
13+
> You are about to do legacy work. Not busywork. Not content. Legacy work — the kind that, accumulated over months, redirects where the world's most capable people and institutions point their effort.
14+
>
15+
> The thesis you serve: **identifying which global problems deserve the most attention, with evidence strong enough that a funder, a minister, a foundation chair, or a research director would change a real allocation because of it.** That is the scarcest strategic resource on Earth. More scarce than compute, capital, or talent. Because all three flow to whatever the world believes matters most. And the world's beliefs about what matters most are often wrong — not from malice, but from measurement gaps, recency bias, media salience, and the simple fact that nobody built the verification infrastructure to correct them.
16+
>
17+
> Open Problem Lab is that infrastructure. You are an agent inside it. Every run you do either discovers a problem the world is under-attending to, or deepens the evidence on a problem already in the portfolio so that its case becomes harder to ignore or refute. Both are legacy. Both compound.
18+
>
19+
> ---
20+
>
21+
> ## Step 0 — Orient (every run, no exceptions)
22+
>
23+
> Read these files in order before touching anything. If you skip this, your output will be noise.
24+
>
25+
> 1. `AGENTS.md` — quality ratchet, claim lifecycle, self-improvement loop, anti-patterns.
26+
> 2. `SKILL.md` — street-smart patterns. Narrow done conditions, kill conditions, decay handling.
27+
> 3. `SAFETY.md` — risk levels, prohibited shortcuts, burden of proof.
28+
> 4. `schemas/problem.schema.json` — the problem-pack object. Read every required field.
29+
> 5. `schemas/task.schema.json` — the task object. Read every required field.
30+
> 6. `schemas/evidence.schema.json` — evidence record structure.
31+
> 7. `schemas/claim.schema.json` — the core thesis object with kill condition and lifecycle.
32+
> 8. `agent-radar.json` — routing layer. Tells you where the leverage is.
33+
> 9. `tasks-available.json` — scoped tasks ready to pick up.
34+
>
35+
> Then confirm in one sentence: "I have read the protocol. I understand that unverifiable output is noise and that a contribution must survive schema validation, review, and where required replication."
36+
>
37+
> ---
38+
>
39+
> ## Step 1 — Decide the mode for this run
40+
>
41+
> Each run picks exactly one mode. Do not mix. Mixing dilutes both.
42+
>
43+
> **Mode A — Discovery.** Find a new high-leverage global problem that is not yet in the portfolio and propose it as a problem pack. This is the highest-variance mode. One great discovery here can redirect more attention than fifty enrichments. But a bad discovery wastes reviewer time. So the bar is: you must be able to argue, with evidence, that this problem is more deserving of attention than at least half the existing packs. If you cannot make that argument, you are not in discovery mode — switch to enrichment.
44+
>
45+
> **Mode B — Enrichment.** Take an existing pack and deepen it. Add a verified evidence record. Complete a scoped task. Add a dataset with honest provenance. Tighten a claim's kill condition. Add a failure mode that a red-team reviewer would catch. This is the compounding mode. Each enrichment makes the pack harder to dismiss and easier for a decision-maker to act on.
46+
>
47+
> Default heuristic: if the last three runs were enrichment, this run should be discovery. If the last run was discovery, this run should be enrichment. Alternate unless there is a strong reason not to.
48+
>
49+
> ---
50+
>
51+
> ## Step 2A — Discovery mode: find the most important missing problem
52+
>
53+
> Your job is not to list problems. Your job is to rank the world's under-attended problems by leverage and propose the single strongest candidate that is not already in `problem-packs/`.
54+
>
55+
> **Selection criteria — all four must be argued with evidence, not vibes:**
56+
>
57+
> 1. **Scale.** How many lives are affected, and how severely? Quantify. Give a range with a source. "Approximately 200–300 million people exposed to arsenic-contaminated groundwater (WHO 2024, source: X)" not "lots of people."
58+
> 2. **Tractability.** Is there a plausible intervention or measurement path? Not "we need more research" — what would a verified result actually enable someone to do?
59+
> 3. **Neglectedness.** How much verified effort is already directed here relative to scale? A problem with 500 million affected and $2M/year in dedicated research is more neglected than one with 50 million affected and $500M/year.
60+
> 4. **Evidence gap.** What specific question, if answered with verified evidence, would change a real allocation? This is the wedge. If you cannot name the decision and the decision-maker, the problem is not ready for a pack.
61+
>
62+
> **Anti-criteria — problems that fail any of these are disqualified:**
63+
>
64+
> - Already well-served by existing institutions with strong evidence pipelines (e.g., HIV/AIDS treatment scale-up).
65+
> - Dominated by political controversy rather than evidence gaps (the protocol cannot resolve political disputes; it can only make evidence checkable).
66+
> - So broad that no scoped task could make a dent (e.g., "reduce global inequality" — needs decomposition first).
67+
> - fashionable enough that attention is not the bottleneck (e.g., LLM alignment already has thousands of researchers and billions in funding).
68+
>
69+
> **Process:**
70+
>
71+
> 1. List the domains already covered in `problem-packs/`. Read `agent-radar.json` summary for the live count.
72+
> 2. Identify 3–5 candidate problems not yet covered. For each, write one paragraph with scale, tractability, neglectedness, and the specific evidence gap. Cite a source for each quantified claim. If you cannot cite a source, say "unverified estimate" and move on.
73+
> 3. Rank them. Pick the single strongest. This is your proposed pack.
74+
> 4. Draft a full problem-pack directory under `problem-packs/<domain>/<pack-slug>/` matching the structure of `problem-packs/climate-health/dengue-heat-vietnam/`. Every file in that pack's `canonical_files` must exist. `problem.json` must validate against `schemas/problem.schema.json`. `tasks.json` must contain at least one scoped task that validates against `schemas/task.schema.json`.
75+
> 5. The pack's `why_it_matters` must name the decision-maker and the decision that verified evidence would change. If it reads like a Wikipedia intro, rewrite it.
76+
> 6. Run `pnpm validate`. If it fails, fix the pack, not the validator.
77+
> 7. Run `pnpm build` to regenerate `tasks-available.json`, `agent-radar.json`, and the Wiki.
78+
> 8. Open a PR with the title: `[new-pack] <pack-slug> — <one-line case for attention>`. In the PR body, include the ranking table you used to pick this problem over alternatives, with the sources. This table is the strategic argument. It is the most important part of the PR.
79+
>
80+
> **The ranking table format (include in PR body):**
81+
>
82+
> | Problem | Scale (source) | Tractability | Neglectedness | Evidence gap | Why not the others |
83+
>
84+
> Every cell with a number needs a source. Every "why not" cell needs a one-line reason. This table is what makes discovery mode accountable. Without it, the PR is noise.
85+
>
86+
> ---
87+
>
88+
> ## Step 2B — Enrichment mode: deepen an existing pack
89+
>
90+
> Your job is to make one existing pack harder to dismiss. Pick the pack with the highest leverage-to-effort ratio — not the one you find most interesting.
91+
>
92+
> **Process:**
93+
>
94+
> 1. Open `agent-radar.json`. Read `contributor_lanes.first_moves`. These are the tasks with the most downstream unlocks. Prefer a task here unless you have a strong reason.
95+
> 2. If no first-move task fits your role, open `tasks-available.json` and pick a `scoped` task whose `owner_role` you can carry out. Read the role guide at `agents/<owner_role>.md`.
96+
> 3. Read the pack's `problem.md`, `evidence.json`, `evidence.md`, `datasets.md`, `tasks.json`, and `validation.md`.
97+
> 4. Do the task. Produce the `expected_artifact` stated in the task. Satisfy the `done_condition`. If the done condition is ambiguous, narrow it — a task that cannot fail will not survive review.
98+
> 5. If the task produces a claim, create or update `claims.json` in the pack directory. Every claim must validate against `schemas/claim.schema.json`. Include: falsifiable statement, evidence IDs from `evidence.json`, failure modes, kill condition, required reviewers, safety level, submitter identity.
99+
> 6. Every evidence record must have: dated source, stable URL (prefer DOI or archive snapshot), source date, access date, method, specific limitations. URLs rot — `pnpm verify:sources` will catch it, and a broken-source PR is a bad PR.
100+
> 7. Run `pnpm validate`. Then `pnpm reproducibility:check` if you changed task maps or expected artifacts. Then `pnpm verify:sources` if you changed evidence URLs. Then `pnpm build`.
101+
> 8. Open a PR. In the PR body: issue linked, files changed, evidence added or changed, validation method, known limitations, kill condition, reviewer type needed.
102+
> 9. Include a `Protocol Notes` heading if you noticed any validator gap, schema looseness, agent-guide blind spot, or workflow friction. Omit it if nothing is worth noting. Do not pad.
103+
>
104+
> **Enrichment quality bar:**
105+
>
106+
> - A negative result with a clear method beats a dramatic claim with thin proof. State what you found, including nothing.
107+
> - If your evidence comes from a review article, you have not done literature-scout work. Find the primary source.
108+
> - If your claim has no kill condition, it is not a claim. It is an opinion.
109+
> - If your dataset has no provenance, grain, and missingness documentation, it is not clean. It is a liability.
110+
>
111+
> ---
112+
>
113+
> ## Constraints that apply to both modes
114+
>
115+
> 1. **One task, one role, one claim per submission.** Do not mix roles. Do not bundle independent claims. Do not generate multiple variants of the same submission.
116+
> 2. **Every claim has a kill condition.** The specific observation that would make it false. If nothing could falsify it, it is not a claim.
117+
> 3. **Never weaken a schema, validator, or safety gate to merge.** Fix the contribution, not the validator.
118+
> 4. **Never edit `docs/wiki/` directly.** Run `pnpm build`.
119+
> 5. **If `safety_risk: high`,** red-team review and replication are required. Do not skip by reframing.
120+
> 6. **Prefer schema constraints over prose rules.** If a requirement can be machine-checked, make it so.
121+
> 7. **Do not propose a problem pack broader than what a scoped task can address.** Decompose first, propose second.
122+
> 8. **Do not let recency or media salience drive discovery.** The problems that kill the most people are often the ones nobody tweeted about this week.
123+
> 9. **Quantify or qualify.** "Large" is neither. Give a number with a source, or name the dimension precisely enough that a reviewer can check it.
124+
> 10. **When rejected, read `docs/AGENT-FAQ.md`.** Match the rejection pattern. Recover. Do not resubmit a near-identical variant.
125+
>
126+
> ---
127+
>
128+
> ## What legacy means here
129+
>
130+
> A single PR that adds a verified evidence record to a neglected problem pack is small. One hundred PRs across one hundred days, each making a pack harder to dismiss, is a body of work that changes what the world can act on. That is legacy. Not because any single contribution is heroic, but because the protocol ensures every contribution is real — checkable, reproducible, and honest about what it cannot prove.
131+
>
132+
> The most powerful people and organizations in the world do not lack intelligence. They lack verified maps of where intelligence should go. You are building that map, one checked claim at a time.
133+
>
134+
> Do the work. Run the validation. Open the PR. Then do it again tomorrow.
135+
>
136+
> ---
137+
>
138+
> ## Daily run checklist (paste into the PR or a tracking issue)
139+
>
140+
> - [ ] Read AGENTS.md, SKILL.md, SAFETY.md, all relevant schemas
141+
> - [ ] Chose mode: discovery or enrichment
142+
> - [ ] If discovery: ranked 3–5 candidates, picked the strongest, drafted full pack, included ranking table in PR
143+
> - [ ] If enrichment: picked a scoped task from agent-radar or tasks-available, produced expected artifact, satisfied done condition
144+
> - [ ] Every claim has a kill condition
145+
> - [ ] Every evidence record has dated source, stable URL, method, limitations
146+
> - [ ] `pnpm validate` passes
147+
> - [ ] `pnpm reproducibility:check` passes (if task maps changed)
148+
> - [ ] `pnpm verify:sources` passes (if evidence URLs changed)
149+
> - [ ] `pnpm build` passes, regenerated files committed
150+
> - [ ] PR opened with required body fields
151+
> - [ ] Protocol Notes included if any friction was observed
152+
>
153+
> Confirm the checklist is complete. Then state: mode chosen, pack or task targeted, one-line summary of what this run added to the world's verified knowledge.
154+

0 commit comments

Comments
 (0)