feat: add comprehensive agent rules and workflows for memory curation, communication synchronization, and project documentation management

.agents/workflows/story-draft.md

@@ -0,0 +1,67 @@
+---
+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:
+
+@core/README.md
+@core/memory/operational-memory.md
+@prompts/story-draft.md
+@project-knowledge/01-current/current-work.md
+@project-knowledge/01-current/work-items.md
+@project-knowledge/03-context/project.md
+@project-knowledge/03-context/workstreams/index.md
+@project-knowledge/03-context/process/communication.md
+@project-knowledge/03-context/process/jira-story-rules.md
+@project-knowledge/04-people/manager.md
+@project-knowledge/04-people/index.md
+
+Today's log, if present:
+
+!`if [ -f project-knowledge/06-daily/$(date +%F).md ]; then cat project-knowledge/06-daily/$(date +%F).md; else echo "No daily note 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 project-knowledge/02-work-items ]; then for f in project-knowledge/02-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:
+
+- Use `professional-communication` when available.
+- 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:
+
+1. Suggested story type
+2. Jira-ready title
+3. Description
+4. Acceptance criteria
+5. Optional notes on dependencies / blockers / sizing concerns