Find a section
AI is most useful for synthesising knowledge: connecting papers, comparing approaches, and organising evidence. The wisdom must come from you: judging what is missing, what may be novel, and which question is worth pursuing. AI can challenge your judgment; it cannot take responsibility for it.
Follow the five stages in our Research Guide. Copy the prompt for your current stage and return to earlier stages when evidence changes.
Set Up a Research Team
Start with one assistant: ChatGPT or Claude. The setup, five research stages, and save prompt work with either. A second assistant, coordinator, or coding tool is optional; add one for a specific need.
| Role | Suggested tool | Responsibility |
|---|---|---|
| Coordinator | Grok Bot, when available | Keep tasks and files current, arrange handoffs, and bring decisions back to you. It has a persistent cloud computer, beyond ordinary Grok chat. Documentation. |
| Research assistant | ChatGPT or Claude | Synthesise literature, propose ideas, and critically review the reasoning. Use a second assistant for an optional independent critique. ChatGPT search · Claude research. |
| Experiment access | OpenRouter, if needed | Access models through an API. Record model, provider, routing, and settings. Routing guidance. |
| Implementation | An AI coding assistant | Implement and check experiments; update the paper alongside the code. Verify what actually ran. |
Use supported integrations and authorised accounts, or pass outputs yourself. Features and access change.
Set Up the Project Once
Use this before your first investigation. If the topic or venue is undecided, start with a working title and a simple paper outline; do not delay reading for a perfect setup. Thesis templates are in Resources.
Set up a research workspace for: [working topic, degree, and project location].
Paper format or target venue, if known: [specify or write undecided].
1. Inspect any existing project first. Reuse its files and preserve existing work.
2. Initialise Git locally. Create or connect a private GitHub repository using
my authorised account and chosen destination when available. If you cannot,
prepare the files locally and give me the exact remaining steps.
3. Create only the folders we need:
paper/ manuscript, references, figures, and template
src/ implementation
experiments/ configurations, protocols, and run logs
results/ shareable outputs and analysis
notes/ research-note.md
Add a README with setup/run instructions and an appropriate .gitignore.
Record dependencies when known; exclude secrets, protected data, and caches.
4. Obtain the current official paper template for the specified venue, or the
programme-required thesis template. Record its source and version/date.
If undecided or unavailable, create a simple manuscript outline and mark
the template choice pending. Do not invent requirements or claim a download.
5. Create notes/research-note.md: a short handoff containing the current question,
closest verified papers, evidence, decisions and reasons, unresolved issues,
and next step. Link the paper, code, and logs rather than duplicating them.
6. Start the paper with background, problem, related work, and planned methods.
Label unknowns and findings pending. Commit the initial setup when possible.
Report what was created, saved, committed, or pushed, and what remains for me.
Do not claim access, execution, or uploads that did not happen.
Keep One Shared Research Note
Use the paper as the project’s source of truth. Keep its research question, methods, evidence, and current claims up to date as you read, code, test, and revise. Ground claims in verified sources and actual results; clearly label plans and untested ideas.
Document every research action in GitHub: what you changed or ran, why, the result, and the next decision. Use commits for code and paper changes, and issues or experiment logs for investigations, failed attempts, and decisions. After each work session, update the paper and link the relevant record. Use a private repository and keep protected data and secrets in approved storage.
The shared research note is notes/research-note.md, a Markdown text file in your project repository—not a page on this website. It is a short handoff with the current question, closest verified papers, evidence, decisions and reasons, unresolved issues, and next step. “Shared” means you, your supervisor, and any assistant work from the same current record. Use this starting template if helpful.
The paper explains the research; GitHub records the work; the note helps you resume.
Save progress: use this short prompt at the end of a work session or before moving to a new conversation.
Update the paper, GitHub record, and notes/research-note.md from this session.
The note is a short handoff, not a second manuscript. Summarise:
- Current research question and closest verified papers, with links.
- Actions taken, results, and supporting files or sources.
- Decisions and reasons, unresolved issues, and the proposed next step.
Separate evidence from assumptions, and plans from completed work.
If you cannot edit or save directly, give me the exact updates to save.
Report what you actually saved and what I still need to do.
Finish with a short handoff I can paste into my next conversation.
1. Idea Generation
Start with a domain, interest, or real problem. Find promising questions by comparing the closest work.
Use notes/research-note.md (or the note I paste): the current question,
verified papers, evidence, decisions, unresolved issues, and next step.
My domain, interest, or observed problem is: [describe it].
My degree, preparation, available resources, and timeline are: [describe them].
Synthesise the evidence and help me find a worthwhile, feasible direction.
Leave the judgment of significance and the final choice to me.
1. Map problems, search terms, and research communities. Prioritise verified
peer-reviewed work, including relevant ACL, CHI, NeurIPS, specialist, and
foundational papers. Include preprints, clearly labelled.
2. Read the closest papers beyond their abstracts. Record the question,
contribution, evidence, limitations, and verified link for each.
Distinguish an author's finding from your own interpretation.
3. Propose directions, then critically review them against verified evidence.
If a second assistant is available, prepare a handoff for an independent
critique. Report who participated; never pretend another model was consulted.
4. Compare proposals: overlap with prior work, important unanswered question,
strongest objection, and smallest useful investigation.
5. Revise through up to three discussion rounds, stopping earlier if another
round adds no meaningful evidence. Do not treat agreement as proof.
6. Present three candidate ideas in a table: problem, closest verified work,
potential distinction, why the answer matters, feasibility, and biggest risk.
Recommend one with trade-offs. Ask me what seems missing and worth pursuing.
Keep the verified-paper comparison and the chosen direction in the shared
research note. Do not claim that an idea is novel before validation.
2. Idea Refinement
Turn the direction into a testable plan. Use thinking tools to expose weaknesses. A pilot helps diagnose feasibility; it does not establish the contribution.
Use notes/research-note.md (or the note I paste): the current question,
verified papers, evidence, decisions, unresolved issues, and next step.
Our chosen direction is: [paste the idea or point to the research note].
Use the verified papers, constraints, and unresolved issues already recorded.
1. Use first principles: define the problem, concepts, and observable measures.
2. Challenge assumptions and simpler explanations. Use systems thinking to trace
feedback loops and second-order effects. Explain what changes the idea.
3. Develop three related research questions, three corresponding objectives,
and three anticipated contributions as one coherent project.
Align them in a table with example methodology and evidence for each.
Label contributions as intended, not demonstrated. If the three questions
make the project too broad, identify the core question and a smaller scope.
4. Plan a first investigation: reproduce a baseline, inspect data, or pilot code
if useful. Report what ran, what it showed, and what it cannot establish.
5. Critically review the plan; optionally seek a second assistant’s critique.
Resolve the main disagreement through
a source, diagnostic test, or supervisor discussion. Avoid needless components.
Deliver the revised question-objective-contribution-method table, the strongest
alternative explanation, feasibility limits, and the proposed next step.
Update the shared research note with the reasoning and any pilot evidence.
3. Idea Validation
Check the distinction against the closest work. Aim for a defensible judgment with clear uncertainty, not certainty that an idea is novel.
Use notes/research-note.md (or the note I paste): the current question,
verified papers, evidence, decisions, unresolved issues, and next step.
Validate this idea: [paste the refined plan or point to the research note].
Target research community or venue: [specify, if known].
1. Search the closest terms, alternative terminology, neighbouring fields,
theories, methods, references, and newer papers citing the closest work.
Prioritise peer-reviewed evidence but include relevant preprints and resources.
2. Verify sources and compare their actual claims, methods, and findings with
ours. Maintain a closest-work table with links and a search date.
3. Take a critic’s perspective and find the strongest counterexample: work that
already answers the question or makes our difference unimportant. Optionally
ask another assistant to check independently; label a self-review honestly.
4. Judge the idea as substantial overlap, a possible distinction needing more
evidence, or a supported distinction within the searched literature.
Explain both novelty and significance; a new combination alone is insufficient.
Present evidence for my judgment, not a model verdict to accept uncritically.
5. If overlap is substantial, refine and search again within an agreed time
budget. Continue while finding closer work or changing the idea; stop at
the budget, a defensible distinction, or a decision to change direction.
6. Report what was searched, the closest counterevidence, the precise difference,
what remains unverified, and whether to proceed, refine, or change direction.
Do not say “definitely novel” or keep looping until models agree.
If the evidence is insufficient, say so and name the next source or test needed.
Update the shared note and the proposed gap statement in the paper.
4. Idea Testing
Design evidence that can answer the question. Learn from closely related studies and test competing explanations.
Use notes/research-note.md (or the note I paste): the current question,
verified papers, evidence, decisions, unresolved issues, and next step.
Develop and carry out a rigorous study for: [plan or research-note location].
Use the validated gap, verified literature, intended claims, and constraints.
1. Compare methods in strong related papers: frameworks, models, tools, tasks,
samples, measures, and analyses. Cite what to reuse, adapt, or reject and why.
2. State clear hypotheses and competing explanations where appropriate.
For experiments, define IVs, DVs, operational measures, confounds, controls,
randomisation, counterbalancing/order effects, and fair comparisons.
For exploratory or design work, use questions, sampling, interpretation,
and credibility checks appropriate to that contribution.
3. Build credible simple and strong relevant baselines. Match information,
training/tuning effort, tool access, and resources as the comparison requires.
Explain construct validity, internal validity, generalisation limits,
sample justification, uncertainty, leakage, and reproducibility.
4. Map each claim to a comparison, measure, analysis, competing explanation,
and limitation. Choose ablations, robustness tests, error analysis, or human
evaluation for a reason. Separate essential from optional work.
5. Reuse the project repository and paper template from setup. Check the README,
dependencies, configurations, and run logs are sufficient to reproduce the work.
6. Work iteratively: write the introduction, related work, and planned methodology;
implement and pilot; inspect evidence; revise the paper and the next experiment.
Keep planned, completed, and exploratory work distinct. Never fill results
with invented numbers or silently change a hypothesis after seeing outcomes.
7. Record what really ran: code/data/model versions, provider and routing when
applicable, prompts, settings, seeds where relevant, outputs, failures, and cost.
Analyse confirming patterns and surprising results. Check bugs and measurement
defects before interpreting an unexpected outcome as a scientific discovery.
8. Design the methodology figure: learn from good examples, propose three
structures, and let me choose. Show the core idea, conditions, components,
relationships, and evidence in an editable figure. Include only supported claims.
9. After each meaningful iteration, update the paper, evidence table, and shared
note. Report the biggest unresolved threat, the next decisive investigation,
and when to narrow, stop, or change the approach with me.
Do not optimise for the number of experiments or for positive findings.
Optimise for evidence that answers the question and tests the strongest alternative.
5. Idea Storytelling
Build the five-part story: background → problem → methodology → findings → contribution/significance. Let writing expose gaps that need further testing.
Use notes/research-note.md (or the note I paste): the current question,
verified papers, evidence, decisions, unresolved issues, and next step.
Help communicate this research: [paper/research-note location and target venue].
Use only verified literature, actual methods, and available results.
1. Write five connected sentences: background, problem, methodology, findings,
and contribution/significance. Use “However” where it clarifies the gap.
If the study is incomplete, write “findings pending”; keep predictions apart.
2. Expand to five short paragraphs. Check whether the problem follows from
the literature, the method answers the question, and the evidence supports
the contribution. Revise weak reasoning before polishing the English.
3. Draft or revise one section at a time in the venue's required structure.
Keep claims, terminology, figures, methods, and numbers consistent across
the paper. Separate interpretation from observation and state limitations.
4. Write a clear, searchable title. For Figure 1, show the problem, insight,
difference from existing practice, and what changes. Learn from verified
examples; offer three concepts for me to choose. Make it editable, original,
and faithful to demonstrated evidence.
5. Review novelty, validity, and communication separately from drafting.
Optionally seek another assistant’s independent critique; label self-review.
For each concern, quote the relevant evidence, explain the consequence,
and suggest a concrete repair. Rank the three most consequential concerns.
6. Revise one concern at a time and recheck it. If a claim needs more evidence,
return to Idea Testing and update both experiments and paper. Do not cover
an evidence gap with persuasive language.
Deliver the story, revisions, evidence gaps, Figure 1, and my next decision.
Update the manuscript and note. Check authorship, AI disclosure, and the venue’s
current AI policy before submission. Never promise publication acceptance.
Optional: Accelerate with Grok Bot
Once your workflow is clear, automate the routine work. Grok Bot has a persistent cloud computer with a browser, files, and terminal; it can continue working while your laptop is closed. Official documentation.
Suggested roles: Grok Bot coordinates; ChatGPT challenges; Claude implements; OpenRouter provides model access for testing. Configure authorised access, or pass the handoffs yourself. OpenRouter is the testing route, not a separate research judge.
Start with one bounded task: specify the inputs, time or compute budget, what “done” means, and when to return for your decision. Review the evidence before expanding the automation.
You remain the researcher. Check sources and results; judge the gap, novelty, significance, and next direction. Faster execution is useful only when the work answers a worthwhile question.
Give Grok Bot this coordinator prompt:
Coordinate this research project: [repository and task]. Read the paper and notes/research-note.md first. The note holds the question, verified papers, evidence, decisions, unresolved issues, and next step. My time/compute budget is: [specify]. Bring research decisions back to me. 1. Check access to GitHub, ChatGPT, Claude, and OpenRouter. Use configured, authorised connections or browser sessions. If unavailable, prepare the exact handoff for me. Never claim a tool was used when it was not. 2. ChatGPT is the challenger. Give it the question, closest verified work, intended claims, study plan, and constraints. Ask for the three strongest objections to novelty, significance, or validity, with evidence and repairs. Request counterexamples and tests that could disprove the claim. 3. Bring me the objections and recommended changes before changing the question, study design, or scope. Record the decision and reasons in GitHub and the note. 4. Claude is the implementer. Give it the agreed plan, acceptance checks, repository, baselines, and constraints. Ask it to implement the smallest useful change, run checks, and report changed files, actual runs, failures, and limitations. Keep the paper's methods aligned with the implementation. 5. Use OpenRouter for the agreed model comparison. Fix a versioned test set, scoring rules, prompts, tool access, and fair resource budgets before testing. Keep development examples separate from held-out evaluation. Record actual model IDs, provider/routing, settings, date, raw outputs, errors, latency, and cost. Analyse repeated runs and uncertainty where relevant; never pick only favourable outputs. Keep API keys outside commits and handoff messages. 6. Return results and implementation details to ChatGPT for critique. Check its objections against sources, code, and logs. Send necessary fixes to Claude within the agreed plan; escalate changes to claims or design to me. Neither assistant's approval establishes novelty or correctness. 7. After each cycle, update the paper, GitHub log, and research note. Distinguish planned, completed, and exploratory work. Report evidence, biggest remaining gap, next proposed action, and the decision needed from me. Run one cycle, then report. Continue only within the agreed task and budget; stop when blocked, over budget, or when a research decision is needed.