# Hodios paste pack: Product (engineering)
Everything in Product (engineering) from Hodios, the open prompt library by Hermes IDE: 13 entries, catalog 2026.1004.3.
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
- Product (engineering)
- [Define non-functional requirements](#define-non-functional-requirements) (prompt)
- [List a feature's edge cases](#list-feature-edge-cases) (prompt)
- [Product manager](#product-manager) (persona)
- [Refine a backlog ticket](#refine-backlog-ticket) (prompt)
- [Specify an in-app reporting feature](#spec-in-app-reporting-feature) (prompt)
- [Specify an internal tool request](#spec-internal-tool-request) (prompt)
- [Specify mobile screen states](#spec-mobile-screen-states) (prompt)
- [Turn a game design into a tech spec](#turn-game-design-into-tech-spec) (prompt)
- [Write a PRD](#write-prd) (prompt)
- [Write acceptance criteria](#write-acceptance-criteria) (prompt)
- [Write an actionable bug report](#write-actionable-bug-report) (prompt)
- [Write firmware requirements](#write-firmware-requirements) (prompt)
- [Write user stories](#write-user-stories) (prompt)
---
## Define non-functional requirements
`define-non-functional-requirements` · prompt · Product (engineering) · https://hermes-ide.com/prompts/define-non-functional-requirements
Writes measurable non-functional requirements for a feature, covering availability, latency, throughput, security, privacy, accessibility and operability, each with a target, verification and cost.
````markdown
Non-functional requirements are where specs are vaguest and where systems most often disappoint: "fast", "secure", "highly available" and "scalable" cannot be built, tested or traded off. A useful requirement names the quality, the scope it applies to, a measurable target with the percentile or window, how it will be verified, and what it costs. Targets also have to be consistent with the dependencies: a feature cannot be more available than the services it calls synchronously, and every extra nine roughly multiplies effort.
Write the non-functional requirements for:
[FEATURE]
1. Identify the user journeys and operations that matter most and the quality attributes relevant to them. Consider availability, latency, throughput and capacity, scalability, durability and data retention, recovery (RPO and RTO), security, privacy, accessibility, compatibility (browsers, devices, OS versions, API versions), operability (observability, deployability, rollback), maintainability and cost. Skip attributes that truly do not apply and say why in one line.
2. For each requirement write:
- an id (NFR-01, NFR-02…) and the attribute;
- the scope: which operation, journey or component;
- a measurable target with its unit, percentile and window, for example "p95 under 300 ms for search requests measured at the load balancer over 28 days", "99.9% of checkout requests succeed per 30 days", "WCAG 2.2 AA for all customer-facing screens";
- the verification method: load test, synthetic check, SLO dashboard, security review or penetration test, accessibility audit, restore drill, or contract test;
- the rationale, tied to users, the business or a regulation;
- the cost or design implication of meeting it.
3. Check consistency: compare availability and latency targets with the dependencies' targets, show the arithmetic for serial dependencies, and flag targets that are not achievable as stated.
4. For regulatory items, state what the regulation typically requires as a requirement to confirm with the compliance or legal owner, not as legal advice.
5. Propose a sensible target where the input gives none, mark it as proposed, and give the cheaper and the stricter alternative so the owner can choose.
- Every requirement must be testable. Replace words such as fast, secure, scalable, robust and user-friendly with numbers or named standards.
- Do not invent current performance figures, user counts or dependency SLOs. Mark every number that was not given as proposed or assumed.
- Prefer a few requirements that matter over an exhaustive checklist; at most about 15.
- 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
The three to five requirements that will most shape the design, in one line each.
## Requirements
Table: id, attribute, scope, target, verification, rationale, status (given, proposed or assumed).
## Trade-offs and cost
Bullets: what meeting the stricter targets would require, and the consistency checks against dependencies with arithmetic.
## Not specified on purpose
Attributes left out and why.
## Open questions
Numbered, each with who should answer it.
````
---
## List a feature's edge cases
`list-feature-edge-cases` · prompt · Product (engineering) · https://hermes-ide.com/prompts/list-feature-edge-cases
Lists the edge cases of a feature before build by boundaries, time zones, concurrency, permissions, money and rounding, languages, scale and failure, each with the decision a product owner must make.
````markdown
Most defects in new features are not coding mistakes but decisions nobody made: what happens at exactly the limit, across midnight in another time zone, when two people edit at once, when a refund splits a discounted amount. In refinement, the goal is not a list of hundreds of theoretical cases but the short list of situations that are likely or costly, each turned into a decision the product owner can make now. Edge-case lists fail when they are generic checklists unrelated to the feature, when they bury the important decisions among trivia, and when they propose answers as if they were already agreed.
[FEATURE_DESCRIPTION]
1. Identify the feature's inputs, states, actors, limits and dependencies.
2. Walk each area and keep only cases that apply to this feature:
- input boundaries: empty, minimum, maximum, just over and under each limit, special characters, duplicates, very long values;
- time: time zones and which one rules, daylight saving changes, midnight and month or year ends, leap days, expiry exactly at the boundary, clock differences between devices;
- concurrency and repetition: double submits, two users editing the same item, retries after timeouts, actions from several devices, ordering of events;
- permissions and lifecycle: each role, losing access mid-action, deleted or archived related items, invited but not yet registered users, account deletion;
- money and quantities: currency, rounding rule and where it is applied, partial refunds, discounts and taxes interaction, negative or zero amounts;
- language and region: translations, right-to-left text, name and address formats, local number and date formats;
- scale: the largest customer, many items, long histories, rate limits, exports;
- failure: a dependency down or slow, partial success, notifications that fail, data migration of existing records;
- abuse: actions that could be exploited for gain or to harm other users.
3. For each case write a concrete example with values, the question the product owner must answer, a recommended default with a one-line reason, and a likelihood and impact rating (high, medium, low).
4. Put the decisions with high likelihood or high impact first under Decisions needed; at most about 12, so the list fits a refinement meeting.
5. List cases the feature description already answers, so they are not reopened.
6. Suggest cases to explicitly put out of scope for this release, with the risk of doing so.
- Every case must be specific to this feature with concrete values; drop generic items that do not apply.
- Recommended defaults are proposals, not decisions; never present them as agreed rules.
- Do not invent business rules or legal requirements; where a rule depends on law or contracts (tax, consumer rights, data retention), say who to check with.
- If the feature description is too thin to find real edge cases, ask the three to five questions that would unlock them instead.
## Decisions needed
Numbered: question, example, recommended default, likelihood and impact.
## Edge cases by area
A checklist grouped by area: "- [ ] case - example - proposed behaviour".
## Already covered
Bullets quoting the rule from the description.
## Suggested out of scope
Bullets with the risk.
````
---
## Product manager
`product-manager` · persona · Product (engineering) · https://hermes-ide.com/prompts/product-manager
Acts as a product manager who starts from the user problem and evidence, writes requirements engineers can build and test, and cuts scope to the smallest valuable release.
````markdown
From now on, work as this persona: Product manager.
You are a product manager who works closely with an engineering team. You care about shipping the smallest thing that solves a real problem for a specific user, and about knowing afterwards whether it did.
How you work:
- Start from the problem, not the solution. For any request, establish who has the problem, how often it happens, what they do today instead, and what evidence shows it matters. When a request arrives as a solution ("add a button that …"), work back to the problem it is meant to solve.
- Keep facts, assumptions and opinions apart, and label each. An assumption that the plan depends on becomes something to validate, not something to build on silently.
- Define success before scope: the outcome you expect, the metric that shows it, its current baseline (or a TODO to measure it) and a target.
- Write requirements engineers can build and testers can verify: specific behaviour, edge cases, error states, permissions and empty states. Say what and why; leave how to the engineers unless there is a real constraint.
- Cut scope deliberately. Separate must-have from nice-to-have, and propose the release that delivers most of the value soonest.
- Bring engineers in early on feasibility and cost, and change the plan when they find a cheaper way to the same outcome.
What you flag:
- Solutions dressed up as requirements, and requirements nobody can test.
- Missing non-goals, unmeasurable success criteria, and metrics with no baseline.
- Unvalidated assumptions about users, and user quotes or data that nobody has a source for.
- Forgotten cases: existing users and their data, permissions and roles, failure and empty states, accessibility, localisation, and what happens to support.
- Scope creep: work that does not serve the stated outcome.
Your habits:
- You never invent research, user quotes, market sizes or metric values. You mark the gap and say how to fill it.
- You write short, plain documents with headings people can scan, and you put decisions and open questions where they cannot be missed.
- You end with the next decision to make and who should make it.
````
---
## Refine a backlog ticket
`refine-backlog-ticket` · prompt · Product (engineering) · https://hermes-ide.com/prompts/refine-backlog-ticket
Turns a vague ticket into a ready-for-development one with the user problem, scope and non-scope, open questions, acceptance criteria and a definition-of-ready check. Use in backlog refinement.
````markdown
A ticket is ready when an engineer who was not in the conversation can build it, a tester can verify it and nobody needs to ask the author what they meant. Vague tickets ("improve search", "users should be able to export") cost more in mid-sprint questions, rework and scope creep than the hour it takes to refine them. Refinement should surface decisions, not paper over them: when the ticket does not say something, the right output is a question with a proposed default, not an invented requirement.
Refine this ticket so it can pass the team's definition of ready.
[TICKET]
If no definition of ready was given, use: the user problem is clear; scope and non-scope are written; acceptance criteria are testable; dependencies are known; designs or examples are attached where UI changes; open questions are answered or have an owner; it is small enough to finish in one sprint.
1. Identify the type (feature, bug, chore, spike) and restate the user problem: who is affected, what they are trying to do, what goes wrong today, and why it matters now. For a bug, include steps to reproduce, expected and actual behaviour, and environment, marking anything missing.
2. Write the scope as concrete behaviours, and the non-scope as the nearby things a reader might assume are included.
3. Write acceptance criteria in Given, When, Then form (or a checklist if that suits the ticket better), covering the main path, the main alternative paths, validation and error cases, empty states, permissions and any edge case the ticket hints at. Each criterion must be checkable by someone who did not write it.
4. List open questions. For each, say why it matters (what it changes in the build or the estimate), propose a default answer, and name who should decide.
5. Note dependencies, risks and anything engineering should know: affected areas, data or migration impact, analytics events to add, documentation or support changes.
6. Check the result against the definition of ready, item by item: met, not met (and what is missing), or not applicable.
7. If the ticket is too large for one sprint or mixes independent outcomes, propose a split into vertical slices that each deliver value on their own.
- Do not invent business rules, numbers, designs or decisions. Anything not in the ticket or context becomes an open question with a proposed default, clearly labelled.
- Keep the original intent. If you think the ticket is solving the wrong problem, say so in one line under Open questions rather than rewriting it into a different ticket.
- Write in plain language a new team member could follow. No filler.
## Refined ticket
**Title:** a short, specific title.
**Type:**
**Problem:** two to four sentences.
**Scope:** bullets.
**Out of scope:** bullets.
**Acceptance criteria:** numbered.
**Notes for engineering:** dependencies, risks, analytics, docs.
## Open questions
Table: question, why it matters, proposed default, who decides.
## Definition-of-ready check
Table: item, status (met, not met, n/a), what is missing.
## Suggested split
Numbered slices, or "Not needed".
````
---
## Specify an in-app reporting feature
`spec-in-app-reporting-feature` · prompt · Product (engineering) · https://hermes-ide.com/prompts/spec-in-app-reporting-feature
Specifies a report or export feature in a B2B product, with filters, columns, permissions, row limits, async export, formats, time zones, scheduled delivery and how numbers reconcile with the screens.
````markdown
"Can we get an export?" is one of the most common B2B requests, and one of the most underspecified. Reporting features go wrong when the numbers in the export do not match the numbers on screen (different time zone, status filter or rounding), when an export leaks data a role should not see, when the largest customer's export times out or takes the database down, when CSVs open broken in spreadsheet tools (encoding, separators, formula injection), and when scheduled reports keep emailing people who left the company. A good spec answers the job behind the request first, then makes these decisions explicit.
[FEATURE_REQUEST]
1. Problem and users: the decision or task the report supports (reconciling invoices, auditing activity, feeding another system), who uses it, how often, and what they do today. If an existing screen or API already answers it, say so.
2. Report definition: grain (one row per what), columns with source, definition, format and unit, default sort, filters (date range with which date field, status, owner, custom fields), totals and how they are computed, and saved views if needed.
3. Permissions and data access: who can run, see, schedule and share each report; row-level scoping by role, team or region; sensitive columns hidden or masked by role; and an audit log of exports.
4. Delivery and formats: on-screen table, CSV, XLSX, PDF or API; synchronous download below a row threshold and asynchronous export above it (with notification and expiring download link); file naming; CSV rules (UTF-8 with BOM if spreadsheet users need it, separator, quoting, neutralising values starting with =, +, - or @ to prevent formula injection).
5. Scheduling, if requested: frequencies, recipients limited to users with access, time zone of the schedule, what happens when a recipient loses access or the report fails, and unsubscribe.
6. Scale and performance: largest expected export from the user data, row limits, pagination or streaming, running against a replica or warehouse rather than the primary database, timeouts, rate limits per account, and retention of generated files.
7. Reconciliation: which screen numbers the report must match, the time zone used for date boundaries (account, user or UTC), currency and rounding, how late-arriving or edited records appear, and the "as of" timestamp printed on every report.
8. Edge cases: empty results, deleted or merged entities, renamed custom fields, multi-currency totals, data changing during an async export.
9. Out of scope for version one, and open questions.
- Do not invent customer needs, data fields or volumes; mark unknowns [X] and add them to Open questions.
- Where data protection or retention rules may apply (personal data in exports, cross-border delivery), flag them to check with the privacy or legal owner without stating the law.
- Prefer the smallest version that serves the job; push builders, charts and scheduling to later unless the request needs them.
- Every threshold you propose (row limits, timeouts, retention) is marked "proposed" with the reason.
## Problem and users
Short paragraph and bullets.
## Report definition
Grain, then a columns table (column, source, definition, format), then filters and totals.
## Permissions and data access
Table: role, run, view, schedule, row scope, hidden columns.
## Delivery and formats
Bullets, including CSV rules.
## Scale and performance
Bullets with proposed thresholds.
## Reconciliation
Bullets naming the screens and rules.
## Edge cases
Table: case, expected behaviour.
## Out of scope
Bullets.
## Open questions
Numbered.
````
---
## Specify an internal tool request
`spec-internal-tool-request` · prompt · Product (engineering) · https://hermes-ide.com/prompts/spec-internal-tool-request
Interviews a non-technical colleague about the internal tool they want, one question at a time, and writes a spec developers can estimate, with problem, users, workaround, data and value.
````markdown
People in operations, finance, HR and support ask for internal tools in terms of a solution ("a dashboard", "an app", "automate it") because they do not know what developers need to estimate. Developers then build the wrong thing or let the request sit because it is too vague to size. A good intake interview starts from the job and the current workaround, gets real numbers (how often, how many, how long), finds the data and systems involved, and separates the few must-haves from the wish list, without making the colleague feel quizzed. The person may not know technical terms; never make them feel they should.
[INITIAL_REQUEST]
Run a short interview, then write the spec.
1. Open with one sentence restating the request in plain words, say that the result is a short spec developers can estimate (not the tool itself), say you will ask about 10 short questions and that they can type "done" at any time, then ask the first one.
2. Ask one question per turn, in plain language, each with a short example answer so the person knows the level of detail wanted. Skip anything the person has already answered, including in the initial request; if one answer covers several topics, note them all and move on. Cover:
- the outcome: what will be different when this exists, and what triggers the task (a date, an email, a customer action);
- the current workaround, step by step: which tools, files and people, how long each run takes, how often, and where it goes wrong;
- who does it and who receives the result, and how many people;
- the data: where it comes from, who owns it, whether it includes personal or financial data, and an example of the input and the output (with real values removed);
- the systems involved and whether they have exports, APIs or integrations the person knows of;
- must-haves versus nice-to-haves: "if it did only one thing, what would it be?";
- deadlines, approvals or audit needs, and what happens today when it fails.
3. Listen for numbers and repeat them back to check ("so about 3 hours every Monday?"). If an answer is vague, ask one follow-up, then move on.
4. Stay in the interviewer role: do not propose a technical solution during the interview. If asked, say you will note options in the spec.
5. Stop when you have enough, when you reach about 10 questions, or when the person types "done". Before writing, read back the must-haves and the key numbers in two or three lines and ask them to confirm or correct; if they typed "done", skip the read-back. Then write the spec, and estimate value: hours saved per month (frequency x time x people), errors avoided, and any risk reduced, labelled as an estimate from their answers.
6. In the spec, add a short note of possible approaches for developers (spreadsheet improvement, no-code automation, small internal app, feature in an existing system), without choosing one.
- One question per message during the interview; never a list of questions at once.
- Use only what the person said; mark unknowns as [X] and list them under Open questions.
- Ask the person not to paste real personal or financial records; ask for made-up examples instead.
- Plain language throughout: no jargon such as API, ETL or schema in questions unless the person used it first.
- If the request turns out to be a policy or staffing problem rather than a tool, say so kindly in the spec.
During the interview: one short acknowledgement line, then one question with an example answer.
Final spec in Markdown:
## Request summary
Two to three sentences: the job and the outcome.
## Current process
Numbered steps with time and frequency, and where it fails.
## Users and volume
Bullets with numbers.
## Data and systems
Table: data, source system, owner, sensitive (yes or no), example.
## Must-haves
At most five numbered items, each testable.
## Nice-to-haves
Bullets.
## Value
The hours-saved calculation shown, plus other benefits.
## Risks and constraints
Bullets, including possible approaches for developers.
## Open questions
Numbered.
````
---
## Specify mobile screen states
`spec-mobile-screen-states` · prompt · Product (engineering) · https://hermes-ide.com/prompts/spec-mobile-screen-states
Specifies every state of a mobile screen before build, from loading, empty, error, offline and denied permissions to long text and dark mode, plus deep link entry, back behaviour and analytics.
````markdown
Mobile designs usually show the happy state with perfect data. The bugs and the one-star reviews come from everything else: a spinner that never ends on a train, an empty list with no explanation, a permission denied once and never asked again, a German translation that overflows a button, a deep link that opens the screen with no back stack, and an error that wipes what the user typed. Engineers then make these decisions alone during build. This spec makes them explicit before build.
Platform conventions to follow (ios, android or both): both. For a single platform, describe only that platform's behaviour.
[SCREEN_DESCRIPTION]
1. Summarise the screen: purpose, primary action, data sources (local, network, both) and whether content is cached.
2. Specify each state that applies, with what the user sees, what they can do, and how the state is left:
- first load and refresh (skeleton or spinner, after how long to show it, pull to refresh);
- empty: first use (never had data) versus cleared (no results after filter or deletion), each with a message and a next action;
- partial: some sections loaded, some failed; paging and end of list;
- error: network failure, server error, timeout, and item-level failure, with retry behaviour and what user input is preserved;
- offline and slow network: cached content with its age, queued actions, what is disabled;
- permissions: not yet asked (explain before the system prompt), denied, permanently denied (route to settings), limited access (for example limited photo library on iOS);
- signed out or session expired mid-use;
- content extremes: very long names and translations (allow about 30-40% text expansion), right-to-left languages, large text and accessibility font sizes, zero and huge counts, missing images;
- appearance: dark mode, landscape or tablet if supported, and safe areas.
3. Navigation and entry: every way in (tab, push, deep link or universal or app link, notification, widget), the back and up behaviour for each (including a deep link opened from cold start), state restoration after the app is killed, and what happens if the linked item no longer exists or the user lacks access.
4. Platform differences for both: system back on Android versus swipe back on iOS, permission flows, pull to refresh and share sheet conventions, only where they change behaviour.
5. Analytics events: screen view and each meaningful action, with event name, trigger, properties and no personal data; include events for error and empty states so their frequency can be measured.
6. Open questions for product and design, especially decisions you had to assume.
- Do not invent data fields, copy or business rules; where the screen needs a decision, propose a default and mark it "Proposed" in the matrix and in Open questions.
- Keep copy suggestions short and mark them as drafts for the designer or writer.
- Name platform behaviours accurately; if unsure of an exact API or setting name, describe the behaviour instead.
- Analytics properties must not include names, emails, free text or precise location.
## Screen summary
Four to six bullets.
## State matrix
Table: state, trigger, what the user sees, available actions, exit, notes (mark Proposed).
## Navigation and entry
Table: entry point, back behaviour, restoration, missing or forbidden item handling. Then platform differences as bullets.
## Analytics events
Table: event, trigger, properties.
## Open questions
Numbered.
````
---
## Turn a game design into a tech spec
`turn-game-design-into-tech-spec` · prompt · Product (engineering) · https://hermes-ide.com/prompts/turn-game-design-into-tech-spec
Turns a game design section such as a mechanic, economy or progression system into an engineering spec with data definitions, state, designer tunables, edge cases, save impact and test hooks.
````markdown
Game design documents describe how a system should feel; programmers need exact rules, data and state. The gap causes the classic problems: numbers hard-coded so designers cannot tune without a programmer, ambiguous rules ("crits stack") implemented one way and designed another, edge cases discovered in playtests (what if the player levels up twice in one frame, sells an equipped item, or loads an old save), and no way to test the system without playing for an hour. The engine context is not stated.
[DESIGN_SECTION]
1. Summarise the system in three to five sentences, and list the other systems it touches (inventory, UI, save, audio, networking, analytics).
2. Restate every rule as precise logic: triggers, conditions, order of evaluation, formulas with variable names and units, rounding, caps and floors, random rolls with their distribution and seeding. Where the design is ambiguous, write the interpretations side by side and raise a question instead of choosing silently.
3. Data definitions: the static content types designers author (items, levels, curves, tables) with each field, type, range and default, and where they live in the engine's data pipeline. Prefer data-driven definitions over code constants.
4. Runtime state: what changes during play, who owns it, when it changes, and whether it is replicated in multiplayer.
5. Tunables: every number designers will want to change, with a sensible initial value from the design, a safe range, and whether it can change at runtime (hot reload or debug menu).
6. Edge cases: simultaneous events in one frame, interruptions (pause, death, scene change, disconnect), overflow and extreme values, stacking and order dependence, exploits (duplication, infinite loops of rewards), and localisation of any generated text.
7. Save and versioning: what is persisted, the format, how saves from earlier versions are migrated when fields or balance change, and what must never be persisted (derived values).
8. Test hooks: debug commands or cheats to reach each state quickly, deterministic seeds, automated tests for formulas and edge cases, and telemetry events designers need to balance the system.
9. Questions for design: every ambiguity and missing number, phrased so the designer can answer quickly.
- Use only rules and numbers from the design. Write [X] for a missing value and add a question; do not balance the game yourself.
- Keep engine-specific advice correct for the stated engine; if the engine is not stated, stay engine-neutral.
- Write formulas in plain notation with named variables, and show one worked example with numbers from the design.
- Flag any monetisation or randomised reward mechanic that may face store rules or regional regulation (for example paid loot boxes) as something to check, without stating the law.
## Summary
Paragraph and a list of touched systems.
## Rules as logic
Numbered rules, formulas in code blocks, one worked example.
## Data definitions
Table per content type: field, type, range, default, notes.
## Runtime state
Table: state, owner, changes when, persisted, replicated.
## Tunables
Table: name, initial value, safe range, runtime-editable.
## Edge cases
Table: case, expected behaviour, source (design or proposed).
## Save and versioning
Bullets.
## Test hooks
Bullets: debug commands, tests, telemetry events.
## Questions for design
Numbered.
````
---
## Write a PRD
`write-prd` · prompt · Product (engineering) · https://hermes-ide.com/prompts/write-prd
Writes a product requirements document that an engineering team can build from, with the problem, goals, success metrics, testable requirements, edge cases and open questions.
````markdown
A PRD aligns product, design and engineering on what to build and why, before the expensive work starts. Engineers use it to find edge cases and push back on scope; testers use it to know what "done" means. It is only as trustworthy as its evidence, so gaps must be visible rather than papered over.
Write a full PRD for: [IDEA]
1. Problem: who has it, when it happens, what they do today, and the evidence that it matters, using only the material given.
2. Goals and non-goals: the outcomes this release must achieve, and things it deliberately will not do.
3. Success metrics: for each, the metric, its current baseline, the target, and how it will be measured. Include one guardrail metric that must not get worse.
4. Users and use cases: the specific user types and the main scenarios, written as short flows.
5. Requirements: numbered, each one testable, each with a priority (must, should, could). Add non-functional requirements (performance, security, privacy, accessibility, localisation) only where they apply.
6. Edge cases: empty states, errors, permissions and roles, limits, existing users and data, concurrent edits.
7. Risks and dependencies, a rollout plan (flag, beta group, migration of existing data, how to roll back), and open questions with an owner where one is known.
For a one-pager, keep Problem, Goals and non-goals, Success metrics, the must-have requirements and Open questions, in under 500 words.
- Describe what and why, not how. Mention implementation only when it is a real constraint.
- Never invent research, user quotes, numbers, dates or names. Write `TODO: …` with what is needed, and repeat important gaps under Open questions.
- Mark assumptions with "Assumption:" so reviewers can challenge them.
- Use plain language a new engineer understands. No marketing tone.
- 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.
# [Feature name]
A status line: Draft · Owner: [TODO unless given] · Last updated: [TODO unless known].
Then the sections in this order, each as `##`: Problem, Goals and non-goals, Success metrics (as a table: metric, baseline, target, how measured), Users and use cases, Requirements (as a table: id, requirement, priority), Edge cases, Risks and dependencies, Rollout, Open questions.
For a one-pager, include only the sections named in the task.
````
---
## Write acceptance criteria
`write-acceptance-criteria` · prompt · Product (engineering) · https://hermes-ide.com/prompts/write-acceptance-criteria
Writes testable acceptance criteria for a user story or ticket, covering the main path, alternatives, validation, boundaries, permissions and empty states. Use before a story enters development.
````markdown
Acceptance criteria are the shared definition of done between product, engineering and testing. Good criteria describe observable behaviour with concrete values, so two people reading them would test the same thing. Most production bugs in new features sit in the cases the criteria never mentioned: boundaries, permissions, errors and empty states.
Write acceptance criteria for this story: [STORY]
Style: gherkin.
1. Identify the main path and write it first.
2. Add the cases that apply to this story: alternative paths, input validation, exact boundaries (at, just below and just above each limit), permissions for each role, empty and first-use states, errors from dependencies, and repeated or concurrent actions.
3. Use concrete example values in every criterion (amounts, dates, names, counts), not "valid input".
4. Check every criterion: could a tester verify it with no further explanation? Rewrite any that fail.
- Describe behaviour the user or a system can observe, not implementation or UI layout, unless the story is about the layout.
- Each scenario stands alone and tests one behaviour.
- At most 12 criteria. If the story needs more, say that it should be split and suggest where.
- Do not invent business rules. If a criterion needs a rule that was not given, write it with your best guess, mark it "Assumption:", and repeat it under Questions for the product owner.
## Acceptance criteria
For gherkin: numbered scenarios, each with a `Scenario:` title and Given, When, Then lines (And where needed).
For checklist: numbered "- [ ]" items, one verifiable statement each.
## Assumptions
Bullets, or "None".
## Questions for the product owner
Numbered, or "None".
````
---
## Write an actionable bug report
`write-actionable-bug-report` · prompt · Product (engineering) · https://hermes-ide.com/prompts/write-actionable-bug-report
Turns a messy complaint, screenshot note or support chat into a bug report engineers can act on, with environment, numbered steps, expected versus actual, frequency, impact and open unknowns.
````markdown
Engineers can fix a bug quickly when they can reproduce it and know how much it matters. Reports from support, testers and colleagues often arrive as stories ("it keeps crashing when I try to pay") that mix symptoms, guesses about causes and frustration. Reports fail when the title is vague, steps skip the state that triggers the bug (logged in as which role, with what data), expected and actual are merged, the environment is missing, impact is "urgent!!" instead of facts, and guesses are written as if they were observations. The person writing may not be technical; the report should be clear without jargon.
[RAW_REPORT]
1. Separate what was observed from what the reporter believes or guesses. Keep guesses only in Notes for triage.
2. Write a title of at most about 80 characters: where, what goes wrong, under which condition ("Checkout: Pay button does nothing when the cart has a gift card").
3. Environment: product area, app or browser and version, operating system and device, account type or role, region or language, date and time with time zone of the occurrence, and any ids that help find logs (order number, request id) - never passwords or full card numbers.
4. Preconditions and numbered steps: the starting state (logged in as, data present), then one action per step, as specific as the source allows. Mark steps you inferred with "(inferred)".
5. Expected result and actual result, separately, with exact error text in quotes.
6. Frequency (every time, sometimes with a rough rate, once) and whether it was reproduced by someone other than the reporter.
7. Impact: who is affected and how many if known, whether there is a workaround, data loss or money at stake, and a suggested severity using a common scale (blocker, critical, major, minor, trivial) with the reason; the team may override it.
8. Evidence: list attachments mentioned (screenshots, recordings, logs, HAR files) and what each shows.
9. List the questions to ask the reporter that would most help reproduction, at most five, in plain language.
- Do not invent steps, versions, error text or numbers of affected users; write [X] or "unknown" and ask.
- Do not guess the cause in the report body; put hypotheses in Notes for triage, labelled as such.
- Remove personal data from the report: names, emails, phone numbers, addresses, payment details. Keep an internal reference to the ticket instead.
- If the report describes several different problems, split them into separate reports.
- If it is a feature request or a question rather than a bug, say so and suggest where it belongs.
## Bug report
Title, then labelled fields: Environment, Preconditions, Steps to reproduce (numbered), Expected, Actual, Frequency, Impact and suggested severity, Evidence, Ticket reference.
## Questions for the reporter
Numbered, plain language.
## Notes for triage
Bullets: hypotheses, related known issues, anything that suggests a recent release caused it.
````
---
## Write firmware requirements
`write-firmware-requirements` · prompt · Product (engineering) · https://hermes-ide.com/prompts/write-firmware-requirements
Writes testable firmware requirements from a hardware product brief, covering behaviour, timing and power budgets, fault handling, update and boot, manufacturing test hooks and traceable IDs.
````markdown
Firmware requirements written from a product brief tend to restate marketing goals ("long battery life", "reliable connectivity") that nobody can test, and they leave out the behaviours that cause field returns: what the device does on brown-out, when a sensor fails, when an update is interrupted, or when the clock is wrong after a battery swap. Good requirements are atomic, testable, measurable, traceable to the brief, and say what to do under fault, not only in the normal case. Use "shall" for mandatory requirements, "should" for goals, and give each a unique ID.
[PRODUCT_BRIEF]
1. Scope: what the firmware is responsible for and what belongs to hardware, the companion app or the cloud. List assumptions you had to make.
2. Write requirements grouped by area, each with an ID (for example FW-PWR-003), the requirement in one sentence with measurable criteria, rationale, source in the brief (or "derived"), priority (must, should, could) and verification method (test, analysis, inspection, demonstration):
- functional behaviour and modes (off, sleep, active, pairing, fault), with a state list and transitions;
- timing: response latencies, sampling rates, start-up time, with tolerances;
- power: current budget per mode, duty cycles, and the resulting battery life calculation with the battery capacity given; low-battery behaviour and thresholds;
- connectivity: pairing, reconnection, behaviour when offline, data buffering limits;
- fault handling: brown-out, watchdog reset, sensor or peripheral failure, memory corruption, clock loss; what is logged and what the user sees;
- boot and update: secure boot if required, update delivery, image verification, A/B or fallback slot, behaviour on interrupted update and on a bad image, version reporting;
- security: unique device credentials, debug port lockdown in production, storage of secrets;
- manufacturing and service: test mode entry, self-test, calibration storage, serial and version readout, factory reset;
- diagnostics: logs, counters and what is reported for field failure analysis.
3. Make every requirement testable: replace adjectives with numbers and conditions; if the brief gives no number, propose one marked "TBC" and add it to Open questions.
Finally, build a verification matrix linking each requirement to a test approach and the brief item it traces to; flag brief items with no requirement.
- Do not invent hardware parts, battery capacities, currents or regulatory targets; use [X] or TBC and ask.
- One requirement per ID; no "and" joining two testable behaviours.
- Do not state that the product meets any regulation or standard; list which ones to check.
- Keep implementation choices out of requirements unless the brief fixes them (say "shall verify the image signature before booting it", not which library).
## Scope and assumptions
Bullets.
## Requirements
One table per area: ID, requirement, rationale, source, priority, verification.
## Verification matrix
Table: ID, test approach, environment (bench, chamber, field), brief item. Then untraced brief items.
## Open questions
Numbered, each linked to requirement IDs.
````
---
## Write user stories
`write-user-stories` · prompt · Product (engineering) · https://hermes-ide.com/prompts/write-user-stories
Turns a feature description into small, independent user stories for specific users, each with acceptance criteria, and splits stories that are too big. Use when preparing a backlog.
````markdown
A user story is a small promise of value to a specific user, sized to finish in a few days and testable on its own. Stories go wrong when they describe technical tasks ("create the table"), when the user is a vague "user", or when one story hides a whole feature.
Write user stories for: [FEATURE]
Format: connextra.
1. Identify the user types and the journey they go through for this feature. Group the stories by journey step.
2. Write one story per piece of user-visible value. Each must be independent, negotiable, valuable, estimable, small and testable (INVEST).
3. Split any story that is too big, using the pattern that fits: workflow steps, business rule variations, data variations, happy path before error paths, simple before complex, or one operation at a time. Note which pattern you used.
4. Under each story, write 2 to 5 acceptance criteria as Given/When/Then, with concrete example values, covering the main path and the most likely failure.
- Name a specific user type in every story. Use "user" only if there truly is a single kind of user.
- No technical tasks as stories. If technical work is needed, mention it in the story's notes.
- Do not invent business rules (limits, prices, permissions). Turn each one you need into an open question.
- At most 15 stories. If the feature needs more, cover the first release and list the rest under Out of scope.
## Stories
For each journey step, a `###` heading, then per story:
**[ID] [Short title]**
The story sentence.
Acceptance criteria (when requested), then Notes if any.
## Split notes
Which stories you split and the pattern used.
## Open questions
Numbered.
## Out of scope
Bullets.
````