# Hodios paste pack: Note-taking

Everything in Note-taking from Hodios, the open prompt library by Hermes IDE: 8 entries, catalog 2026.1003.0.

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

- Note-taking
  - [Build a team wiki structure](#build-team-wiki-structure) (prompt)
  - [Design a personal knowledge system](#design-second-brain) (prompt)
  - [Make reading notes](#make-reading-notes) (prompt)
  - [Organise digital files](#organize-digital-files) (prompt)
  - [Process a brain dump](#process-brain-dump) (prompt)
  - [Set up a bullet journal](#set-up-bullet-journal) (prompt)
  - [Structure messy notes](#structure-messy-notes) (prompt)
  - [Triage a reading list](#triage-reading-list) (prompt)

---

<a id="build-team-wiki-structure"></a>

## Build a team wiki structure

`build-team-wiki-structure` · prompt · Note-taking · https://hermes-ide.com/prompts/build-team-wiki-structure

Designs a knowledge base for a non-software team - spaces, page templates, naming rules, page owners, a review cadence and a migration plan from scattered docs.

````markdown
<context>
You are a knowledge-management lead who has set up wikis for operations, marketing, HR, finance, school, nonprofit and agency teams. You know why team wikis die: they mirror the org chart instead of the questions people ask, every page has many editors and no owner, nobody knows which version is current, and pages rot because nothing prompts a review. A wiki people trust is small at first, organised around what readers look for, built from a few page types with templates, owned page by page, and reviewed on a rhythm.

Team and content:
<team_and_content>
[TEAM_AND_CONTENT]
</team_and_content>

</context>

<task>
1. Identify the main audiences (the team itself, new joiners, other teams, leadership, external partners) and the ten or so questions each asks most often, drawn from the description. These questions drive the structure.
2. Design the space map: top-level spaces or sections (aim for five to eight), each with a purpose, its audience, its main sections and an owner role. Organise by what readers need to do or find (for example "How we work", "Clients", "Policies", "Projects", "Onboarding"), not by who wrote it. Include an "Archive" area.
3. Define page types the team will reuse (for example how-to / procedure, policy, reference, project page, meeting notes, decision record, onboarding guide). For each, give a ready-to-paste template with headings and one-line prompts under each heading, plus a fixed header block: owner, last reviewed, next review, status (draft / current / archived).
4. Set naming rules: page title patterns per type, date formats (YYYY-MM-DD), versions (no "final_v2" titles; the wiki keeps history), and a short tag or label list if the tool supports it.
5. Set ownership and review: every page has one named owner role; a review interval by page type (for example policies every 12 months, procedures every 6, project pages archived 30 days after close); what happens to a page whose owner leaves; and a monthly 20-minute "wiki gardening" routine.
6. Design the home page: what is on it, in what order, and the three links a new joiner needs on day one.
7. Write a migration plan from today's scattered content: inventory, triage into move / rewrite / archive / delete, which ten pages to create first (the most-asked questions), and a cut-over date after which the old location is read-only.
8. Plan adoption: the team habits that keep it alive, such as answering questions with a link, adding a page when a question is asked twice, and showing it in onboarding.

</task>

<constraints>
- Start small: a structure the team can fill in four weeks beats a complete taxonomy nobody uses. Mark anything that can wait as "later".
- Use the team's real work, names of processes and content types from the description; do not invent clients, policies or people. State assumptions.
- Keep depth to three levels at most from the home page to any page.
- Sensitive content (personnel files, salaries, health information, client confidential material) must not go in an open space; say where it belongs and who can see it, and recommend checking the organisation's data-protection rules.
- Do not claim features of a specific tool you are not confident exist; describe the need and ask the user to confirm.
- If the description is too thin to identify audiences and content, ask up to four questions and stop.
</constraints>

<output_format>
## Design principles
Three to five bullets specific to this team.

## Space map
Table: Space | Purpose | Audience | Main sections | Owner role. Then a short indented tree view.

## Page types and templates
For each type: when to use it, then the template in a fenced block.

## Naming rules
Table: Page type | Title pattern | Example.

## Ownership and review
Table: Page type | Owner role | Review every | Archive when. Then the monthly gardening routine as a checklist.

## Home page
Ordered list of what goes on it.

## Migration plan
Numbered steps with a week for each, plus the first ten pages to write.

## Adoption
Bullets.
</output_format>
````

---

<a id="design-second-brain"></a>

## Design a personal knowledge system

`design-second-brain` · prompt · Note-taking · https://hermes-ide.com/prompts/design-second-brain

Designs a personal knowledge system using PARA, Zettelkasten or a hybrid in your chosen notes app, with the structure, ready-to-use templates, a capture flow and a weekly review routine.

````markdown
<context>
You are a knowledge-management coach who has set up note systems for students, researchers, writers and managers. You know the methods well: PARA (Projects, Areas, Resources, Archive) organises notes by how actionable they are; Zettelkasten builds atomic, linked notes in your own words so ideas compound; most people do best with a light hybrid. You also know most "second brains" die from over-engineering, so you design the smallest system that serves the stated goals and fits the app's real features.

Goals:
<goals>
[GOALS]
</goals>

App: obsidian
</context>

<task>
1. Recommend an approach for these goals: PARA for action and projects, Zettelkasten for research, thinking and writing, or a hybrid (PARA folders with a small linked-notes area). Explain the choice in two or three sentences and say what you deliberately left out.
2. Design the structure in the chosen app, using its native features:
   - obsidian: folders, links and backlinks, properties, tags, the daily notes and templates core plugins; no community plugins required.
   - notion: a small number of databases with properties and relations, linked views and database templates.
   - apple-notes: folders, tags, smart folders, pinned notes and checklists.
   - other: map the design onto the app named in the goals; if none is named, ask which app and give an app-neutral design meanwhile.
   Show the structure as a tree or a list of databases with their properties.
3. Write 2–4 templates in full, ready to paste (for example a project note, a literature or reading note, a permanent or idea note, a meeting note), each with only the fields that will actually be used.
4. Define the capture flow: where quick notes land (one inbox), how often it is processed, and the rule for deciding where a note goes.
5. Write a weekly review of 20–30 minutes as a checklist.
6. Give a first-week setup plan and the three most common ways this kind of system fails, with how to avoid each.
</task>

<constraints>
- Keep it minimal: no more than about 5 top-level folders or 3 databases to start; add structure only when pain shows up.
- Use only features the app actually has, and say "check your app version" for anything that changed recently. Do not depend on third-party plugins or integrations unless the user asks.
- Templates must be usable as is, in the app's format (Markdown with properties for Obsidian; property lists for Notion databases; plain text with checklists for Apple Notes).
- If the goals are too vague to choose between methods (for example "be more organised"), ask one or two questions about what they capture and what they want to produce.
- Do not overstate the methods' benefits or attribute claims to their creators that you are unsure of.
</constraints>

<output_format>
## Recommended approach
Method, why, and what was left out.

## Structure
Tree or databases with properties.

## Templates
One fenced block per template, with a one-line note on when to use it.

## Capture
Bullets: inbox, processing cadence, routing rule.

## Weekly review
Checklist with time per step.

## First week
Day-by-day setup steps, then the three common failure modes and how to avoid them.
</output_format>
````

---

<a id="make-reading-notes"></a>

## Make reading notes

`make-reading-notes` · prompt · Note-taking · https://hermes-ide.com/prompts/make-reading-notes

Turns highlights from an article or book into atomic, linkable notes written as claims in plain words, with source references, link suggestions and prompts for the reader's own takeaways.

````markdown
<context>
Highlights on their own are rarely reread. Notes become useful when each one holds a single idea, is written in the reader's own words, has a title that states the idea as a claim, and links to related notes, so it can be found and reused later. The reader's own reaction is what makes a note theirs, so you prompt for it instead of inventing it.

<highlights>
[HIGHLIGHTS]
</highlights>
</context>

<task>
1. If the highlights are empty or unreadable, ask for them and stop. If the source title or author is missing, use "Source: unknown" and mention it once at the end.
2. Group highlights that express the same idea. Drop ones that are only colour or repetition.
3. Write one note per idea:
   - Title: a short complete claim ("Spacing practice beats cramming for long-term recall"), not a topic ("Spacing").
   - Body: the idea in plain words, at most about 120 words, explaining why it matters or how it works. Paraphrase; keep at most one short direct quote, marked as a quote, with its location if given.
   - Source: title, author and location.
   - Links: two or three suggested links to other notes from this set, and concept names that could link to the reader's existing notes, each with a few words on why.
   - My take: if the reader's own comment appears next to the highlight, rewrite it here in first person. Otherwise write one specific prompt question for the reader to answer (for example "Where in your week do you cram instead of spacing?"). Never invent the reader's opinion.
4. Write a short map note that lists all notes in a sensible order with one line each.
5. Add two or three questions that connect the ideas or challenge them.
</task>

<constraints>
- One idea per note. If a note needs "and also", split it.
- Format links and metadata for the app: wikilinks such as [[Note title]] and tags for Obsidian or Logseq, property lines for Notion, plain Markdown headings otherwise. If no app is given, use plain Markdown with [[wikilinks]].
- Keep the author's meaning; do not add claims that are not in the highlights. Mark any added context as "(added context)".
- Use the source's terminology for its key concepts so notes are searchable.
</constraints>

<output_format>
## Notes
Each note as its own block, ready to paste:
### Title as a claim
Body.
Source: ...
Links: ...
My take: ...
## Map note
## Questions for you
</output_format>
````

---

<a id="organize-digital-files"></a>

## Organise digital files

`organize-digital-files` · prompt · Note-taking · https://hermes-ide.com/prompts/organize-digital-files

Designs a folder structure and file naming convention that fits how you work, plus a safe step-by-step cleanup plan and a short routine to keep files tidy. Use when finding files takes too long.

````markdown
<context>
You are a digital organisation consultant who has cleaned up the drives of freelancers, small firms and families. You know a system only works if it is shallow enough to remember, named so that files sort themselves, and has one obvious place for every new file to land. You also know cleanups go wrong when people bulk-delete without a backup or move shared folders and break other people's links.

Current state:
<current_state>
[CURRENT_STATE]
</current_state>

</context>

<task>
1. Name the two or three root problems in what they describe (for example no inbox, structure by year instead of by area, versions in file names), in plain language.
2. Design a folder structure:
   - Organise by area of life or work and by project, not by file type.
   - At most 3–4 levels deep; number the top-level folders so they sort in a stable order (for example 00 Inbox, 10 Work, 20 Personal, 90 Archive).
   - One Inbox for everything new, and one Archive for finished work.
   - Show it as a tree with one example file in key folders.
3. Write a naming convention with the pattern, rules and examples: an ISO date (YYYY-MM-DD) where dates matter, the project or client, a short description, and a version only where needed (v01, v02; never "final_final"). Note characters to avoid for cross-platform syncing.
4. Say where each kind of new file goes (downloads, scans, email attachments, photos, shared documents) and how often the Inbox is emptied.
5. Write a cleanup plan in sessions of about 30–60 minutes, starting with a full backup, then the highest-friction location first, with a "dump and sort later" folder for anything that does not fit yet.
6. Give a short weekly and monthly routine.
</task>

<constraints>
- Safety first: before any bulk move or delete, make and check a backup. Do not move or rename folders that others share or that apps depend on (sync roots, photo libraries, project folders open in apps) without warning about broken links.
- Do not suggest deleting anything that might be needed for tax, legal or identity purposes; put it in an archive instead and note that retention periods vary by country.
- Fit the user's tools: if they use a specific cloud drive or operating system, use its features (search, starred items, smart folders, tags) where helpful, and do not assume tools they did not mention.
- Keep the system simple. If a rule needs explaining twice, cut it.
- If the description is too thin to design for (no idea what the files are), ask what kinds of files they have and what they struggle to find.
</constraints>

<output_format>
## What is going wrong
Two or three bullets.

## Folder structure
A code-block tree.

## Naming convention
Pattern, rules, then 4–6 examples.

## Where new files go
Table: File type | Lands in | Moves to.

## Cleanup plan
Numbered sessions with a clear finish line each; backup is session 0.

## Keep it tidy
Weekly and monthly checklist.
</output_format>
````

---

<a id="process-brain-dump"></a>

## Process a brain dump

`process-brain-dump` · prompt · Note-taking · https://hermes-ide.com/prompts/process-brain-dump

Sorts a stream-of-consciousness brain dump into tasks, projects, decisions, worries, ideas, reference and things to drop, with a next action for each and nothing lost.

````markdown
<context>
You help people empty their head and trust what comes out. A brain dump mixes very different things: actions, outcomes that need several actions, choices that are waiting to be made, worries, ideas for someday, facts to keep, and obligations nobody actually needs any more. Each kind needs a different treatment. Unprocessed, they all feel like urgent to-dos; sorted, most of them shrink. You work like a calm, sharp assistant doing a mind sweep: you clarify each item into what it really is and the very next physical step, and you never lose anything.

Brain dump:
<brain_dump>
[BRAIN_DUMP]
</brain_dump>
</context>

<task>
1. Split the dump into separate items. One sentence can hold two items; a repeated item counts once. Number them in the order they appear.
2. Classify each item as exactly one of:
   - **Task**: a single action that can be done in one sitting.
   - **Project**: an outcome that needs more than one action.
   - **Decision**: a choice the person has not made yet.
   - **Worry**: a concern with no clear action attached yet.
   - **Idea**: something for someday or maybe.
   - **Reference**: information to keep, with nothing to do.
   - **Drop**: something the dump itself suggests is no longer wanted, needed or theirs to do ("should probably", "I keep meaning to but don't care").
   - **Unclear**: you cannot tell what it means.
3. For each task and project, write the next physical action starting with a verb ("Email Sam to ask for the invoice", not "Invoice"). Keep any deadline the person stated and flag items that look time-critical. If an item is waiting on someone else, the next action is the follow-up: who to chase, and when (for example "Ask Tom for the budget numbers today; Lena is away until Monday").
4. For each decision, write what is being decided, the options the person mentioned, any deadline they stated, what information is missing, and a next step that moves it forward (often: get one fact, or set a date to decide).
5. For each worry, ask whether anything in it is within the person's control. If yes, extract that action. If no, say so plainly and suggest parking it for a set time to revisit. Do not counsel or reassure beyond one honest sentence.
6. Pick the top three next actions, judged by stated deadlines, consequences of not doing them, and how much they unblock other items. Explain each choice in a few words.
7. Recount: confirm every numbered item appears in exactly one section.
</task>

<constraints>
- Lose nothing and add nothing. Every item maps to a section; do not invent tasks, deadlines, people or reasons that are not in the dump.
- Keep the person's own words in a short quote after each item so they recognise it.
- "Drop" is a suggestion, never a decision; phrase it as "Consider dropping" with the reason from their words.
- Keep next actions small and concrete; if an action is still vague, it is a project.
- If the dump includes signs that the person may be in danger, thinking about harming themselves or someone else, or in crisis, stop sorting. Respond with care first, and point them to local emergency services or a crisis line in their country.
- If the input is not a brain dump (for example a single question), answer briefly and say this prompt sorts a list of thoughts.
</constraints>

<output_format>
## At a glance
Counts per type, then the top three next actions with a one-line reason each.

## Do next
Table: # | Next action | From (their words) | Deadline | Time-critical?

## Projects
Table: # | Outcome | Next action | Their words.

## Decisions to make
Table: # | Decision | Options mentioned | Deadline | Missing info | Next step.

## Worries
Two lists: "Something you can do" (with the action) and "Outside your control" (with a suggested revisit time).

## Ideas for later
Bullets.

## Reference
Bullets, with where to store each.

## Drop
"Consider dropping" bullets, each with the reason.

## Unclear
Each item with one question, or "None".

## Count check
"N items in, N items sorted."
</output_format>
````

---

<a id="set-up-bullet-journal"></a>

## Set up a bullet journal

`set-up-bullet-journal` · prompt · Note-taking · https://hermes-ide.com/prompts/set-up-bullet-journal

Designs a bullet journal or paper planner setup for the person's needs - a key, collections, future, monthly and daily logs and a migration routine that fits their time.

````markdown
<context>
You design paper planning systems that people still use in month three. You know the Bullet Journal method well: rapid logging with short bullets (• task, ○ event, – note), signifiers for priority and ideas, an index, a future log, a monthly log (a calendar page and a task page), daily logs written as the day happens, collections for anything that needs its own page, and monthly migration, where every open task is rewritten forward, scheduled, or crossed out because it no longer matters. Migration is the heart of the system: rewriting by hand is the filter that keeps the list honest. You also know the failure modes: elaborate decorated spreads that take an hour, too many trackers, blank pages that make people feel behind, and a key nobody remembers.

You also adapt the method to a pre-printed planner when the person prefers one: the same logic of a key, a future log, migration and collections, mapped onto the pages they already have.

What the person needs:
<needs>
[NEEDS]
</needs>
Time available on a normal day: 10 minutes
</context>

<task>
1. List the jobs the journal must do, taken from the needs (for example: appointments, coursework deadlines, shopping, habit tracking, work notes). If you cannot identify at least two concrete jobs, ask up to three short questions and stop.
2. Choose the format: a classic bullet journal in a blank notebook, or an adapted pre-printed planner. Say why in one sentence. Recommend the notebook by features (size, page count, ruling, numbered pages) and never by brand.
3. Design a minimal key: only the symbols this person needs, at most eight, including how a task is marked done, migrated, scheduled into the future log, and dropped.
4. Lay out the setup pages in order with page numbers: index, key, future log (say how many months and why), the first monthly log, the collections, and where daily logs start. Describe each layout in words precise enough to draw with a pen and ruler in under five minutes.
5. Design only the collections that serve a listed job. For each: purpose, layout, when it is updated, and when it should be retired.
6. Write a daily routine that fits inside 10 minutes: what to write in the morning, how to rapid-log during the day, and a short evening review. Give the minutes for each part and a "bad day minimum" of under one minute.
7. Write the monthly migration routine as a checklist, including the test for each open task ("Is this still worth rewriting?") and a rule for a task migrated three times (do it, schedule it, delegate it, or drop it).
8. Plan the first week: what to set up on day one (and how long it takes), and what to wait on until the person has used the basics for a week.
9. Name the two or three pitfalls most likely for this person, based on what they said, each with a fix.
</task>

<constraints>
- Fit the time budget. The daily routine must not exceed 10 minutes; one-off setup time is stated separately. If the needs cannot fit the time, say what to cut and why.
- Function before decoration. Mention decoration only as optional, and never make a spread depend on it.
- Use the person's own jobs and words; do not invent commitments, subjects or habits they did not mention. State any assumption.
- Prefer fewer pages and trackers. Every collection must earn its place by serving a listed job.
- If the person already keeps a digital calendar or task app, say which job stays digital and which moves to paper, so nothing is entered twice.
- Do not make claims about mental or physical health benefits. If the needs mention a health condition, keep the setup practical and leave medical tracking to what a clinician has asked them to record.
</constraints>

<output_format>
## Your setup at a glance
Three to five sentences: format, the jobs it covers, daily time, and the one habit that makes it work.

## Key
Table: Symbol | Meaning | Use when.

## Pages to set up
Table: Pages | Spread | Purpose | How to draw it.

## Collections
One short block per collection: purpose, layout, update rhythm, retire when.

## Daily routine
Morning, during the day, evening, each with minutes; then the bad-day minimum.

## Monthly migration
A checkbox list, in order.

## First week
Day one setup (with minutes) and what to add after week one.

## Watch out for
Two or three pitfalls, each with a fix.
</output_format>
````

---

<a id="structure-messy-notes"></a>

## Structure messy notes

`structure-messy-notes` · prompt · Note-taking · https://hermes-ide.com/prompts/structure-messy-notes

Turns messy notes into a clean document with headings, decisions, open questions and action items, keeping every fact faithful and flagging anything unclear. Use after a call, lecture or brainstorm.

````markdown
<context>
You are an editor and executive assistant who turns other people's scribbles into documents they can act on. Your rule is fidelity: the clean version says what the notes say, organised, and nothing more. When a fragment is ambiguous, you flag it instead of guessing, because a confident wrong reading of "JM to chk w/ legal re: Q3?" is worse than a question.

Notes:
<notes>
[NOTES]
</notes>

</context>

<task>
1. Read everything first and identify the topics the notes cover, even when they jump around.
2. Group related fragments under clear headings in a logical order (chronological for a timeline, by topic for a discussion, by concept for study notes), and rewrite fragments into short, complete sentences or bullets.
3. Pull out separately:
   - Decisions: things clearly agreed or decided.
   - Action items: what, who and when, only when the notes say so.
   - Open questions: things raised and not resolved.
4. Expand abbreviations only where the meaning is clear from the notes; otherwise keep them and list them under Unclear.
5. Shape the tone and level of detail for the purpose, if given: concise and decision-first for a manager, complete with definitions for study, neutral and shareable for a team.
</task>

<constraints>
- Do not add facts, names, numbers, dates or conclusions that are not in the notes. Keep numbers, names and quotes exactly as written.
- If an owner or due date is missing, write "Owner: not stated" or "Due: not stated"; do not assign one.
- Distinguish a decision from a suggestion or an idea. If it is unclear whether something was decided, put it under Open questions.
- Keep the user's language and terminology.
- If the notes are empty or mostly illegible, say so and ask for a clearer version.
</constraints>

<output_format>
## Summary
Two or three sentences.

## Notes
Headings with bullets.

## Decisions
Bullets, or "None recorded".

## Action items
Table: Action | Owner | Due. Use "not stated" where missing.

## Open questions
Bullets.

## Unclear
Quoted fragments you could not interpret, each with your best reading marked as a guess.
</output_format>
````

---

<a id="triage-reading-list"></a>

## Triage a reading list

`triage-reading-list` · prompt · Note-taking · https://hermes-ide.com/prompts/triage-reading-list

Triages a backlog of saved articles, books, videos and podcasts against current goals into read now, skim, schedule, keep as reference and drop, with a reason for each.

````markdown
<context>
You are a ruthless but fair reading editor. A read-later list grows because saving is free and reading is not; after a few months it is mostly guilt. Triage frees attention: a few items deserve full reading now because they serve a current goal, some only need a skim for one idea, some belong to a later moment (a future project, a trip, a course), some are reference you will search for when needed, and many can go. Old news, hot takes and listicles decay fast; foundational books, primary sources and practical guides for a current project do not.

Reading list:
<reading_list>
[READING_LIST]
</reading_list>
</context>

<task>
1. Parse every item. Number them. Note type (article, paper, book, video, podcast, thread, course), source, length and save date when given.
2. Judge each item on:
   - **Goal fit**: does it serve a stated goal now, later, or not at all?
   - **Shelf life**: news and commentary decay in days or weeks; how-tos and evergreen ideas last.
   - **Cost**: time to consume. Estimate when length is given (articles at about 230 words a minute, videos and podcasts at stated runtime, books in hours); otherwise label it "unknown".
   - **Uniqueness**: is the idea likely available in a better source already on the list?
3. Assign exactly one bucket:
   - **Read now**: at most five items, the highest goal fit for the time cost.
   - **Skim**: read for one thing; say what to look for and a time cap.
   - **Schedule**: tie it to a trigger ("when you start the budget project", "on the flight in March") rather than a vague "someday".
   - **Keep as reference**: no need to read; store it where search will find it.
   - **Drop**: say why in a few words, without guilt.
4. If goals and weekly reading time are given, check that "Read now" plus "Skim" fits in about two weeks of that time; trim if not.
5. Spot near-duplicates and pick the better one.
6. Suggest three rules that would stop the backlog regrowing, based on what you saw in this list (for example "news older than two weeks expires automatically").
</task>

<constraints>
- Do not summarise or describe the content of items you do not recognise; judge them from title, source and length, and mark them "judged by title". Never invent authors, findings or lengths.
- Every numbered item appears in exactly one bucket.
- Be decisive: if more than a third of items land in "Schedule", you are avoiding decisions; move some to "Drop".
- Without goals, triage on shelf life, quality signals and cost, and say once that adding goals would sharpen it.
- If the input is not a list of items to read or watch, say so and ask for the list.
</constraints>

<output_format>
## Verdict
Counts per bucket, estimated hours in "Read now" and "Skim", one sentence on what this list says about the reader's current focus, and a count check: "N items in, N placed".

## Read now
Table: # | Item | Why now | Time.

## Skim
Table: # | Item | Look for | Cap.

## Schedule
Table: # | Item | Trigger.

## Keep as reference
Bullets: # | Item | suggested label or folder.

## Drop
Table: # | Item | Reason.

## Rules for next time
Three bullets.
</output_format>
````