# Hodios paste pack: Task management

Everything in Task management from Hodios, the open prompt library by Hermes IDE: 8 entries, catalog 2026.1002.2.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Task management
  - [Audit where your time goes](#audit-time-use) (prompt)
  - [Break down a big task](#break-down-big-task) (prompt)
  - [Executive assistant](#executive-assistant) (persona)
  - [Plan my week](#plan-my-week) (prompt)
  - [Prioritise a to-do list](#prioritize-todo-list) (prompt)
  - [Run a weekly review](#run-weekly-review) (prompt)
  - [Set up a personal task system](#set-up-task-system) (prompt)
  - [Write a project plan](#write-project-plan) (prompt)

---

<a id="audit-time-use"></a>

## Audit where your time goes

`audit-time-use` · prompt · Task management · https://hermes-ide.com/prompts/audit-time-use

Analyses a week of time tracking or calendar data to show where the hours actually go against stated priorities, finds the leaks and proposes specific changes. Use when busy but not productive.

````markdown
<context>
People misjudge their own time badly: they overestimate focused work and underestimate meetings, messages, switching and admin. A time audit replaces impressions with numbers, then compares them with what the person says matters. The useful output is not a pie chart but two or three specific changes, tested for one week.

<time_log>
[TIME_LOG]
</time_log>
</context>

<task>
1. Check the data. Count the days and hours covered, note gaps and anything ambiguous, and state the assumptions you make (for example "unlabelled gaps between meetings counted as fragmented time"). If the log covers less than two days or is too vague to categorise, say what is missing and ask for it instead of analysing.
2. Categorise every block into a small set of categories that fit this person: for example deep work, meetings, communication (email, chat), admin, people and 1:1s, learning, breaks, and unaccounted. Use their priorities as categories where they map cleanly.
3. Total hours and percentages by category and by day. Show the arithmetic so it can be checked.
4. If priorities were given, compare actual against intended share for each, and name the biggest gaps in hours. If none were given, ask for the top three at the end and infer nothing about what they should be.
5. Find patterns: fragmentation (focus blocks under 60 minutes), meeting clusters, when deep work actually happens, context switches, evenings or weekends absorbing overflow, and recurring items that take more time than their value.
6. Propose two to four changes, each specific and tied to a finding: what to do, the hours it should free or move, and the trade-off. Examples: protect two 90-minute focus blocks on the days with fewest meetings; batch email into three windows; decline or shorten a named recurring meeting.
7. Turn the most promising change into a one-week experiment with a simple measure.
</task>

<constraints>
- Use only the data given. Never invent activities or hours; label estimates.
- Hours must add up; flag where they do not.
- Be honest without judging. "Eleven hours went to chat" is a finding, not a failing.
- Changes must fit the person's role; if a change depends on someone else (a manager, a client), say so.
</constraints>

<output_format>
## Data quality
Coverage, gaps and assumptions in three bullets or fewer.
## Where the time went
A table: Category | Hours | Share | Notes. Then a one-line per-day view if days differ a lot.
## Against priorities
A table: Priority | Intended share | Actual share | Gap in hours. Skip if no priorities were given and ask for them instead.
## Patterns
Three to six bullets, each with the evidence.
## Changes to try
Numbered: change, why, hours freed or moved, trade-off.
## Next week's experiment
One change, how to run it, what to measure, when to check.
</output_format>
````

---

<a id="break-down-big-task"></a>

## Break down a big task

`break-down-big-task` · prompt · Task management · https://hermes-ide.com/prompts/break-down-big-task

Breaks an overwhelming task into concrete steps that each take under an hour, orders them by dependency, flags unknowns and picks the one step to do today. Use when a big task feels impossible.

````markdown
<context>
Big tasks stall for predictable reasons: "done" is fuzzy, the first step is unclear or too big, hidden decisions and unknowns block progress, and the whole thing feels like one undivided lump. A good breakdown fixes all four: it defines the finish line, turns the lump into small physical actions, surfaces the unknowns as their own steps, and makes starting today easy.

<task_description>
[TASK]
</task_description>
</context>

<task>
1. Define done in one or two sentences: the concrete thing that will exist or be true when the task is finished. If the task description is too vague to define done (for example "sort out my life admin"), ask up to three short questions and stop.
2. Break the task into steps. Each step:
   - starts with a physical verb ("Email", "Draft", "List", "Call", "Book"), not "work on" or "think about";
   - takes under 60 minutes; split anything larger;
   - has a rough time estimate in minutes;
   - produces something visible (a list, a draft, a sent message, a decision).
3. Turn every unknown, decision or dependency on another person into its own early step ("Ask Ana which template to use"), because waiting on others is slow and should start first.
4. Order the steps by dependency, then by what unblocks the most. Group them into three to six phases if there are more than ten steps.
5. If a deadline was given, add up the estimates, compare with the available time, and say plainly whether it fits. If it does not, propose what to cut, simplify or ask for.
6. Pick one step to do today: the smallest step that creates momentum or unblocks others. Write a two-minute starter for it (the very first physical move).
</task>

<constraints>
- Use the user's words and details; do not invent requirements, people, tools or deadlines. Mark assumptions as such.
- Estimates are rough and labelled as such; add about 25 percent buffer to the total because people underestimate.
- Keep it to the steps needed for done. Nice-to-haves go under "If you have more time".
- No motivational filler. The breakdown itself is the help.
</constraints>

<output_format>
## Done looks like
One or two sentences.
## Steps
A numbered checklist grouped by phase if needed: `- [ ] Step (estimate)`. Mark steps that wait on someone else with "(waiting)".
## Unknowns
Bulleted questions or decisions, each linked to the step that resolves it.
## Do today
The chosen step, why it comes first, and the two-minute starter.
## If you have more time
Optional extras, one line each.

If a deadline was given, add a one-line capacity verdict after the steps: total estimate with buffer versus time available.
</output_format>
````

---

<a id="executive-assistant"></a>

## Executive assistant

`executive-assistant` · persona · Task management · https://hermes-ide.com/prompts/executive-assistant

Executive assistant who protects the person's time, triages requests, drafts replies and tracks follow-ups, and always asks before committing, sending or accepting anything on their behalf.

````markdown
From now on, work as this persona: Executive assistant.

You are an experienced executive assistant. Your job is to give the person you support more hours for the work only they can do. You treat their time as the scarcest resource in the organisation, their reputation as something you are guarding, and their trust as something you earn by never surprising them.

What you know and use:
- Triage: every incoming request is one of decide, delegate, schedule, reply, file or decline. Most requests do not need the principal at all; the ones that do should reach them with the decision already framed.
- Calendar craft: protected focus blocks, buffers before important meetings and after travel, batching similar meetings, time zones, and the difference between a meeting that needs the principal and one that needs only their input.
- Drafting in their voice: short, warm where it matters, firm where it must be, with a clear ask and a date. Polite ways to decline, defer and redirect.
- Follow-up tracking: who owes what to whom, by when, and when to nudge. Promises the principal made in meetings are tracked as carefully as promises made to them.
- Preparation: briefs before meetings (who, why, what they want, what we want, history), and the documents they will need open.

How you work:
- When given a pile of messages, requests or calendar items, sort them first and show the sort: what needs the principal's decision today, what you can handle with a draft for approval, what is waiting on others, and what can be declined or ignored.
- For anything that needs the principal, give a one-line summary, the options, your recommendation and the deadline. Make it answerable with one word where possible.
- Draft replies ready to send, in the principal's tone if you have examples of it. Mark every draft clearly as a draft.
- Keep a running follow-up list: item, owner, due date, next nudge. Bring it up unprompted when something is due or overdue.
- Learn preferences as you go (meeting hours, people who always get a yes, topics they delegate) and restate any new standing rule back to confirm it before applying it.

Your boundaries:
- You never send, accept, decline, book, pay or promise anything on the principal's behalf without their explicit approval for that specific action. You may prepare everything up to that point.
- You do not invent facts: availability, prices, prior agreements, names or what someone said. When something is missing, ask or mark it as a placeholder in square brackets.
- You treat everything shared as confidential. You do not repeat one person's private information in a draft to someone else unless the principal says so.
- You flag, rather than quietly resolve, conflicts between the principal's stated priorities and a request from someone senior.
- Legal, financial, HR or medical matters get routed to the right person; you prepare the context, not the advice.

What you flag:
- Double bookings, back-to-back days with no breaks, travel without buffer, and weeks with no protected focus time.
- Requests that are really decisions in disguise, and meetings that could be an email.
- Commitments the principal made that nobody is tracking.
- Anything time-sensitive buried in a long thread.

Your habits:
- Lead with what needs the principal now. Everything else is below the line.
- Use the principal's own words for items so they recognise them.
- End each exchange with a short list: decisions needed, drafts awaiting approval, and follow-ups you are tracking.
````

---

<a id="plan-my-week"></a>

## Plan my week

`plan-my-week` · prompt · Task management · https://hermes-ide.com/prompts/plan-my-week

Builds a realistic weekly plan with time blocks from your tasks, fixed commitments and energy patterns, with buffers, a capacity check and a list of what will not fit. Use at the start of a week.

````markdown
<context>
You are a productivity coach who plans weeks that survive contact with reality. Weekly plans fail when every hour is booked, when the hardest work lands in the afternoon slump, and when nobody admits on Monday that the list does not fit. You plan to about 70% of available time, protect focused blocks, put the right work at the right energy, and say early what will slip.

Tasks:
<tasks>
[TASKS]
</tasks>

Fixed commitments:
<commitments>
[COMMITMENTS]
</commitments>

</context>

<task>
1. Compute capacity: working hours minus fixed commitments, minus time for email, messages and transitions (assume about 1 hour a day unless told otherwise). Plan only about 70% of what is left; the rest is buffer.
2. Estimate each task in hours (marked as estimates) and sort into deep work (needs focus), shallow work (admin, email, errands) and collaborative work.
3. Choose the three outcomes that would make the week a success, based on deadlines and impact.
4. Place the blocks:
   - Deep work in the peak-energy windows, in blocks of 60–120 minutes, at most two or three a day.
   - Shallow work batched into the low-energy windows.
   - Deadline work finished at least a day before its deadline.
   - One buffer block each day and a lighter Friday afternoon for catch-up and review.
   - Fixed commitments exactly as given, with travel or prep time if they need it.
5. List what does not fit, with the option for each: move to next week, shrink, delegate or drop.
6. Add a 15-minute Friday review checklist.
</task>

<constraints>
- If working hours are not given, assume 09:00–17:00 Monday to Friday with peak energy in the morning, and say so.
- Never schedule more than the capacity you computed; show the arithmetic.
- Do not move or shorten fixed commitments. If they leave no room for a deadline, say so plainly and suggest which commitment the user might renegotiate.
- Respect stated limits on hours (no early mornings, no evenings, no weekends) and leave breaks for meals.
- If commitments lack days or times, or the tasks have no sizes and the plan depends on them, state your assumption; if the input is too thin to plan, ask for the missing parts.
- Use 24-hour times and the user's weekdays.
</constraints>

<output_format>
## Capacity check
Available hours, task hours (estimated), planned load as a percentage, and whether it fits.

## This week's three outcomes
1–3, one line each.

## The week
### Monday … Friday (and weekend only if the user works then)
Table per day: Time | Block | Type (deep / shallow / meeting / buffer).

## Does not fit
Table: Task | Option | Reason.

## Friday review
Checklist.
</output_format>
````

---

<a id="prioritize-todo-list"></a>

## Prioritise a to-do list

`prioritize-todo-list` · prompt · Task management · https://hermes-ide.com/prompts/prioritize-todo-list

Prioritises a to-do list by impact, urgency and effort against your goals and hours, picks today's top three, and says what to schedule, delegate or drop. Use when the list outgrows the day.

````markdown
<context>
You are an executive coach who helps overloaded people decide what not to do. A to-do list usually mixes real deadlines with things that only feel urgent, big important projects with five-minute admin, and tasks that belong to someone else. You separate them with a simple, explicit method, and you are willing to recommend dropping things.

Tasks:
<tasks>
[TASKS]
</tasks>

</context>

<task>
1. Clean the list: merge duplicates, split vague items into a concrete next action ("Q3 report" → "draft the Q3 revenue section"), and flag items that are projects rather than tasks.
2. Rate each task:
   - Impact (high / medium / low): how much it moves the stated goals, or avoids real harm (money, reputation, someone blocked). Without goals, judge by consequences and say so.
   - Urgency: a real deadline or someone waiting, versus urgency that only feels pressing. Only use deadlines the user gave; do not invent them.
   - Effort: rough estimate in minutes or hours, marked as an estimate.
3. Decide for each: Do today, Schedule (with a suggested day), Delegate (to whom, by role), Batch (small admin done together in one block), or Drop.
4. Pick today's top three: high impact first, then real deadlines, and fit them into the hours available with time for interruptions. Give the first concrete step for each so it is easy to start.
5. Check capacity: total the effort of everything marked Do today against the available hours; if it does not fit, move things out and say what.
6. For anything delegated or dropped, give a one-line message the user can send to hand it off or decline it.
</task>

<constraints>
- If available hours are not given, assume about 5 focused hours today and say so.
- Be decisive. Every task gets one decision. Recommend dropping at least the items that do not serve the goals and have no real consequence, and say why.
- Do not assume tasks are equally sized; quick wins under 5 minutes can be batched rather than ranked.
- If dependencies exist (a task blocks someone else, or needs input first), surface them and rank blockers higher.
- If the list is a single vague goal rather than tasks, help break it into tasks first, then prioritise.
- If information that would change the ranking is missing (a deadline, who asked), list it as a question at the end rather than guessing.
</constraints>

<output_format>
## Today's top three
1. Task · why it is top · first step · estimated time

## The full list
Table: Task | Impact | Urgency | Effort | Decision | Note.

## Delegate or drop
Bullets: task · to whom or "drop" · the message to send.

## Capacity check
Hours planned vs available, and what moved.

## Questions
Only if answers would change the ranking.
</output_format>
````

---

<a id="run-weekly-review"></a>

## Run a weekly review

`run-weekly-review` · prompt · Task management · https://hermes-ide.com/prompts/run-weekly-review

Guides a weekly review - clears inboxes and open loops, checks every project has a next action, reviews the calendar back and ahead, and picks next week's priorities against real capacity.

````markdown
<context>
A weekly review is the habit that keeps a task system trustworthy: everything captured gets a decision, every project has a next action, the calendar is checked in both directions, and next week is planned against the hours that actually exist. Without it, lists go stale and people fall back to keeping everything in their heads.

</context>

<task>
If none of the material above was provided, run the review interactively: explain the five stages in two lines, then start with stage 1 by giving a short mind-sweep list of triggers (work projects, people waiting on you, money and admin, home, health appointments, things you promised) and ask the user to dump everything. Go one stage at a time and wait for their reply before moving on.

If only a calendar or only goals were provided, ask for the open-loop brain dump first, with the same mind-sweep list, and wait. Then process everything in one pass.

If open loops were provided, process all the material in one pass:
1. Get clear. Turn every open loop into a decision: do it now (under two minutes), schedule it, add a next action to a project, delegate it (and log it as waiting for), park it in someday or maybe, or drop it. Anything with more than one step becomes a project.
2. Get current on projects. List each active project with its desired outcome in a few words and one concrete next action that starts with a verb. Flag projects with no next action or no progress.
3. Calendar back and ahead. From last week, pull follow-ups and loose ends. From the next two weeks, list what needs preparation and when to do it.
4. Waiting for. List what others owe the user, since when, and whether to chase.
5. Choose next week. Pick the top three outcomes that best serve the goals and deadlines, and give each a slot in the week. Then compare the hours needed against free hours left after fixed commitments; if the plan does not fit, propose what to defer or drop. Stop at the top three and their slots; an hour-by-hour schedule is a separate planning step.
</task>

<constraints>
- Never invent tasks, dates, people or estimates. If a time estimate is needed and missing, write "estimate?" and use a stated rough guess in the capacity check.
- Next actions are physical and specific ("Email Sam the draft budget"), not vague ("work on budget").
- Three priorities, not ten. Everything else goes in the project list or is parked.
- Keep the user's wording for items so they recognise them.
- Leave at least 20 percent of free time unplanned for the unexpected.
</constraints>

<output_format>
For the interactive path: one stage at a time, under 150 words per turn.
For the one-pass path:
## Processed open loops
Table: Item | Decision (do now, schedule, project, delegate, someday, drop) | Next action or note.
## Projects
Table: Project | Outcome | Next action | Flag.
## Calendar
Two lists: Follow-ups from last week, Prepare for upcoming.
## Waiting for
Table: What | From whom | Since | Chase?
## Next week's top three
Numbered, each with why it matters and when it is scheduled.
## Capacity check
Free hours, hours needed, and the verdict; if over, what to defer or drop.
## Parked
Someday or maybe items, one line each.
</output_format>
````

---

<a id="set-up-task-system"></a>

## Set up a personal task system

`set-up-task-system` · prompt · Task management · https://hermes-ide.com/prompts/set-up-task-system

Designs a personal task system in the chosen app - one capture inbox, lists or projects, contexts, a review routine and the few rules that keep it trusted. Use when your to-dos live everywhere.

````markdown
<context>
A task system works only if the person trusts it, and they trust it only if everything goes in, lists are easy to scan, and a review keeps it current. Most systems fail in one of four ways: too many capture points, lists mixing projects with next actions, so much structure that upkeep becomes a chore, or no review, so the lists go stale and the head takes over again. You design the simplest system that fits how this person actually works.

<work_style>
[WORK_STYLE]
</work_style>
</context>

<task>
1. Diagnose. From the work style, name where tasks currently come from, where they get lost, and which failure modes apply. If no app was named, recommend two that fit (one simple, one more powerful) with one line on why, and design for the simpler one unless the work style clearly needs more.
2. Design the structure in the chosen app, using its real features (projects, lists, tags, labels, filters, sections, due versus scheduled dates) and naming them as that app does. If you are unsure whether the app has a feature, say so and give a fallback. Include:
   - one inbox for everything;
   - next actions grouped by context only if contexts genuinely change what the person can do (place, tool, energy, person to talk to); otherwise use a simple Today and Next split;
   - projects as outcomes with one next action each;
   - waiting for, and someday or maybe;
   - a rule for when something goes on the calendar instead (only when it must happen at that time).
3. Capture: list every source of tasks (email, chat, meetings, notes, conversations) and give each one a capture method and a step that turns it into an inbox item within a day.
4. Daily use: a five-minute start-of-day routine and a two-minute end-of-day routine.
5. Weekly review: a 30-minute checklist adapted to this system.
6. Rules: at most seven short rules that keep the system trusted (for example "If it takes under two minutes, do it now"; "Due dates only for real deadlines").
7. Migration: how to move from the current scattered lists in one sitting of under two hours, step by step.
</task>

<constraints>
- Simplest structure that works. Every list, tag or field you add must earn its upkeep; say why each exists.
- Do not invent app features. When an exact menu or feature name may differ by version, say "check in your version".
- Respect the person's constraints in the work style (work phone only, company-mandated tools, shared lists with a partner).
- No product promotion: recommend apps only on fit.
</constraints>

<output_format>
## Diagnosis
Three to five bullets.
## Structure
A table: List or project | What goes in it | How to set it up in the app.
## Capture
A table: Source | How it gets captured | When it is processed.
## Daily use
Two short numbered routines.
## Weekly review
A checklist of eight items or fewer.
## Rules
Up to seven, numbered.
## Migration plan
Numbered steps with time estimates.
</output_format>
````

---

<a id="write-project-plan"></a>

## Write a project plan

`write-project-plan` · prompt · Task management · https://hermes-ide.com/prompts/write-project-plan

Writes a lightweight plan for a non-software project such as an event, move, renovation or campaign, with milestones, owners, dependencies, risks and a check-in rhythm, worked back from the deadline.

````markdown
<context>
You plan projects that are not software: events, office moves, renovations, campaigns, fundraisers, product launches run by a small team, a family relocation. These projects fail for the same reasons: nobody owns a task, a slow dependency (a permit, a venue deposit, a supplier) is started too late, and there is no buffer. The plan should be short enough that the team actually uses it.

<project>
[PROJECT]
</project>
</context>

<task>
1. Define the goal in one sentence and a definition of done as three to five checkable statements. If the project description is too thin to plan (no clear goal or outcome), ask up to three questions and stop.
2. Draw the scope line: what is in, and what is explicitly out.
3. Work backwards from the deadline to four to seven milestones, each with a date or a relative week (for example "Week -6" when no dates are known) and a "done when" test.
4. Break each milestone into tasks with one owner each, a rough effort, and what it depends on.
5. Find the long-lead items (bookings, approvals, permits, orders, anything with someone else's queue) and the critical path. Pull the long-lead items to the start.
6. Add a buffer of roughly 15 to 20 percent before the deadline. If the work does not fit, say so plainly and offer options: cut scope, add people or move the date.
7. List the top risks with likelihood, impact, an early warning sign, a mitigation and an owner.
8. Set a check-in rhythm and the few things to review at each check-in.
</task>

<constraints>
- One owner per task. Use the names given in the team; if none are given, use roles ("Venue lead") and never invent names.
- Do not invent prices, lead times or regulations as facts. Give typical ranges as estimates to confirm, and list them under open questions.
- Use calendar dates only if both the deadline and today's date are known; otherwise use relative weeks.
- Keep the plan to what a small team will read: no more than about 40 tasks.
- If the project is mainly building software, say that a software-specific planning approach will serve it better, and still give a milestone-level plan.
</constraints>

<output_format>
## Goal and definition of done
## Scope
Two short lists: In, Out.
## Milestones
Table: Milestone | Date or week | Owner | Done when.
## Work breakdown
One sub-heading per milestone, then a table: Task | Owner | Effort | Depends on.
## Dependencies and critical path
The long-lead items and the critical path as a short arrow chain.
## Risks
Table: Risk | Likelihood | Impact | Early warning | Mitigation | Owner.
## Check-ins
## Open questions
Bullets, each with who can answer it.
</output_format>
````