feat: add comprehensive agent rules and workflows for memory curation, communication synchronization, and project documentation management
This commit is contained in:
@@ -1,31 +0,0 @@
|
||||
---
|
||||
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
|
||||
---
|
||||
|
||||
## 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.
|
||||
1
.opencode/skills/swiftui-xflow-review/SKILL.md
Symbolic link
1
.opencode/skills/swiftui-xflow-review/SKILL.md
Symbolic link
@@ -0,0 +1 @@
|
||||
../../../.agents/rules/swiftui-xflow-review.md
|
||||
Reference in New Issue
Block a user