# Hodios paste pack: Assistant setup
Everything in Assistant setup from Hodios, the open prompt library by Hermes IDE: 6 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
- Assistant setup
- [Build project instructions](#build-project-instructions) (prompt)
- [Candid feedback rules](#candid-feedback-rules) (rule)
- [Map where AI helps in your work](#map-ai-use-cases) (prompt)
- [Review custom instructions](#review-custom-instructions) (prompt)
- [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.
````
---
## Map where AI helps in your work
`map-ai-use-cases` · prompt · Assistant setup · https://hermes-ide.com/prompts/map-ai-use-cases
Maps a person's recurring work tasks to where an AI assistant helps, what to keep human, the prompt or setup for each and a check step, ranked by the time it could save.
````markdown
People who try an AI assistant on a few random tasks often conclude it is either magic or useless. The useful question is narrower: which of my recurring tasks have a shape AI handles well (drafting from known material, summarising, reformatting, first-pass analysis, brainstorming, explaining, checking against a list) and which depend on judgement, relationships, accountability or facts the assistant cannot verify. The biggest wins are usually frequent, text-heavy tasks with a quick way to check the output. Every use needs a check step, because fluent output can be wrong, and some data must never go into a tool that is not approved for it.
Map where an AI assistant can help in my work.
[ROLE_AND_TASKS]
1. If fewer than three recurring tasks are described, ask me to list my typical week (tasks, how often, how long) and stop.
2. For each task, judge the AI fit (high, medium, low) by: how much is drafting, transforming or summarising; how checkable the output is; how much depends on judgement, relationships or facts only I have; and the cost of an error.
3. For high and medium fits, say what the AI does, what stays with me, the setup (a reusable prompt, custom instructions, a template, a project with reference files), and the check step.
4. Estimate time saved per week from my own frequency and duration numbers, as a range, showing the arithmetic. If I gave no numbers for a task, say "not estimated" rather than guessing.
5. Rank by estimated time saved, adjusted down for error cost.
6. Write starter prompts for the top three, and a two-week pilot to test them.
- Respect the data constraints strictly: if a task needs restricted data, either propose a way to do it without that data (anonymised, structure-only, synthetic sample) or mark it "not with current tools" and say why.
- Recommend only the tools listed; if none are listed, describe capabilities ("a chat assistant with file upload") rather than naming products.
- Keep human anything involving final decisions about people (hiring, performance, discipline), legal or medical judgements, commitments made in my name, and relationship-critical messages; AI can help prepare, not decide or send.
- Be honest about low fits; do not stretch AI into every task.
- Time estimates are estimates; label them as such and do not present them as measured.
- Starter prompts must be complete and ready to paste, with placeholders in square brackets for my inputs.
## Ranked map
A table: Rank | Task | Fit | AI does | I do | Setup | Check step | Time saved per week (estimate).
## Keep human
Tasks with a low fit, each with a one-line reason.
## Starter setups
For each of the top three: a heading and the prompt in a fenced block.
## Data cautions
Bullets: what not to paste, and the workaround for each affected task.
## Two-week pilot
A short plan: which tasks, how to track time before and after, what quality checks to log, and how to decide whether to keep each one.
````
---
## Review custom instructions
`review-custom-instructions` · prompt · Assistant setup · https://hermes-ide.com/prompts/review-custom-instructions
Reviews existing custom or project instructions for an AI assistant, finds conflicts, vague rules, outdated facts and missing context, and returns a tighter version with test prompts.
````markdown
Custom instructions grow by accretion: a line added after each annoying answer, a job title from two roles ago, a rule copied from a blog post. Over time they contradict each other ("be concise" next to "always explain your reasoning in detail"), use adjectives the model cannot act on ("be smart"), carry stale facts, and spend the character budget on things the assistant already does. Modern assistants follow instructions literally and apply them to every conversation, so a vague or over-broad rule shows up everywhere. A good review keeps the person's intent, turns each preference into an observable behaviour, scopes rules to when they apply, and cuts the rest.
Review these instructions.
[CURRENT_INSTRUCTIONS]
1. Read every line and classify any problem as one of:
- conflict: two lines that cannot both be followed, or that pull in opposite directions;
- vague: an adjective or goal with no behaviour attached ("be thorough", "be smart");
- over-broad: a rule that should apply only in some situations but is stated for all;
- outdated or unverifiable: dates, roles, tools, versions, projects or facts that look stale;
- redundant: repeats another line or what assistants do by default;
- counterproductive: shouting, threats, or rules likely to cause over-application;
- missing: context the pain points or the rest of the instructions suggest is needed but absent.
2. Link each pain point to the line that causes it or the gap that allows it.
3. Write a revised version that keeps every preference I actually hold, resolves conflicts (choosing the reading that fits the rest of the text, and listing the choice as a question), turns adjectives into behaviours, scopes conditional rules ("When I share code…"), and groups related lines.
4. Write three to five test prompts that show the difference between the old and new versions.
- Do not add preferences I did not express. Put suggested additions in Findings as "missing", for me to accept or not.
- Do not silently update facts. Ask about anything that looks outdated rather than guessing the current value.
- The revised version should be the same length or shorter unless a missing item I clearly need requires more; give an approximate character count for both versions and remind me to check the exact count against my tool's limit.
- Keep my voice and my wording where it already works.
- Keep personal details already present, but flag sensitive ones (health, finances, exact address, other people's details) as worth removing, since instructions are sent with every conversation.
## Findings
A table: Line (quoted, shortened) | Problem | Why it matters | Fix.
## Revised instructions
The full revised text in one fenced block, then "Characters (approx.): old N → new M".
## Removed
Bullets of what was cut and why, one line each.
## Questions for you
Numbered questions on conflicts resolved, outdated facts and suggested additions.
## Try it
Test prompts, each with what should change in the answer.
````
---
## 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.
````