2.7 KiB
description
| 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 the current manager or stakeholder can reuse or forward without rewriting
Input notes or rough idea:
$ARGUMENTS
Read:
@prompts/story-draft.md @ai/AGENTS.md @ai/context/index.md @ai/context/project.md @ai/context/workstreams/index.md @ai/context/process/communication.md @ai/context/process/jira-story-rules.md @ai/context/people/manager.md @ai/context/people/index.md @ai/work-items/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
Detailed active work item files, if available:
!if [ -d ai/work-items ]; then for f in ai/work-items/*.md; do case "$f" in *README.md|*index.md) continue;; esac; echo "\n### $f"; cat "$f"; done; else echo "No work item files 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
- If the story touches consumer validation or release propagation, reflect that explicitly in the description or notes
Return:
- Suggested story type
- Jira-ready title
- Description
- Acceptance criteria
- Optional notes on dependencies / blockers / sizing concerns