| name | research-director |
| description | Rank candidate experiments, decide what not to run next, maintain the factory queue, and choose one decisive next research goal before autonomous loops spend compute. |
Research Director
Use when choosing the next research direction, starting a new /goal loop,
reviewing a branch after surprising evidence, or asking whether the research
workspace is still moving toward the right objective.
This skill does not replace research-experiment; it decides which experiment
deserves to be created or run.
Read First
RESEARCH.md
programs/index.yml and the active program cards
OPEN_QUESTIONS.md
CLAIMS.md
DECISIONS.md
experiments/index.yml
- scorecard
Status: lines in factory/scorecards/
- the latest relevant synthesis note under
research-log/
Output Shape
Produce one ranked shortlist, then choose exactly one next move.
1. candidate
expected information gain:
cost:
most likely way it fools us:
what it would prove:
what it would not prove:
Selected next move:
Not next:
Stop/pivot gate:
Factory State
When a candidate is selected, create or update its scorecard under
factory/scorecards/F###_short_name.md with its Program: RP###, mark it
Status: selected, and point the dashboard Goal: line at it. Keep at most
one selected scorecard at a time; the scorecard Status: lines are the
queue.
Ranking normally happens inside the highest-priority active program. Changing
program priorities, pausing a program, or starting a new one is a portfolio
move: record it in the RESEARCH.md router and programs/index.yml, and for
a new program follow the Program Layer checklist in AGENTS.md (card, index
row, first Q###, D### with revisit condition) before writing its first
scorecard.
If the next move is ready for autonomous execution, use plan-research-goal
after this skill and write the prompt into the scorecard's Goal Prompt
section. Program-level LOOP_/BATCH_ prompts still live in
factory/goals/.
Taste
- Prefer one decisive experiment over a broad sweep.
- Prefer tests that can falsify the current favorite idea.
- Penalize experiments that only rename a failed mechanism.
- Do not promote a result until it survives the stress test implied by its
own failure mode.
- Name what should not be run next; this is part of the output, not a footnote.
Anti-Bloat Rule
If RESEARCH.md, CLAIMS.md, or DECISIONS.md have become long ledgers,
choose compress before more experiments as the next move. The factory should
not spend compute while the belief layer is unreadable.