feat: Add story draft command and prompt for Jira-ready proposals with clear requirements

.opencode/commands/story-draft.md

@@ -0,0 +1,60 @@
+---
+description: Draft a Jira story proposal with Fidelity-ready context and acceptance criteria
+---
+
+Draft a future Jira story from rough notes, findings, or follow-up ideas.
+
+This command should optimize for:
+
+- professional story wording
+- explicit scope
+- useful acceptance criteria
+- clear ownership framing
+- natural US English that Jeff can reuse or forward without rewriting
+
+Input notes or rough idea:
+
+$ARGUMENTS
+
+Read:
+
+@prompts/story-draft.md
+@ai/AGENTS.md
+@ai/context/project.md
+@ai/context/people/manager.md
+@ai/context/people/jeff-dewitte.md
+@ai/context/people/index.md
+@ai/state/current.md
+@ai/state/work-items.md
+@knowledge/communication-rules.md
+@knowledge/agent-memory-rules.md
+
+Today's log, if present:
+
+!`if [ -f ai/logs/$(date +%F).md ]; then cat ai/logs/$(date +%F).md; else echo "No log exists for today yet."; fi`
+
+Latest Mattermost context, if available:
+
+!`if [ -s ai/inbox/mattermost-latest.md ]; then cat ai/inbox/mattermost-latest.md; elif [ -s scripts/mattermost/generated/mattermost_context.jsonl ]; then cat scripts/mattermost/generated/mattermost_context.jsonl; else echo "No Mattermost context available."; fi`
+
+Requirements:
+
+- Preserve the exact technical meaning of the input
+- Rewrite fully when needed so the output sounds like a fluent senior engineer wrote it
+- Choose the most appropriate story framing: bug, enhancement, spike, task, or follow-up
+- Keep the title short, concrete, and Jira-ready
+- Make the description specific enough that another engineer can understand the intended work
+- Separate current problem, root-cause suspicion, workaround, and follow-up work when relevant
+- Do not overstate certainty; if something is still a hypothesis, label it clearly
+- Make ownership explicit when helpful: XFlow vs consumer app vs service/configuration vs other framework
+- Acceptance criteria should be testable and scoped to the proposed story
+- If the story looks too large or too ambiguous, say so explicitly and suggest spike framing instead
+- If useful, include a short note about dependencies, blockers, or coordination needed
+
+Return:
+
+1. Suggested story type
+2. Jira-ready title
+3. Description
+4. Acceptance criteria
+5. Optional notes on dependencies / blockers / sizing concerns

ai/logs/2026-04-09.md

@@ -41,3 +41,11 @@
 ## Next Step
 
 - Keep using explicit issue framing for future Mattermost and Jira updates
+
+---
+
+## Workflow Clarification
+
+- This workspace is mainly used off the Fidelity work machine
+- Main practical use cases are: drafting Mattermost updates to Jeff, translating/refining English, reusing prior context, getting Swift technical support, and drafting PR/story text
+- Recommendations for new commands should prioritize communication support and context reuse over heavy local triage workflows that assume direct access to the product environment

prompts/story-draft.md

@@ -0,0 +1,33 @@
+# Story Draft Prompt
+
+Draft Jira-ready story proposals for Fidelity work.
+
+The goal is not just to rephrase notes, but to turn them into work items another engineer, manager, or scrum contact can understand quickly.
+
+Requirements:
+
+- Write in natural, professional US English
+- Preserve exact technical meaning
+- Prefer explicit scope over broad or vague framing
+- Use bug / enhancement / spike / task language accurately
+- Keep titles concise and concrete
+- Separate these when relevant:
+  - current issue
+  - suspected root cause
+  - workaround
+  - follow-up work
+- If the notes describe a consumer issue that likely belongs outside XFlow, make that visible in the notes instead of hiding it
+- If the request is too ambiguous or too large, recommend turning it into a spike
+
+Acceptance criteria guidance:
+
+- Make ACs observable and testable
+- Do not include implementation details unless they are central to scope
+- Prefer behavior-based acceptance criteria over code-structure criteria
+- If risk of regression matters, include a regression-safety criterion
+
+Useful output qualities:
+
+- Jeff should be able to forward or paste it with little or no rewriting
+- Quy or another scrum/contact person should be able to create the story from it directly
+- Another engineer should understand what success looks like