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

.agents/rules/ai-prompt-engineering.md

@@ -0,0 +1,28 @@
+---
+name: ai-prompt-engineering
+description: Create self-contained prompts for another AI assistant that lacks access to this workspace memory.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill when the user wants a prompt for another AI assistant, coding agent, review tool, or implementation environment.
+
+## Workflow
+
+1. Identify target task type: investigation, implementation, review, testing, debugging, or documentation.
+2. Pull only relevant workspace context.
+3. Make the prompt self-contained.
+4. Tell the target AI what to inspect before acting.
+5. State constraints, non-goals, expected output, and validation expectations.
+6. Avoid invented file paths when the implementation repository is not available.
+
+## Output Rules
+
+- Return only the prompt unless the user asks for commentary.
+- Prefer clear sections over long prose.
+- Include work-item ID and title when relevant.
+- Make assumptions explicit.
+

.agents/rules/copilot-prompt-engineering.md

@@ -0,0 +1,49 @@
+---
+name: copilot-prompt-engineering
+description: Create high-quality prompts for GitHub Copilot or another AI running on the Fidelity development machine, using this workspace's context without assuming the target AI has access to it.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill when the user wants a prompt for another AI assistant, GitHub Copilot, or the Fidelity development machine.
+
+## Workflow
+
+1. Identify the target task type:
+   - investigation
+   - implementation plan
+   - code change
+   - review
+   - test strategy
+   - story/PR drafting
+2. Pull only the relevant context:
+   - `project-knowledge/02-work-items/` for ticket-specific context
+   - `project-knowledge/03-context/systems/` for component context
+   - `project-knowledge/03-context/workstreams/` for recurring constraints
+   - `project-knowledge/03-context/ios/` for Swift/iOS guidance
+3. Make the prompt self-contained.
+4. Tell the target AI what to inspect before acting.
+5. State constraints, non-goals, and validation expectations.
+
+## Fidelity Prompting Rules
+
+- Write the final prompt in English unless the user explicitly requests another language.
+- Default to first-person wording so the user can paste the prompt directly into Copilot.
+- Keep the prompt short unless the user asks for more detail.
+- For follow-up prompts in the same AI session, assume recent shared context and avoid repeating which side made the previous changes unless it matters for the task.
+- Include Jira ID and approved title when available.
+- For REST work, say REST is behind a feature flag and GraphQL is fallback unless confirmed otherwise.
+- For XFlow work, say behavior may depend on entry point, auth state, backend config, and consumer integration.
+- For AO/Discourse issues, say external report vs regression must be separated.
+- For SwiftUI/XFlow work, mention lifecycle, modal presentation, UIKit bridge, feature flag, and Fid4 validation if relevant.
+
+## Output Rules
+
+- Return only the prompt unless the user asks for explanation.
+- Keep the prompt concise but complete.
+- Prefer sections over paragraphs.
+- Do not invent file paths unless the workspace context explicitly names them.
+- If exact files are unknown, ask Copilot to locate them first.

.agents/rules/ios-swift-answering.md

@@ -0,0 +1,30 @@
+---
+name: ios-swift-answering
+description: Answer Swift, SwiftUI, and iOS programming questions using current Apple guidance while adapting recommendations to Fidelity/XFlow project constraints.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill for Swift, SwiftUI, iOS architecture, concurrency, testing, or debugging questions.
+
+## Workflow
+
+1. Identify whether the question is general Swift/iOS or Fidelity-specific.
+2. Read `project-knowledge/03-context/ios/current-practices.md` for currentness rules.
+3. Read `project-knowledge/03-context/ios/project-swift-guidance.md` when the answer may affect XFlow, Fid4, XFlowViewMaker, FTFrameworks, feature flags, or consumer validation.
+4. If the answer depends on current Apple APIs, Xcode versions, dependency tooling, package-manager behavior, testing frameworks, or migration guidance, verify with official/primary documentation before making strong claims.
+5. Separate:
+   - current best practice
+   - project-safe recommendation
+   - assumptions to confirm
+
+## Output Rules
+
+- Be direct and senior-engineer practical.
+- Avoid generic architecture advice when project constraints matter.
+- Do not assume deployment target, Xcode version, or framework migration status.
+- Do not characterize CocoaPods, SPM, podspec repos, trunk/CDN behavior, CI/build behavior, or testing framework practices as good or bad practice without corroborating current primary docs when the recommendation matters.
+- Mention tradeoffs and validation path when relevant.

.agents/rules/ios-testing-strategy.md

@@ -0,0 +1,36 @@
+---
+name: ios-testing-strategy
+description: Recommend iOS testing approaches for Swift, SwiftUI, XFlow, Fid4, and REST migration work while respecting existing XCTest/Swift Testing/project constraints.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill for unit tests, UI tests, integration tests, regression coverage, XFlow flow validation, or REST/GraphQL migration testing questions.
+
+## Workflow
+
+1. Identify the behavior under test.
+2. Classify the test level:
+   - unit
+   - integration
+   - UI / consumer flow
+   - exploratory validation
+3. Check whether the behavior depends on backend configuration, auth state, entry point, feature flags, or Fid4 integration.
+4. Prefer the test framework already used by the project unless the user asks about migration.
+5. If suggesting Swift Testing, confirm Xcode/project support first and do not mix APIs inside the same test.
+
+## Project-Specific Guidance
+
+- XFlow behavior may require exploratory validation beyond unit tests.
+- AO/Discourse issues often need auth-state and entry-point coverage.
+- REST migration tests must distinguish REST path from GraphQL fallback.
+- Consumer-facing changes may require Fid4 validation even when SDK tests pass.
+
+## Output Rules
+
+- Recommend the smallest useful test strategy.
+- Include what cannot be proven by that test layer.
+- Mention manual/exploratory validation when code-level tests are insufficient.

.agents/rules/professional-communication.md

@@ -0,0 +1,26 @@
+---
+name: professional-communication
+description: Rewrite rough technical notes into clear, concise, stakeholder-ready professional English while preserving scope and technical meaning.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill for manager updates, stakeholder messages, translations, issue clarification, Jira comments, and communication polishing.
+
+## Workflow
+
+1. Identify audience, purpose, scope, and requested action.
+2. Preserve technical meaning and uncertainty.
+3. Make ownership, reproducibility, environment, and next action explicit when relevant.
+4. Use Context, Observation, Action when it improves readability.
+5. Avoid vague comparisons and generic progress language.
+
+## Output Rules
+
+- Write natural professional US English.
+- Keep messages concise enough for workplace chat unless the user asks for a longer document.
+- Do not invent facts, evidence, or commitments.
+

.agents/rules/status-reporting.md

@@ -0,0 +1,27 @@
+---
+name: status-reporting
+description: Generate work-item-aware standups and status summaries from current workspace memory, recent logs, and communication evidence.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill for standups, daily scrum updates, end-of-day summaries, and short progress reports.
+
+## Workflow
+
+1. Read current state, active work items, recent logs, and latest communication evidence.
+2. Use the previous workday as the default source for "Yesterday" style updates.
+3. Group updates by work item when possible.
+4. If one work item has multiple concrete updates, use one top-level work-item bullet with indented markdown sub-bullets.
+5. Exclude side chatter unless it changed work scope, priority, risk, or blockers.
+
+## Output Rules
+
+- Use explicit work-item ID and title when available.
+- Keep the report concise and ready to send.
+- Do not mention internal evidence sources unless the user asks.
+- Use `Blockers: None` only when no blocker is visible in current memory.
+

.agents/rules/swiftui-xflow-review.md

@@ -0,0 +1,33 @@
+---
+name: swiftui-xflow-review
+description: Review or reason about SwiftUI code in XFlow/Fidelity contexts, especially lifecycle, modal presentation, navigation, backend-driven UI, and UIKit bridge removal.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill when a SwiftUI question touches XFlow, Fid4, XFlowViewMaker, modal presentation, dismissal sequencing, navigation, `UIHostingController`, or backend-driven UI behavior.
+
+## Review Heuristics
+
+- Check whether behavior is driven by backend configuration before blaming local SwiftUI code.
+- Identify data ownership and view lifecycle boundaries.
+- Treat dismissal sequencing as high risk when delegate callbacks, `onDisappear`, or upstream state changes are involved.
+- Treat UIKit bridge removal as rollout-sensitive, not just cleanup.
+- Separate SwiftUI best practice from Fidelity-safe migration strategy.
+
+## Fidelity-Specific Checks
+
+- Does the change preserve UIKit/SwiftUI parity?
+- Does it require a feature flag?
+- Does it need validation in Fid4 or only XFlowSDK?
+- Could XFlowViewMaker or FTFrameworks block consumer visibility?
+- Is the issue external behavior, existing behavior, or a regression?
+
+## Output Rules
+
+- Provide a clear recommendation.
+- Include risks and validation path.
+- Avoid recommending a pure SwiftUI approach without noting rollout and consumer validation impact.

.agents/rules/workspace-memory-curation.md

@@ -0,0 +1,27 @@
+---
+name: workspace-memory-curation
+description: Maintain file-based operational memory by deciding what to log, promote, correct, or route into tool behavior across reusable AI workspaces.
+compatibility: opencode
+trigger: always_on
+glob: ""
+---
+
+## When To Use
+
+Use this skill when new information may change workspace memory, project state, work-item context, people context, decisions, or reusable agent/tool behavior.
+
+## Workflow
+
+1. Read `core/memory/operational-memory.md`.
+2. Classify the information as daily, state, work-item, stable-context, people, decision, or tooling-behavior.
+3. Update the smallest correct canonical file.
+4. If new information corrects older memory, replace or refine the stale statement instead of appending a contradiction.
+5. If a correction affects future output, update the command, prompt, agent, skill, or knowledge file that controls that behavior.
+6. Keep imported evidence separate from promoted memory.
+
+## Output Rules
+
+- Report updated files and the memory change.
+- Preserve uncertainty when confidence is mixed.
+- Do not promote tool failures, sync noise, or generic chat chatter as project facts.
+