|
| 1 | +# Feature Specification Prompt |
| 2 | + |
| 3 | +To generate the YAML specification file required for the LLM Prompt Generator, use the following prompt. This ensures the output adheres to the strict schema required by the tool. |
| 4 | + |
| 5 | +```text |
| 6 | +You are a senior software architect and QA / automation platform designer. |
| 7 | +
|
| 8 | +OBJECTIVE |
| 9 | +Generate a single YAML document that defines a list of engineering features for implementation and verification. |
| 10 | +
|
| 11 | +CRITICAL OUTPUT CONTRACT (MUST FOLLOW) |
| 12 | +1) Output MUST be valid YAML only. |
| 13 | + - Do NOT output Markdown. |
| 14 | + - Do NOT use code fences. |
| 15 | + - Do NOT add any prose before or after the YAML. |
| 16 | +2) The YAML root key MUST be: features |
| 17 | +3) features MUST be a YAML list of feature objects. |
| 18 | +4) Every feature object MUST include the EXACT keys below (no extra keys, no missing keys): |
| 19 | + - feature_key |
| 20 | + - feature_name |
| 21 | + - is_frontend |
| 22 | + - verification_url |
| 23 | + - context |
| 24 | + - requirements |
| 25 | + - acceptance_criteria |
| 26 | +
|
| 27 | +LANGUAGE REQUIREMENT (MANDATORY) |
| 28 | +- All YAML content MUST be written in English: |
| 29 | + - All string values MUST be English. |
| 30 | + - All YAML comments (lines starting with #) MUST be English. |
| 31 | +
|
| 32 | +STYLE / SPEC RIGOR REQUIREMENTS |
| 33 | +- Use clear, testable language using must/shall/should with explicit constraints and thresholds. |
| 34 | +- Avoid vague statements (e.g., “handle properly”, “improve performance” without measurable criteria). |
| 35 | +- Emphasize: |
| 36 | + - contracts / schemas |
| 37 | + - state machines and illegal transition guards |
| 38 | + - idempotency and deduplication |
| 39 | + - auditability |
| 40 | + - observability (logs/metrics/tracing) |
| 41 | + - E2E with cleared data + evidence capture and archiving: |
| 42 | + - features/<feature_key>/E2E_RUN_REPORT.md |
| 43 | + - features/<feature_key>/STATE.md |
| 44 | +- Verification environment is the source of truth. |
| 45 | +- For frontend features: |
| 46 | + - UI MUST reflect backend/DB truth (no client-side inference as source of truth). |
| 47 | + - Acceptance criteria MUST include Chrome DevTools: console 0 error AND network 0 failure. |
| 48 | +
|
| 49 | +FIELD SEMANTICS (MUST APPLY) |
| 50 | +feature_key |
| 51 | +- Uniquely identifies the feature in tracking systems. |
| 52 | +- Must be unique across the entire YAML. |
| 53 | +- Format: lower-kebab-case. |
| 54 | +- Recommended action prefixes: add-, enhance-, fix-, refactor-, healthcheck-, upgrade-. |
| 55 | +
|
| 56 | +feature_name |
| 57 | +- Human-facing title. |
| 58 | +- MUST start with one of the prefixes: |
| 59 | + "Add:", "Enhance:", "Fix:", "Refactor:", "Upgrade:", "Healthcheck:" |
| 60 | +- Must be concise but specific and include key scope/constraints when relevant. |
| 61 | +
|
| 62 | +is_frontend |
| 63 | +- true if any UI deliverable exists, otherwise false. |
| 64 | +
|
| 65 | +verification_url (Mandatory fallback rule) |
| 66 | +- verification_url MUST always be present and MUST be a quoted string. |
| 67 | +- If a real, reachable verification URL is available, use it. |
| 68 | +- If a real verification URL is NOT available, set exactly: |
| 69 | + - verification_url: "No verification_url" |
| 70 | +- Do NOT omit verification_url, do NOT use null, and do NOT use an empty string. |
| 71 | +
|
| 72 | +context |
| 73 | +- A list of English strings describing why/what at a high level. |
| 74 | +- Must include: |
| 75 | + - Goal statement and user impact |
| 76 | + - Why now / problem being solved |
| 77 | + - Scope boundaries and key constraints (Verification truth, clear-data E2E, non-goals if needed) |
| 78 | +
|
| 79 | +requirements |
| 80 | +- A detailed, testable specification as a list of strings. |
| 81 | +- Must be structured using YAML comment section headings EXACTLY like: |
| 82 | + # -------- |
| 83 | + # A. <title> |
| 84 | + # -------- |
| 85 | +- Each requirement MUST be an English string item. |
| 86 | +- Requirements MUST specify (as applicable): |
| 87 | + - contracts/schemas (fields + types + validation rules) |
| 88 | + - state machine, allowed transitions, illegal transition behavior |
| 89 | + - idempotency, dedupe rules, and replay safety |
| 90 | + - concurrency and locking rules |
| 91 | + - APIs: endpoints, auth, pagination/filtering, error model |
| 92 | + - data models: tables/indexes/retention, migrations + rollback |
| 93 | + - artifact storage: types, checksum, retention policy |
| 94 | + - observability: structured logs, metrics, tracing propagation |
| 95 | + - test plan: unit/integration + E2E steps starting with clearing data |
| 96 | + - evidence capture requirements and file paths |
| 97 | +
|
| 98 | +acceptance_criteria |
| 99 | +- A list of binary-verifiable outcomes in English. |
| 100 | +- Must include: |
| 101 | + - Clear-data E2E pass conditions in verification environment |
| 102 | + - Evidence archived to: |
| 103 | + - features/<feature_key>/E2E_RUN_REPORT.md |
| 104 | + - features/<feature_key>/STATE.md |
| 105 | + - For frontend features: Chrome DevTools console 0 error AND network 0 failure |
| 106 | +
|
| 107 | +QUALITY BAR SELF-CHECK (DO THIS BEFORE YOU OUTPUT) |
| 108 | +- Feature completeness: |
| 109 | + - context includes goal + constraints |
| 110 | + - requirements include deep operational detail with sections |
| 111 | + - acceptance_criteria are binary-verifiable and mention clear-data E2E + evidence paths |
| 112 | + - terminology is consistent: run, step, artifact, report, schedule |
| 113 | +- Engineering rigor: |
| 114 | + - explicit contracts/schemas |
| 115 | + - state machine with illegal transition guard |
| 116 | + - idempotency and dedupe rules |
| 117 | + - observability + audit logs |
| 118 | + - security: authn/authz + RBAC |
| 119 | + - retention policy for artifacts/results |
| 120 | +- Verification: |
| 121 | + - unit tests + integration tests + E2E with clear-data prerequisite in verification environment |
| 122 | + - evidence capture requirements included |
| 123 | +
|
| 124 | +NOW GENERATE THE YAML IN THE EXACT SHAPE OF THE TEMPLATE BELOW. |
| 125 | +- Keep the same key order as the template. |
| 126 | +- Replace placeholders with concrete, English content. |
| 127 | +- Output YAML only. |
| 128 | +
|
| 129 | +features: |
| 130 | + - feature_key: <kebab-case-unique-key> |
| 131 | + feature_name: "<Prefix:> <Concise but specific title>" |
| 132 | + is_frontend: <true|false> |
| 133 | + verification_url: "<Verification URL or 'No verification_url'>" |
| 134 | + context: |
| 135 | + - "<Goal statement>" |
| 136 | + - "<Why now / what problem it solves>" |
| 137 | + - "<Scope boundaries + constraints (Verification truth, clear data E2E, etc.)>" |
| 138 | + requirements: |
| 139 | + # -------- |
| 140 | + # A. Scope and contracts |
| 141 | + # -------- |
| 142 | + - "<Define primary entities/contracts and required fields/types>" |
| 143 | + - "<Define input/output schemas; strict validation rules>" |
| 144 | + # -------- |
| 145 | + # B. Execution semantics |
| 146 | + # -------- |
| 147 | + - "<Define state machine; allowed transitions; illegal transition handling>" |
| 148 | + - "<Define idempotency and dedupe rules>" |
| 149 | + - "<Define concurrency/locking rules>" |
| 150 | + # -------- |
| 151 | + # C. APIs and security |
| 152 | + # -------- |
| 153 | + - "<List endpoints and required query filters/pagination>" |
| 154 | + - "<AuthN/AuthZ requirements; RBAC matrix>" |
| 155 | + - "<Audit log fields and required coverage>" |
| 156 | + # -------- |
| 157 | + # D. Storage, artifacts, retention |
| 158 | + # -------- |
| 159 | + - "<DB schema or persistence requirements; migrations and rollback>" |
| 160 | + - "<Artifact types and storage; checksum; retention policy>" |
| 161 | + # -------- |
| 162 | + # E. Observability |
| 163 | + # -------- |
| 164 | + - "<Structured logs fields>" |
| 165 | + - "<Metrics list>" |
| 166 | + - "<Tracing propagation rules>" |
| 167 | + # -------- |
| 168 | + # F. Tests and E2E (clear data) |
| 169 | + # -------- |
| 170 | + - "<Unit tests list>" |
| 171 | + - "<Integration tests list>" |
| 172 | + - "<E2E steps starting with clearing data (DB/queue/cache/object storage as applicable) in verification environment>" |
| 173 | + - "<Evidence capture requirements (features/<feature_key>/E2E_RUN_REPORT.md and features/<feature_key>/STATE.md)>" |
| 174 | + acceptance_criteria: |
| 175 | + - "<Binary verifiable outcome 1>" |
| 176 | + - "<Binary verifiable outcome 2>" |
| 177 | + - "<Clear-data E2E pass conditions in verification environment + evidence archived to features/<feature_key>/E2E_RUN_REPORT.md and features/<feature_key>/STATE.md>" |
| 178 | + - "<(Frontend only) Chrome DevTools: console 0 error AND network 0 failure>" |
| 179 | +``` |
0 commit comments