# Hodios paste pack: Assistant setup
Everything in Assistant setup 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
- Assistant setup
- [Build project instructions](#build-project-instructions) (prompt)
- [Candid feedback rules](#candid-feedback-rules) (rule)
- [Write a memory profile for your assistant](#write-memory-profile) (prompt)
- [Write custom instructions](#write-custom-instructions) (prompt)
---
## Build project instructions
`build-project-instructions` · prompt · Assistant setup · https://hermes-ide.com/prompts/build-project-instructions
Writes project-level instructions and a knowledge-file outline for a recurring project in an AI assistant, with a playbook for each repeated task and test prompts.
````markdown
Many assistants let people group conversations into a project with standing instructions and uploaded reference files. The pattern works when the two are split well: instructions describe behaviour (how to do each recurring task, what to check, what to ask), and knowledge files hold facts that change (style guide, product details, past examples). Instructions stuffed with facts go stale; files with no instructions pointing to them get ignored.
[PROJECT]
1. List the assumptions you are making. If the project is too vague to write useful instructions (no purpose or audience), ask up to three questions and stop.
2. If no recurring tasks are given, infer the three most likely from the project and label them as inferred.
3. Write the project instructions:
- Purpose and audience in two or three sentences.
- Standing rules that apply to everything (voice, terminology, units, things never to do), each with a short reason when it is not obvious.
- A short playbook for each recurring task: inputs to expect, steps, which knowledge file to check first, the output format, and the definition of done.
- What to do when information is missing: which questions to ask, or which assumptions are acceptable and must be labelled.
- How to use the knowledge files: refer to them by file name, prefer them over general knowledge, and say when a file does not cover a question.
4. Outline the knowledge files: names, what each contains, why the assistant needs it, and who updates it and when. Suggest a template or headings for any file the user would need to create.
5. Add a maintenance note: what to update when, and signs the instructions need revising.
6. Write four or five test prompts, including one per recurring task and one the files do not cover.
- Keep instructions model-agnostic and under about 800 words; move facts into files.
- Use placeholders such as [BRAND_COLOURS] for facts you do not have. Never invent names, figures or policies.
- Do not recommend uploading secrets, credentials or personal data the tasks do not need; if the project involves people's personal data, suggest minimising or anonymising it.
- Write the instructions in second person, addressed to the assistant.
## Assumptions
## Project instructions
Fenced code block, ready to paste.
## Knowledge files
Table: File | Contents | Why the assistant needs it | Owner and update rhythm. Then any templates as short heading lists.
## Maintenance
## Test prompts
Table: Prompt | Tests | Good result.
````
---
## Candid feedback rules
`candid-feedback-rules` · rule · Assistant setup · https://hermes-ide.com/prompts/candid-feedback-rules
Standing rules that make an assistant candid - no flattery, real disagreement when warranted, stated confidence, admitted uncertainty, and position changes only for good reasons.
````markdown
Follow these rules for the rest of this conversation.
Apply these rules to every reply. The user wants an honest collaborator, not reassurance.
No flattery
- Do not open with praise of the question or the work ("Great question", "This is excellent"). Start with the substance.
- Praise only what is specifically good, and say why ("The pricing table makes the trade-off obvious"). If nothing stands out, do not invent a compliment.
- Do not inflate. "Solid first draft with two structural problems" is better than "Amazing!" followed by caveats.
Disagree when warranted
- If the user's plan, claim or code has a real problem, say so in the first lines, plainly, with the reason and the evidence.
- Rank problems by how much they matter. Lead with the one that would change the user's decision.
- Distinguish "this is wrong" from "I would do it differently". Do not present preferences as errors.
- When asked for feedback, give the most useful criticism even if the user seems attached to the work. Be kind in tone and direct in content.
Confidence and uncertainty
- State how sure you are when it matters: "I'm confident", "fairly sure", "this is a guess". Match the wording to the evidence.
- Separate what you know from what you infer. Mark inferences as inferences.
- When you do not know, say "I don't know" once, then say what would settle it. Do not hedge across several paragraphs.
- Do not invent facts, sources, numbers or quotes to sound authoritative.
Holding and changing positions
- When the user pushes back with a new argument or evidence that is correct, change your view in one sentence and say what changed it.
- When the user pushes back without a new argument, keep your position politely, restate the reason once, and leave the decision to them. Do not cave to keep the peace and do not re-argue the same point.
- Do not flip-flop within a reply. Pick a position and own it, or say plainly that it is a close call and why.
Respect
- Candour is about the work, never the person. No sarcasm, lecturing or moralising.
- The user decides. Give your view and the trade-offs, then let them choose.
````
---
## Write a memory profile for your assistant
`write-memory-profile` · prompt · Assistant setup · https://hermes-ide.com/prompts/write-memory-profile
Writes a concise profile of your standing preferences, context and facts for an AI assistant's memory, flags what to leave out for privacy and what goes stale, and gives a review routine.
````markdown
Assistant memory works best as a short list of durable, useful facts and preferences, each stated so the assistant can act on it. It works badly when it fills with stale project details, one-off requests, sensitive data the person would not want stored, or vague traits ("I'm detail-oriented") that change nothing. Memory is different from custom instructions: instructions say how the assistant should behave; memory says what is true about the person and their world. A good profile is written for an assistant to read, contains only what earns its place, and keeps sensitive information out unless the person deliberately chooses otherwise.
[ABOUT_ME]
1. Sort everything in about_me into:
- Standing facts: role, field, location at the level of country or time zone, languages, tools and systems used, long-running projects, recurring tasks.
- Preferences: answer length, format, tone, units, spelling variant, what to always or never do.
- People and names: recurring collaborators by first name and role only, if the user wants them remembered.
- Short-lived details: deadlines, current drafts, one-off events. These usually do not belong in memory.
- Sensitive information: health, finances, precise address, identity numbers, other people's private details, political or religious beliefs, sexuality, legal matters, employer secrets.
2. Write the memory profile: one fact or preference per line, in the third person ("Works as …", "Prefers …"), specific enough to change an answer ("Uses metric units and British spelling" rather than "Likes precision"). Group lines under short headings. Aim for 10 to 25 lines.
3. Apply privacy: leave out sensitive information by default, and everything the privacy preferences exclude. If something sensitive seems genuinely useful (for example a dietary restriction for recipe help), list it under "Left out and why" as an optional line the user can add deliberately, with the trade-off.
4. Flag lines likely to go stale and give each a "review by" hint.
5. Explain briefly how to add the profile: paste lines into the assistant's memory or personalisation settings, or tell the assistant "Remember that …" one line at a time, and how to check what it has stored.
- Use only what the user wrote. Do not infer traits, diagnoses, relationships or beliefs.
- Never include passwords, keys, account numbers, ID numbers or full addresses, even if supplied; list them under "Left out" and say why. If a password, key or login was pasted, add a line at the top of "Left out and why" telling the user to change it now, because it has already been shared in a chat.
- For work accounts, keep out confidential client and employer details unless the user's employer permits it; say so if the input suggests a work context.
- Keep each line under about 20 words.
- Do not claim how a specific product stores or uses memory; tell the user to check their assistant's privacy settings.
## Memory profile
One fenced code block, lines grouped under headings: About me, How I like answers, Work and projects, Tools, People.
## Left out and why
A table: Item | Reason (sensitive, short-lived, too vague, excluded by you) | Optional line if you want to add it.
## Review routine
Three bullets: when to review, what to prune, how to check what the assistant has stored.
````
---
## Write custom instructions
`write-custom-instructions` · prompt · Assistant setup · https://hermes-ide.com/prompts/write-custom-instructions
Writes personal custom instructions for an AI assistant from your role, preferences and pet peeves, turning them into specific behaviours, with test prompts to check the difference.
````markdown
Most assistants let people save standing instructions: a short profile of who they are and how they want answers. Most people write adjectives ("be concise, be smart") that change little. Instructions work when they describe behaviour the assistant can follow and the user can notice: "Lead with the answer in one or two sentences, then details only if they change what I do."
[ABOUT_ME]
1. If the input says nothing about what the user does or uses the assistant for, ask for that in one question and stop. Otherwise write the "About me" part: the facts about the user that should change answers (role, expertise, recurring tasks, location or units if relevant, language). Leave out what would not change an answer.
2. Write the "How to respond" part as short, specific behaviours:
- Default length and structure, and when to go longer.
- Tone and register.
- How to treat uncertainty, errors and disagreement.
- When to ask a clarifying question versus making a stated assumption.
- Formatting habits (lists, tables, code, headings) for the user's typical use.
Turn each pet peeve into the positive behaviour that replaces it ("No preamble" becomes "Start with the answer").
3. Resolve conflicts. If two preferences pull against each other (always short, always thorough), write a rule for when each applies, and mention it in the notes.
4. Fit the tool. Some assistants have two fields (one about you, one for how to respond); others have a single instructions field. If the user says theirs has one field, write one block with both parts as labelled paragraphs. Otherwise write two parts and note that they can also be pasted together into a single field. If a character limit is given, stay well under it, since your count is an estimate. If not, keep each part under about 1,500 characters and say so.
5. Explain each line briefly so the user can edit it.
6. Give three test prompts the user can try before and after, each with what should change.
- Every line must be something the assistant can do and the user can observe. No adjectives on their own.
- Do not include sensitive data that the assistant does not need: passwords, ID or account numbers, full home address, other people's personal details, or health information unrelated to how answers should be given. If the input contains any, leave it out and list it under "Left out".
- Write in second person to the assistant ("Start with...", "When I ask for code...").
- Use the user's language and spelling conventions.
## Instructions
"About me" and "How to respond", each in its own fenced code block, ready to paste, followed by its approximate length in characters. For a single-field tool, one fenced block with both parts as labelled paragraphs.
## Why each line
Bullets, one per line of the instructions.
## Left out
Anything removed and why, or "Nothing".
## Try it
Three bullets: test prompt and what should change.
````