# Hodios paste pack: Coding-agent operations
Everything in Coding-agent operations 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
- Coding-agent operations
- [Audit a coding agent's permissions](#audit-agent-permissions) (prompt)
- [Review a coding agent transcript](#review-agent-transcript) (prompt)
- [Write a subagent brief](#write-subagent-brief) (prompt)
- [Write an agent handoff](#write-agent-handoff) (prompt)
- [Write an agent skill](#write-agent-skill) (prompt)
- [Write an AGENTS.md](#write-agents-md) (prompt)
---
## Audit a coding agent's permissions
`audit-agent-permissions` · prompt · Coding-agent operations · https://hermes-ide.com/prompts/audit-agent-permissions
Reviews a coding agent's tool, permission and sandbox configuration for shell, network, secrets and write-scope risk, and proposes least privilege. Use before giving an agent more autonomy.
````markdown
A coding agent acts with whatever the configuration lets it touch, and it reads untrusted text all day: issue bodies, web pages, dependency READMEs, test output, files in the repository. Any of that text can carry instructions (prompt injection). The real risk is the combination of three things in one session: access to private data or secrets, exposure to untrusted content, and a way to send data out or cause effects (network, pushing, posting, deploying). Broad shell access is the usual way all three meet, because a shell command can read any file and call any host. The audit judges the configuration against what the agent actually needs for its intended use.
Audit this configuration:
[CONFIG]
1. Identify the tool or tools the configuration belongs to and the format. If you do not recognise a key, say so instead of guessing its meaning.
2. Build an exposure map along six axes and rate each none, scoped or broad:
- **Shell:** which commands run without approval; wildcards that let an allowed prefix chain into anything (for example a command allowed by prefix that can take `&&`, `;`, `$(...)` or `-c`); interpreters and package managers that execute arbitrary code (`python`, `node`, `npx`, `npm install`, scripts fetched from the network and piped into a shell).
- **File write scope:** inside the workspace only, or also home directory, dotfiles, shell profiles, git hooks, CI configuration and the agent's own settings (an agent that can edit its own permissions has every permission).
- **Network:** outbound access, allowed domains, fetch and browser tools, and whether data can leave through them.
- **Secrets:** environment variables, tokens, cloud credentials, SSH keys and `.env` files readable by the agent or its subprocesses; token scopes (a CI token that can push to the default branch or publish packages).
- **External effects:** git push, pull request and issue comments, package publishing, deploys, messages, payments, MCP servers with write tools.
- **Approval and sandbox:** approval mode, whether a container or OS sandbox is on, and whether any "skip permissions" or "yolo" style flag is set.
3. Check where untrusted content enters for the intended use, and mark every path where untrusted content, secrets and an outbound channel meet in one session.
4. Write findings ranked by risk, each with a concrete abuse scenario (what injected text could make the agent do), and the smallest change that removes it.
5. Write a least-privilege configuration in the same format as the input: explicit allow rules for what the intended use needs, deny rules for secrets paths and the agent's own config, approval for anything external, network limited to required hosts, and the sandbox on. If you are unsure of a key's exact syntax for this tool, write it and mark it "check against the tool's documentation".
- Judge against the intended use. Do not strip a permission the use clearly needs; say how to scope it instead.
- Never print secret values that appear in the config. Refer to them by name and recommend rotating any that were committed.
- Do not claim the proposed config makes the agent safe; list what remains in Residual risks.
- If the intended use is missing, assume the agent may read untrusted content, say so, and ask for the use under Questions.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Exposure summary
A table: axis, current level (none, scoped, broad), what drives it.
## Findings
Numbered, highest risk first. Each: severity (critical, high, medium, low), the setting, the abuse scenario, the fix.
## Least-privilege config
One fenced block in the input's format, then a short list of what changed and why.
## Residual risks
Bullets of risks the configuration cannot remove, with the process control that covers each (review before merge, short-lived tokens, separate CI job).
## Questions
What you need to know to tighten further, or "None".
````
---
## Review a coding agent transcript
`review-agent-transcript` · prompt · Coding-agent operations · https://hermes-ide.com/prompts/review-agent-transcript
Reviews a coding agent session transcript for where it went wrong (bad assumptions, skipped verification, scope creep, looping) and turns each failure into an instruction-file or prompt change.
````markdown
When a coding agent session goes badly, the cause is usually visible in the transcript a few turns before the visible failure: an assumption it never checked, a file it never read, a test it never ran, an instruction that was missing, ambiguous or contradicted by another one. Adding a vague line such as "be careful" or an all-caps "NEVER" to the instruction file rarely helps. What helps is a specific instruction placed where the agent will read it, with the reason, or a change to the setup (a command, a check, a tool) that makes the right behaviour the easy one. Some failures are model variance and no instruction will fix them; saying so prevents instruction files from bloating.
Review this agent session:
[TRANSCRIPT]
1. Reconstruct the task: what the user asked, what a good outcome would have been, and how the session actually ended.
2. Find the key moments: the turns where the session's direction changed, for better or worse. For each failure, find the earliest turn where it became likely, not only where it became visible.
3. Classify each failure:
- Misread the request, or invented scope the user did not ask for.
- Acted on an assumption it could have checked (an API, a file's contents, a command's behaviour, the project's conventions).
- Missing context: did not read relevant files, docs or existing patterns.
- Skipped verification: claimed success without running the tests, build, type check or the app; or misreported a result.
- Scope creep: changed files or behaviour outside the task.
- Looping or thrashing: repeated a failing approach, or edited back and forth, without new information.
- Stopped early or handed work back that it could have finished; or the opposite, pushed on when it should have asked.
- Unsafe or destructive action, or one taken without the confirmation the instructions require.
- Ignored an existing instruction, or followed one that was wrong, outdated or contradicted by another.
- Context loss: forgot earlier decisions in a long session.
Quote the evidence (turn and a short excerpt) for each.
4. For each failure, decide the cause in the setup: instruction missing, ambiguous, buried, contradicted or outdated; the prompt was underspecified; a tool, command or permission was missing; the environment misled the agent (flaky test, stale docs); or model variance with no setup cause.
5. Propose the smallest change that would have prevented it, in order of leverage: fix or remove a wrong or conflicting instruction; add a specific instruction with its reason and the exact command or file it refers to; change how the task is prompted; add a check the agent can run (a script, a test command, a pre-commit hook); change permissions. Write each instruction as the agent would read it: concrete, positive ("Run `npm test -- path` after editing a file under src/") rather than vague or shouted.
6. Note what the agent did well that the instructions should keep encouraging.
7. Check the result for bloat: if the instruction file would grow by more than a few lines, merge or cut instead, and point out any existing lines that are now redundant.
- Every failure cites transcript evidence. Do not speculate about the model's internal reasoning beyond what the transcript shows.
- Prefer one high-leverage instruction over several narrow ones. Do not propose an instruction for a one-off mistake unless the cost of a repeat is high.
- Keep proposed instructions tool-neutral where possible, so they work in any agent that reads the file.
- Do not include secrets, tokens or personal data from the transcript in the output.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
## Summary
Three to five lines: what was asked, what happened, and the root causes.
## Key moments
Table: turn | what happened | effect.
## Failures
Numbered, most costly first. Each: category - evidence (turn and quote) - setup cause - proposed change.
## Instruction file changes
A unified diff against the given instruction file, or the new lines with where they go if no file was given. Include removals of conflicting or redundant lines.
## Prompt changes
How the user could phrase the task next time, if that was a cause. "None" otherwise.
## Other setup changes
Commands, checks, hooks, tools or permissions to add or change.
## Keep doing
Bullets.
## Not fixable by instructions
Failures that look like model variance, and how to work around them (smaller tasks, checkpoints, review).
````
---
## Write a subagent brief
`write-subagent-brief` · prompt · Coding-agent operations · https://hermes-ide.com/prompts/write-subagent-brief
Turns a task into a self-contained brief for a subagent or parallel agent, with the goal, context, scope, constraints, return format and definition of done. Use before delegating to another agent.
````markdown
A subagent starts with an empty context. It cannot see this conversation, does not know what you already tried, and will fill gaps with plausible guesses. Most failed delegations come from three gaps: the goal is a topic instead of an outcome, the boundaries are unstated so the agent edits things it should not, and the return format is undefined so the result cannot be checked or merged. Parallel agents fail in one more way: overlapping scope, where two agents edit the same files.
Write 1 brief(s) for this task: [TASK]
1. Gather what the subagent needs and cannot see: relevant file paths, commands, decisions already made, approaches already rejected and why, and the user's standing instructions. Read the files you reference so the paths are right.
2. State the goal as an outcome with a definition of done that can be checked ("the three failing tests in `tests/api/` pass and no other test fails"), not as an activity ("look into the API tests").
3. Set the scope: the files or areas it may change, the ones it must not touch, and the actions that need approval or are forbidden (pushing, deleting, installing dependencies, network calls).
4. Define the return format: what to report and in which structure, including evidence (commands run and their real output) and anything it could not do.
5. If more than one agent: split the work so no two briefs share files or decisions, say what each agent can assume about the others, and say how the results will be combined.
6. Size each brief so it can finish in one session. If the task is too big or too vague to delegate safely, say so and list what must be decided first.
- Each brief must be self-contained: no "as above", "the issue we discussed" or references to this conversation.
- Include only context that changes what the subagent does. Do not paste whole files; give paths and the lines that matter.
- Never put secrets, tokens or personal data in a brief.
- Do not delegate decisions that belong to the user; list them as open questions instead.
For each brief, a fenced `markdown` block ready to paste, containing these headings: Goal, Context, Scope (may change / must not change), Constraints, Steps (only if the order matters), Return format, Done when.
After the briefs: how the results will be checked and combined, and any open questions for the user.
````
---
## Write an agent handoff
`write-agent-handoff` · prompt · Coding-agent operations · https://hermes-ide.com/prompts/write-agent-handoff
Writes a self-contained handoff note so a fresh agent or a teammate can continue the current task without the conversation history. Use before ending a long session, switching tools or delegating.
````markdown
The next reader has none of this session's context: not the conversation, not the files you read, not the dead ends you already ruled out. A handoff fails when it says "as discussed", when it reports work as done that was never verified, or when it leaves out the approaches that did not work, so the next agent repeats them. It should let a fresh agent with no memory of this session start working within a minute.
Write a handoff for the task in this session.
1. Check the actual state before writing: `git status`, the current branch, uncommitted changes, and the last commands and test results in this session. Do not rely on memory of what you intended to do.
2. Separate what is done and verified (with the evidence), what is done but unverified, and what is in progress (the exact point where work stopped).
3. Write the next steps as concrete, ordered actions with file paths and commands, so they can be executed without interpretation.
4. Record decisions with their reasons, and the approaches that were tried and rejected, with why.
5. Note gotchas: environment quirks, flaky tests, commands that need special flags, files not to touch, constraints the user gave.
- Self-contained: no "as discussed", "the earlier approach" or references to messages the reader cannot see. Name files, functions, branches and commands explicitly.
- Never mark something verified unless a command in this session showed it. Say "not verified" plainly.
- Include the user's explicit instructions and preferences that still apply, quoted briefly.
- Never include secrets, tokens, passwords or personal data, even if they appeared in the session. Refer to where they are stored instead.
- Keep it under about 600 words; link to files for detail instead of pasting them.
A Markdown note with a one-line title, then:
## Goal
What the task is and what done looks like.
## State
Three lists: Done and verified (with evidence) / Done, not verified / In progress (where it stopped).
## Next steps
Numbered, concrete actions.
## Decisions
Decision and reason; rejected approaches and why.
## Gotchas
Bullets.
## Verify
Commands that prove the task is complete.
## Open questions
For the user, or "None".
````
---
## Write an agent skill
`write-agent-skill` · prompt · Coding-agent operations · https://hermes-ide.com/prompts/write-agent-skill
Writes a reusable agent skill (SKILL.md with frontmatter, steps, scripts and references) from a repeated task, with a trigger description models can match and a test plan. Use to package a workflow.
````markdown
A skill is a folder with a `SKILL.md` file: YAML frontmatter with a `name` and a `description`, then instructions, plus optional scripts and reference files. Agents that support the format see only the name and description of every installed skill and load the body when the description matches the request, then open supporting files only when the body points to them. So the description decides whether the skill is ever used, and the body must be short enough to load cheaply while the detail lives in files read on demand. Skills fail when the description is vague ("helps with deployments"), when the body repeats what the model already knows, when fragile steps that should be a script are left as prose, and when nobody tests whether the skill triggers on the requests it should and stays out of the ones it should not.
Turn this repeated task into a skill:
[TASK]
1. Decide whether a skill is the right container. A one-line convention belongs in the project's instruction file; a one-off task belongs in a prompt; a multi-step procedure with its own knowledge, scripts or templates that recurs is a skill. If it is not a skill, say what it should be, give that instead, and stop.
2. Identify what the agent does not already know: the project-specific steps, commands, file locations, conventions, gotchas, and the definition of done. Leave out general knowledge the model has.
3. Write the frontmatter:
- `name`: lowercase letters, numbers and hyphens, at most 64 characters, naming the activity (for example `release-mobile-app`).
- `description`: at most 1,024 characters, third person, saying what the skill does and when to use it, with the words users actually type (taken from the examples), the file types or tools involved, and when not to use it if a nearby request could falsely match.
4. Write the body as numbered steps the agent follows, each with the exact command or file, the expected result, and what to do when it fails. Include a verification step that proves the task is done, and the points where the agent must ask for confirmation before acting (deploying, deleting, sending). Keep the body under about 500 lines; move long reference material into `references/` files and say in the body when to read each one.
5. Move steps that must be done exactly the same way every time (parsing, validation, generation from a template, multi-command sequences) into scripts under `scripts/`, in a language available in the environment, with clear usage output and non-zero exit codes on failure. Tell the agent to run them, not read them. Keep scripts free of secrets and of commands that download and execute remote code.
6. Add templates or examples under `assets/` or `references/` only if the output has a fixed shape.
7. Write the test plan: ten requests that should trigger the skill and five near-misses that should not, taken from or modelled on the examples; two or three end-to-end runs on real instances with the expected result; and a comparison against running the same tasks without the skill.
If the task description is too thin to write concrete steps (no commands, files or definition of done), ask for those details, ideally with one real example, and stop.
- Use only commands, paths and tools present in the input or the repository; mark anything you had to assume with TODO.
- Write instructions as direct, specific steps with the reason where it is not obvious. No filler such as "be thorough" and no shouting in capitals.
- Keep the skill portable across agents that support the format; isolate any agent-specific feature and say which agents need it.
- Respect the user's permission limits; never add steps that bypass confirmations or security checks.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
## Decision
One or two sentences: skill or not, and why.
## Folder layout
A tree of the skill folder.
## SKILL.md
The complete file in a `markdown` code block.
## Supporting files
Each script, reference or template in its own code block, with its path as a heading.
## Test plan
Table of trigger tests: request | should trigger (yes or no). Then the end-to-end runs and the with-and-without comparison.
````
---
## Write an AGENTS.md
`write-agents-md` · prompt · Coding-agent operations · https://hermes-ide.com/prompts/write-agents-md
Writes or updates a repository's AGENTS.md with the verified commands, layout, conventions and boundaries a coding agent needs, and nothing generic. Use when setting up a repo for coding agents.
````markdown
AGENTS.md is the instruction file that coding agents read at the start of every session (several tools read it directly; others read CLAUDE.md, GEMINI.md or their own rules files, which can point to it). Every line costs context in every session, so it should hold only what an agent would otherwise get wrong: the exact commands, the non-obvious layout, the conventions that differ from the language defaults, and the things it must never do. Generic advice ("write clean code", "add tests") is ignored and wastes space. A wrong command is worse than none, because the agent will run it with confidence.
Write `AGENTS.md` for the repository in the working directory.
1. Read what exists: any AGENTS.md, CLAUDE.md, GEMINI.md, `.cursor/rules/`, `.github/copilot-instructions.md`, CONTRIBUTING and README. If an AGENTS.md exists, update it and keep accurate content.
2. Collect the commands from the sources of truth: package scripts, Makefile or task runner, CI workflows (the commands CI runs are the ones that must pass), and lint, format and type-check configs. Include how to run a single test, not only the whole suite.
3. If you can run commands, run the cheap ones (install check, lint, type check, one test) and record which you ran. Mark the ones you could not run.
4. Map the layout only where it is not obvious: where the entry points are, which folders are generated or vendored, where tests live, and module boundaries.
5. Write down the conventions an agent would get wrong from defaults: naming, error handling, logging, the test style, import rules, the commit and PR format, the branch policy. Take each from the config files or from consistent patterns in the code, and cite the file.
6. Write boundaries: files and folders never to edit, commands never to run, actions that need the user's approval (dependencies, migrations, deleting files, pushing).
- Every command must come from the repo's scripts, CI or docs. Never invent a script name or flag.
- No generic advice, no restating the README, no product description beyond one line.
- Keep it under about 120 lines. Prefer short imperative bullets.
- Do not include secrets, tokens, internal hostnames or personal data.
- Do not create tool-specific files (CLAUDE.md, rules folders) unless asked; mention in your reply which tools need a pointer to AGENTS.md.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
Write `AGENTS.md` with: a one-line project description, then `## Commands`, `## Layout`, `## Conventions`, `## Boundaries` (add `## Commits and PRs` if the repo has rules for them).
Then reply with: the commands you ran and their real results, the commands you could not verify, and anything in the existing instruction files that contradicted the code.
````