Compose and create the issue. Title: action-oriented and specific — Implement: <feature> for features, Fix: <symptom> for bugs. When the brief names a handoff file (a — brief: <path> suffix from om-brainstorm), embed its content — problem, agreed direction, resolved unknowns, non-goals — in the body sections below: the tracker copy is the durable one, and the issue must never depend on the local file. Body:
## Summary
- {one-line goal from the brief}
- Problem: {what hurts, or what is missing}
- Who has it: {user or role}
- Expected outcome: {what is true afterwards, and how it will be checked}
## Spec
- Implementation spec: `{spec path}` ({link}) <!-- when step 2 found one, or step 3 authored one (also note the spec PR #) -->
## Analysis <!-- only when no spec covers it -->
- Affected areas: {modules/files}
- {expected vs actual, root-cause hypothesis for bugs}
## How to implement
1. {concrete step — file/function level}
2. {concrete step}
3. {tests to add and where}
## Compatibility notes
- {None | protected surfaces touched and the required migration path per BACKWARD_COMPATIBILITY.md}
## How to pick this up
- Run `om-auto-fix-issue {thisIssueNumber}` (it handles both bugs and features), or hand the spec/analysis to `om-auto-create-pr` as the brief. When step 3 authored a spec PR, implement with `om-auto-implement-spec {specPrNumber}` or `om-auto-fix-issue {thisIssueNumber}` — the spec PR stays design-only; implementation ships on its own PR referencing it.
## Out of scope
- {non-goals, so the implementer does not gold-plate}
## Open questions
- {question} — blocking | non-blocking <!-- or: none -->
The Summary, Out of scope, and Open questions sections are the ticket-level tier of the Definition of Ready in SDLC.md; fill them from the brief and, when ${SPECS_DIR}/product-brief.md exists (written by om-discover), from its Problems, Target group, Goals, Non-goals, and Open questions — cite the brief's ids (D03, N01) where a decision or non-goal bounds the ticket. Never invent a problem or a user that neither names — write "unknown" and mark the question blocking instead.
Create it via create-issue with title, body, --assignee when passed, and the SDLC labels through the guards (a missing label degrades to a logged skip; labels.enabled: false skips all):
- One category label the brief clearly is:
feature, bug, refactor, security, dependencies, or documentation.
- Exactly one priority label and exactly one risk label, inferred from the brief per the inference rules in
SDLC.md (its "When no priority label is set" / "When no risk label is set" lists) — --priority / --risk override the inference when passed.
- Never pipeline labels (
review, qa, merge-queue, …) — those are PR-only. Never in-progress — nothing is being worked on.
- After applying the label set, make the classification auditable per
SDLC.md with one consolidated 🤖 `om-prepare-issue` — 🏷️ label rationale comment (or an equivalent section in the body): one label per line with its emoji (🐛 bug · ✨ feature · 🔥/🔺/🔹/🔽 priority-* · ⚠️/🟡/🟢 risk-*) and a full-sentence reason — never one comment per label.
Attach image evidence. When the user provided images with the brief (pasted screenshots or file paths), upload them via the tracker operation attach-image-evidence when the installed descriptor defines it, and embed the returned URLs in a ## 📸 Evidence section of the issue body (or a follow-up comment-issue with a one-line caption per image when the issue was already created). Save pasted images to a temp file first so the operation has a path. When the descriptor lacks the operation or the upload fails, degrade gracefully: reference the local paths/filenames in the body and note that inline upload was unavailable — never fail the issue creation over evidence.
