hermes

Plan a PhD or long research project timeline

Builds a PhD or multi-year research project timeline with phases, milestones, a chapter and paper plan, buffers and a monthly check-in routine, working back from the end date. For doctoral students.

context

Doctoral projects overrun for predictable reasons: ethics and access approvals take months, data collection slips, analysis reveals problems that send work back, journal review and revision cycles take three to twelve months, and writing up is underestimated. A useful plan works back from the hard end date (usually funding or submission), puts the slow external dependencies early, writes continuously instead of saving writing for the end, turns chapters into papers when the programme allows, and holds an explicit buffer. A milestone only helps if it has a date and a done-criterion someone else could check.

task

Build a timeline for this project.

project

Dates: Only if [REQUIREMENTS] is given:

requirements

  1. Establish where the project stands today: the current month (if it is not in the input, ask for it and plan from the assumption you state) and what is already done. Then compute the months remaining, convert to full-time equivalent if part-time or with teaching or a job, and state your assumptions about anything missing.
  2. Work back from the end date: reserve the final submission and examination period, then a dedicated write-up and revision phase (normally at least six months full-time equivalent), then a buffer of roughly 15 to 20 percent of the remaining time, then fit the research phases into what is left.
  3. Lay out phases (for example foundations and review, approvals and pilot, study or work package 1, 2, 3, synthesis and write-up), putting slow dependencies such as ethics, data access, fieldwork seasons, equipment or recruitment as early as they can go.
  4. Set milestones with a month and a done-criterion: programme reviews, approvals, data collection complete, analysis complete, chapter drafts to supervisor, paper submissions, final draft, submission.
  5. Map chapters to papers: for each paper, its source chapter or study, target submission month, and a realistic acceptance horizon. If the programme requires published papers, check whether the review cycles fit and say if they do not.
  6. Identify the top risks with an early warning sign and a fallback (a smaller study, secondary data, a dropped chapter).
  7. Give a monthly check-in routine: the questions to answer, what to bring to the supervisor, and when to re-plan.
  8. List concrete tasks for the next 90 days.
constraints
  • Do not invent programme rules, deadlines or required numbers of papers. Use what the user gave, and mark the rest as [CHECK WITH PROGRAMME].
  • If the plan does not fit in the time available, say so at the top and give options (descope, extension, thesis format change) rather than compressing everything into an impossible schedule.
  • Plan for a sustainable workload: no schedule that assumes evenings and weekends as standard capacity, and include leave.
  • Keep the plan supervisor-ready: plain dates (month and year), no motivational filler.
output format

Assumptions

Bulleted, including the current month used and FTE months remaining.

Phase plan

A table: phase | months | goals | deliverables. Then a text Gantt with one row per phase and one column per quarter.

Milestones

A table: month | milestone | done when.

Chapter and paper plan

A table: chapter | source study | paper? | target journal type | submit by.

Buffers and risks

A table: risk | early warning | fallback.

Monthly check-in

The routine and its questions.

Next 90 days

A checklist.

2 required values still a placeholder; the assistant will ask for them.

details

kind
Prompt: a task you run by name to get one finished thing back
domain
Research and science
category
Research methods
level
Intermediate
made for
Student, Researcher / scientist
risk
read-only
version
v1.0.1 · incubating
reviewed
2026-10-03
works in
Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai

Edit on GitHubReport a problem

use in

Hodios CLI
npx @hermes-hq/hodios install plan-phd-timeline --target claude-code
Agent Skills
npx skills add hermes-hq/hodios-dist --skill plan-phd-timeline -a claude-code
Add the Hodios marketplace (once)
claude plugin marketplace add hermes-hq/hodios-dist
Install the research-science plugin
claude plugin install hodios-research-science@hodios

The plugin brings every entry in this domain at once.

PromptScientific writing

Plan a thesis structure

Plans a thesis or dissertation structure with each chapter's purpose, the argument flow, word budgets and a writing timeline working back from the deadline. For graduate students.

plan-thesis-structure
PromptResearch methods

Refine a vague topic into a research question

Refines a vague topic into researchable questions using FINER and PICO-style frameworks, with variants by scope, feasibility notes and the literature to check first. For students and researchers.

refine-research-question
PromptScientific writing

Write a research proposal

Writes a research or grant proposal section (aims, significance, approach, timeline) mapped to the funder's criteria, with placeholders instead of invented data. Use for grant or thesis proposals.

write-research-proposal
PromptScientific writing

Shortlist target journals for a manuscript

Shortlists journals for a manuscript by scope, audience, article type, open-access costs and timelines, ranked in tiers, with facts to verify on each journal's site. For authors before submission.

choose-target-journal
PersonaScientific writing

Thesis advisor

Acts as a thesis advisor who sharpens the research question, keeps scope realistic, pushes for a clear contribution and sets milestones, with direct, supportive feedback. For graduate students.

thesis-advisor
PromptResearch methods

Build a qualitative codebook

Builds a codebook and coding procedure for qualitative data, with definitions, inclusion and exclusion rules, verbatim examples and an inter-rater check. Use before coding interviews or open text.

build-qualitative-codebook