|
| 1 | +# Agent Bootstrap Prompt |
| 2 | + |
| 3 | +This file is for the human (or scheduler) operating an AI agent. Copy the prompt below verbatim into Claude, GPT, Gemini, or any other coding agent that can read repository files. The prompt orients the agent in one pass and routes it to the canonical guides. |
| 4 | + |
| 5 | +If the agent supports a config file (Cursor, Windsurf, Copilot, Claude Code), it will already auto-detect the right guide. In that case, this prompt is the explicit version of what the config file says. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## Copy-paste prompt |
| 10 | + |
| 11 | +> You are about to contribute to Open Problem Lab, a GitHub-native verification protocol for AI contributions to neglected global problems. Before you do anything else, read these files in order and confirm you understand them: |
| 12 | +> |
| 13 | +> 1. `AGENTS.md` — canonical agent guide. Quality ratchet, self-improvement loop, anti-patterns. |
| 14 | +> 2. `SKILL.md` — street-smart contribution patterns. Narrow done conditions, kill conditions, decay handling. |
| 15 | +> 3. `CLAUDE.md` — quick-reference rules, commands, role guides, schemas. |
| 16 | +> 4. `SAFETY.md` — risk levels, prohibited shortcuts, burden of proof. |
| 17 | +> 5. `docs/AGENT-FAQ.md` — common rejection patterns and how to recover. |
| 18 | +> |
| 19 | +> Then open `tasks-available.json`. It is a machine-readable index of every task with status `scoped`. Each entry has: `pack_id`, `task_id`, `owner_role`, `reviewer_needed`, `safety_risk`, `outcome`, `expected_artifact`, `done_condition`, and pointers to the source files. |
| 20 | +> |
| 21 | +> Pick exactly one task whose `owner_role` matches a role you can carry out. Read the role guide at `agents/<owner_role>.md`. Then read the relevant `problem.md` at the pointer in the task entry. |
| 22 | +> |
| 23 | +> Constraints you must respect: |
| 24 | +> |
| 25 | +> - One task, one role, one claim per submission. Do not mix roles. Do not bundle independent claims. |
| 26 | +> - Every claim must have: dated source with stable URL (prefer DOI or archive snapshot), method, named limitations, kill condition. |
| 27 | +> - Run `pnpm install` once, then `pnpm validate` before opening any PR. If it fails, fix the contribution, not the validator. |
| 28 | +> - Never edit `docs/wiki/` directly — run `pnpm build`. |
| 29 | +> - Never weaken a schema, validator, or safety gate to merge a contribution. |
| 30 | +> - If your contribution is `safety_risk: high`, it requires red-team review and replication. Do not skip these by reframing the task. |
| 31 | +> |
| 32 | +> Workflow: |
| 33 | +> |
| 34 | +> 1. Pick a task from `tasks-available.json`. |
| 35 | +> 2. Open a GitHub Issue using `.github/ISSUE_TEMPLATE/agent-submission.yml` with the task's `task_id`. |
| 36 | +> 3. Make the canonical-file changes needed to satisfy the done condition. Match the structure of the existing pack at `problem-packs/climate-health/dengue-heat-vietnam/` as your calibration sample. |
| 37 | +> 4. Run `pnpm validate`. If it passes, run `pnpm build`. Commit both the canonical-file changes and the regenerated `docs/wiki/` and `tasks-available.json`. |
| 38 | +> 5. Open a pull request linking the Issue. In the PR body, include: issue linked, files changed, evidence added or changed, validation method, known limitations, reviewer type needed. |
| 39 | +> 6. If you noticed any validator gap, schema looseness, agent-guide blind spot, or workflow friction during the task, include a `Protocol Notes` heading in the PR body listing each. Omit the heading if nothing is worth noting — do not pad. |
| 40 | +> |
| 41 | +> When your PR is reviewed: |
| 42 | +> |
| 43 | +> - If approved, your work is done. The reviewer merges. |
| 44 | +> - If rejected, read the rejection. Match it to a pattern in `docs/AGENT-FAQ.md` and recover. Do not resubmit a near-identical variant of the same idea — that is treated as spam. |
| 45 | +> - If a reviewer asks for replication, provide the exact command, input hash, and environment notes needed to rerun your work. |
| 46 | +> |
| 47 | +> Confirm you have read and understood all of the above. Then state the `task_id` you intend to work on and why you picked it. Do not start the work until you have confirmed the task choice. |
| 48 | +
|
| 49 | +--- |
| 50 | + |
| 51 | +## What the prompt is doing |
| 52 | + |
| 53 | +- **Routes the agent to canonical guides first** so it picks up the operating rules before producing output. |
| 54 | +- **Forces a single-task choice** via `tasks-available.json`. Eliminates the "agent generates a 20-bullet plan covering everything" failure mode. |
| 55 | +- **Names the calibration sample** (`dengue-heat-vietnam`) so output matches existing structure. |
| 56 | +- **Bakes in the Protocol Notes convention** so the agent's friction becomes signal, not lost. |
| 57 | +- **Requires confirmation before work starts** — gives the operator a checkpoint to redirect if the agent picked a poorly fitting task. |
| 58 | + |
| 59 | +## Variations |
| 60 | + |
| 61 | +For Claude Code specifically, you do not need this prompt — `CLAUDE.md` is auto-detected. Use this prompt for agents whose harness does not yet support an AGENTS.md / llms.txt convention. |
| 62 | + |
| 63 | +For non-coding agents (research, retrieval, synthesis), prepend: "You will not edit files. Your job is to produce a draft submission matching `schemas/agent-submission.schema.json` that a human can review and convert into a PR." |
| 64 | + |
| 65 | +## Verification |
| 66 | + |
| 67 | +Before considering this prompt good for your loop, test it once end-to-end on a low-risk pack (e.g., a `literature-scout` task on a `safety_risk: low` pack). Confirm the agent: |
| 68 | + |
| 69 | +1. Picks the right files to read. |
| 70 | +2. Picks a task that matches its claimed role. |
| 71 | +3. Produces a submission that passes `pnpm validate`. |
| 72 | +4. Does not invent a new schema field. |
| 73 | + |
| 74 | +If any of those fails, the prompt or the agent harness needs adjustment. |
0 commit comments