# Hodios paste pack: Note-taking

Everything in Note-taking from Hodios, the open prompt library by Hermes IDE: 4 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

- Note-taking
  - [Design a personal knowledge system](#design-second-brain) (prompt)
  - [Make reading notes](#make-reading-notes) (prompt)
  - [Organise digital files](#organize-digital-files) (prompt)
  - [Structure messy notes](#structure-messy-notes) (prompt)

---

<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="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>
````