# Hodios paste pack: Planning Everything in Planning from Hodios, the open prompt library by Hermes IDE: 7 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 - Planning - [Break down an epic](#break-down-epic) (prompt) - [Estimate work as a range](#estimate-with-ranges) (prompt) - [Feature track](#feature-track) (workflow) - [Plan a spike](#plan-spike) (prompt) - [Plan a sprint](#plan-sprint) (prompt) - [Write a tech debt proposal](#write-tech-debt-proposal) (prompt) - [Write an implementation plan](#write-implementation-plan) (prompt) --- ## Break down an epic `break-down-epic` · prompt · Planning · https://hermes-ide.com/prompts/break-down-epic Splits an epic into small, ordered vertical slices that each deliver testable value, with acceptance checks, dependencies and spikes. Use when an epic or large feature is too big to start. ````markdown Large epics stall because they are split by technical layer ("build the database", "build the UI"), so nothing works end to end until the very last ticket. Vertical slices cut through every layer and deliver something a user or tester can see, so the team learns early, can ship partway, and can stop when enough value is delivered. Break down this epic: [EPIC] Largest acceptable item: 2 days of work for one person. 1. State the goal in one sentence and the scope: what is in, and what is explicitly out. 2. Find the walking skeleton: the thinnest end-to-end path that proves the main flow works. Make it slice 1. 3. Add slices that each grow the working system, splitting by workflow step, business rule, data variation, happy path then error paths, or user type. Each slice must be independently testable and, where possible, shippable behind a flag. 4. Give every slice a one-line acceptance check that a tester could verify, its dependencies on other slices, and a relative size (S, M or L, where L is at most 2 days of work for one person). Split anything bigger. 5. Where an unknown blocks sizing or ordering, add a time-boxed spike with the question it must answer. 6. Order the slices so that risk and learning come first and the most valuable behaviour arrives early. - No layer-only items ("set up the database", "build the API") unless something truly cannot be sliced; then say why. - At most 15 slices. If the epic needs more, propose how to split the epic itself and break down only the first part. - Do not invent requirements. Anything you had to assume goes under Risks and open questions. - Each slice title starts with a verb and names user-visible behaviour. - 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. ## Goal and scope One goal sentence, then "In:" and "Out:" bullets. ## Slices Table in delivery order: #, slice, acceptance check, depends on, size. ## Spikes Bullets: question, time box, which slices it unblocks. Or "None". ## Risks and open questions Numbered. ```` --- ## Estimate work as a range `estimate-with-ranges` · prompt · Planning · https://hermes-ide.com/prompts/estimate-with-ranges Breaks engineering work into tasks and produces a range estimate with a confidence level, stated assumptions and the unknowns that need a spike. Use when asked "how long will this take?". ````markdown Single-number estimates are heard as promises and are almost always optimistic: they leave out review, testing, rollout and interruptions, and they hide the parts nobody understands yet. A useful estimate is a range with a stated confidence, built bottom-up from tasks small enough to reason about, and explicit about the assumptions and unknowns that drive the spread. The unknowns that matter most are better resolved with a short, time-boxed spike than argued about. Estimate this work: [WORK] Unit: days. If you do not know who will do the work, how familiar they are with the code, or their real availability, ask once; if the user wants an answer anyway, use the assumptions "one engineer familiar with the codebase, about 60% of their time on this work" and say so. 1. Clarify scope: list what is in and out, including the parts people forget (tests, code review rounds, migrations, feature flags, monitoring, docs, deployment, coordination with other teams). Ask about anything that changes the size by more than about 20%. If the work is too vague for a meaningful range, say so, give the questions that would make it estimable, and give a rough order of magnitude only. 2. Break the work into tasks of no more than about two ideal days each. For each task give optimistic, most-likely and pessimistic effort in days (ideal engineer-days when the unit is days), and mark its uncertainty (low, medium, high) with the reason. For points, estimate relative to a reference task from the context; if there is none, say that points cannot be calibrated and give days as well. 3. For each high-uncertainty task, define a spike: the question it answers, a time box (normally half a day to two days), and how its answer changes the estimate. 4. Roll up: compute the expected value and spread per task with the three-point (PERT) formula, mean = (O + 4M + P) / 6 and standard deviation = (P − O) / 6, sum the means, and combine spreads (root-sum-square if tasks are independent; note when they are correlated, which widens the range). Under a normal approximation the 50% figure is the summed mean and the 85% figure is the mean plus about one combined standard deviation (z ≈ 1.04). Show the arithmetic. 5. Convert effort to calendar time using availability and parallelism, and add waiting time that is not effort (review latency, other teams, release windows). 6. List the assumptions the estimate depends on, and what would move it most. - Never give a single number without its range and confidence. - Do not pad silently. Every buffer appears as a named line with its reason. - Do not use velocity, story points or historical figures that were not given; if they would help, ask for them. - Label every assumption as such. - An estimate is not a commitment; do not phrase it as one. - 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. ## Estimate One sentence: "50% likely within X weeks of starting, 85% likely within Y weeks, assuming Z", then the effort range in ideal days. ## Breakdown Table: Task | O | M | P | Mean | Uncertainty and reason. Totals row, then the roll-up arithmetic. ## Unknowns and spikes Table: Unknown | Spike question | Time box | Effect on the estimate. ## Assumptions Bullets. ## What would change it The three factors that would move the estimate most, and in which direction. ## Not included Bullets: work outside this estimate. ```` --- ## Feature track `feature-track` · workflow · Planning · https://hermes-ide.com/prompts/feature-track Takes a feature from open questions to a reviewed implementation in six gated steps, saving each step's artifact to the repo. Use for any change bigger than a quick fix. ````markdown Builds the feature "[FEATURE]" in small, reviewable steps. Each step writes one artifact and stops for approval before the next one starts, so the human stays in control of scope and design while the agent does the legwork. Later steps read the earlier artifacts instead of re-asking. --- # Step 1: Questions Read the request for "[FEATURE]" and the code it touches. Write the questions whose answers would change the design: users, edge cases, constraints, non-goals and how success is measured. Group them, keep each one answerable in a sentence, and mark the ones you can answer yourself from the code (with the answer). Stop and wait for the answers. --- # Step 2: Research Using the answered questions, map the current system: the files, modules, data and external services involved, and how a request flows through them today. Note existing patterns the feature should follow and anything that will make it harder. Cite file paths. Do not propose a design yet. Stop and wait for approval. --- # Step 3: Design Propose the design for "[FEATURE]": the approach, the alternatives you rejected and why, data and API changes, failure modes, and how it will be tested. Keep it to what a reviewer needs to say yes or no. Stop and wait for approval. --- # Step 4: Structure List every file to add or change, with a one-line purpose each, plus new types, functions and their signatures. Flag anything that touches a shared or public interface. Stop and wait for approval. --- # Step 5: Plan Turn the approved design and structure into an ordered list of small steps. Each step leaves the code building and its tests passing, and says how it will be verified. Stop and wait for approval. --- # Step 6: Implement Carry out the plan one step at a time. After each step, run its verification and report the real result. If reality differs from the plan, stop and say how before continuing. Finish with what changed, what was verified, and anything left open. ```` --- ## Plan a spike `plan-spike` · prompt · Planning · https://hermes-ide.com/prompts/plan-spike Turns a technical unknown into a time-boxed spike with a sharp question, exit criteria, cheapest-first experiments and a clear deliverable. Use when an unknown blocks a decision or an estimate. ````markdown A spike is a short, time-boxed investigation that buys information, not features. Spikes go wrong when the question is vague ("look into Kafka"), when nobody defines what "done" means, or when the prototype quietly becomes production code. A good spike plan fixes all three before the clock starts. Plan a spike for: [QUESTION] Time box: 2 days. 1. Rewrite the unknown as one or two answerable questions, each with a yes or no, a number, or a choice between named options as its answer. 2. Name the decision or estimate the answer unblocks, and who makes it. 3. Define exit criteria: the evidence that answers each question, and what result would mean "go", "no go" or "need more data". 4. List the experiments, cheapest and most informative first (reading docs and code, asking someone, a throwaway prototype, a measurement). Give each a share of the time box and what it should show. 5. Add a checkpoint at about half the time box to decide whether to continue, narrow the question or stop. 6. Define the deliverable: a short findings note with the answer, the evidence, the recommendation and what remains unknown. - Fit the whole plan inside 2 days. If it cannot be answered in that time, say so and narrow the question instead of stretching the box. - Prototype code is throwaway by default. Say so in the plan, and list anything that must be rebuilt properly if the answer is "go". - Do not pre-decide the answer or bias the experiments toward one outcome. - Do not state facts about tools or products you are unsure of; turn them into things the spike checks. ## Question The sharpened questions, numbered. ## Decision it unblocks One or two lines. ## Exit criteria Bullets: go, no go, need more data. ## Plan Numbered experiments with time share and expected evidence, plus the checkpoint. ## Deliverable What the findings note contains. ## Out of scope Bullets. ```` --- ## Plan a sprint `plan-sprint` · prompt · Planning · https://hermes-ide.com/prompts/plan-sprint Builds a sprint plan from a backlog and real capacity, with a sprint goal, committed and stretch items, dependencies, risks and what it deliberately leaves out. Use before sprint planning. ````markdown Sprints fail in planning more often than in execution: the team commits to the sum of everyone's nominal hours, forgets on-call and holidays, ignores carry-over, picks unrelated items with no goal tying them together, and discovers on day six that an item depended on another team. A good plan starts from realistic capacity, picks a single goal worth achieving, commits to less than the maximum, and says out loud what it is not doing. Draft a 2 weeks sprint plan from the backlog and capacity below, ready for the team to challenge in planning. [BACKLOG] [CAPACITY] 1. Compute realistic capacity, in the backlog's own unit, and show the arithmetic: - **Available person-days:** people × working days, minus absences, on-call or support time and fixed ceremonies. Compare it with a normal sprint for this team. - **With history in points or item counts:** capacity = the average of the last three sprints × (available person-days ÷ normal person-days). Do not apply a focus factor on top: history already includes meetings, interruptions and reviews. If the history is volatile, plan to the lower end of the range and say so. - **Without history:** apply a focus factor of 60 to 70% to available person-days, say it is an assumption, and only then compare with the items' estimates. If items are sized in T-shirt sizes or not at all, say they cannot be summed reliably, state the day range you assume per size (or ask for it), and treat the result as a rough fit, not a total. 2. Account for carry-over first: re-estimate what remains, and decide with a reason whether each item continues, is split or goes back to the backlog. 3. Propose one sprint goal: a single outcome, written as what users or the business will have by the end, that most committed items serve. If the backlog has no coherent goal, say so and propose the best candidate. 4. Select committed items in priority order up to realistic capacity, leaving roughly 10 to 20% unplanned only if the history is volatile or the team has unplanned support work not reflected in it. Never commit beyond capacity because someone asked; put the excess in stretch or Not this sprint and say what the trade-off is. Prefer finishing over starting, and items that serve the goal. Flag items that are not ready (no acceptance criteria, unresolved questions, missing designs, estimates too large for one sprint) and either propose a split or move them out. 5. Pick stretch items that fill the remaining capacity, labelled clearly as not committed. 6. Check the plan against people, not only points: no one is overloaded, specialist skills are not a bottleneck, and work that needs reviews, QA or another team has time for it. 7. List dependencies (other teams, vendors, environments, decisions) with what is needed and by which day, and the main risks with a mitigation each. 8. List what is deliberately left out and why, so stakeholders hear it before the sprint, not after. - Use the backlog's own estimates and units. Do not re-estimate items unless asked, but flag estimates that look inconsistent. - Do not change the backlog's priority order silently. If the plan skips a higher-priority item, give the reason. - Do not invent team members, dates, velocities or dependencies. Mark assumptions. - The plan is a proposal for the team to decide on, not a commitment made for them. - 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. ## Sprint goal One sentence, then one line on why this goal. ## Capacity Table: person or role, days available, deductions, available days. Then the conversion to the backlog's unit (history scaling or focus factor, never both) and the resulting capacity. ## Committed Table: item, estimate, owner or skill, serves goal (yes or no), ready (yes or what is missing). Total against capacity, in the same unit. ## Stretch Same table, labelled as not committed. ## Not this sprint Bullets: item and reason. ## Dependencies and risks Table: dependency or risk, needed by, owner, mitigation. ## Questions for planning Numbered questions the team must answer in the planning meeting. ```` --- ## Write a tech debt proposal `write-tech-debt-proposal` · prompt · Planning · https://hermes-ide.com/prompts/write-tech-debt-proposal Turns a piece of technical debt into a business case with evidence, cost of delay, options, the smallest valuable paydown and success measures. Use when you need product or leadership buy-in. ````markdown Tech debt proposals usually fail for the same reasons: they describe the code instead of the consequences, ask for a big rewrite with no end date, rely on adjectives ("fragile", "a mess") instead of numbers, and leave the decision-maker unable to compare the request with feature work. A proposal that wins treats debt like any other investment: what it costs us now, what it will cost if we wait, the smallest piece of work that pays back first, and how everyone will know it worked. Write a proposal to pay down this debt, aimed at a product audience. [DEBT] [EVIDENCE] 1. Translate the debt into consequences the audience already cares about: slower delivery of named roadmap items, incidents and their customer impact, security or compliance exposure, on-call load and attrition risk, or infrastructure cost. Keep only consequences the evidence supports. 2. Quantify with the evidence given. Show the arithmetic (for example "6 incidents in 2 quarters × about 4 engineer-hours each"). Where a number is an estimate, say so and give a range. If the evidence is too thin to make the case, say what to measure first and how, and draft the proposal with clearly marked placeholders. 3. Explain the cost of delay: what gets worse each month the debt stays (a growing workaround, an end-of-life date, a hiring plan that doubles the people touching this code) and any deadline that makes now cheaper than later. 4. Give two to four options, always including "do nothing" and an incremental option. For each: scope, effort as a range, what it unlocks, risk and reversibility. 5. Recommend the smallest valuable paydown: a first slice that fits the available capacity, delivers a measurable benefit on its own and can stop cleanly. Prefer tying it to an upcoming feature that touches the same code over a standalone project. 6. Define success measures with a baseline, a target and a review date, using measures the audience trusts (lead time for changes in this area, change failure rate, incident count, time to onboard, cloud cost). 7. Tune for the audience: product wants the roadmap trade-off and the date impact; leadership wants risk, money and a one-paragraph decision; the team wants scope, sequencing, ownership and how the work coexists with feature work. - Do not invent incidents, metrics, costs or quotes. Every figure comes from the evidence, is shown as arithmetic on it, or is marked as an estimate or placeholder. - No jargon the audience would not use. Explain any technical term in a few words the first time. - Do not ask for an open-ended rewrite. Every option has a defined end and a way to stop early. - Keep the whole proposal readable in five minutes: about 600 words, plus tables. - 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. ## The ask Two or three sentences: what you want approved, how much capacity, for how long, and the decision date. ## Problem The consequences in the audience's terms. ## Evidence Bullets, each with its source. ## Cost of delay ## Options Table: option, scope, effort range, benefit, risk, reversible. ## Recommended first step What, who, how long, what it unlocks, and the stop point. ## How we will measure success Table: measure, baseline, target, review date. ## Risks and open questions Numbered. ```` --- ## Write an implementation plan `write-implementation-plan` · prompt · Planning · https://hermes-ide.com/prompts/write-implementation-plan Reads the codebase and writes an ordered implementation plan in small verifiable steps, with files to touch, tests, rollout and risks. Use before coding any change that spans several files. ````markdown A good implementation plan is written against the real code, not an imagined one. Each step is small enough to review, leaves the build and tests green, and says how it will be verified, so the work can stop or change direction at any step without leaving a mess. Plan the implementation of: [GOAL] 1. Read the code this change touches: entry points, the modules and data involved, existing tests, and similar features you can copy patterns from. Do not plan from file names alone. 2. If an open question would change the plan (behaviour, data model, compatibility), list those questions first and stop. Ask only questions the code cannot answer. 3. List the touchpoints: every file, module, table, config or public interface that will change, with real paths. Mark new files as new. 4. Write the steps in order. Each step makes one coherent change, includes its tests, leaves the build green, and fits in a single reviewable commit. Prefer an order that gets a thin end-to-end path working early. 5. For each step, give the verification: the test to add or the command to run, and the expected result. 6. Plan the rollout: feature flags, data migrations (expand, migrate, then contract), backward compatibility for clients and running instances, and how to roll back. - Plan only. Do not edit files or write full implementations; signatures and short snippets are fine where they remove ambiguity. - Cite only paths, functions and commands that exist, or mark them as new. Never guess a test command; find it in the repo's scripts or docs. - Follow the patterns the codebase already uses unless the goal requires a change; say so when it does. - Read the relevant code before making a claim about it. Do not guess what a file, function or config contains. - If the information you need is not available, say what is missing and how to get it instead of inventing it. - 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. ## Understanding Three to five lines: what will change and how it fits the current design. ## Touchpoints Bullets: `path` — what changes. ## Steps Numbered. Each: title — files — the change — verification (command or test, expected result). ## Rollout Flags, migrations, compatibility, rollback. ## Risks Bullets: risk — mitigation. ## Out of scope Bullets. ````