chore: remove compatibility field from various agent rules for consistency
This commit is contained in:
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
@@ -25,4 +24,3 @@ Use this skill when the user wants a prompt for another AI assistant, coding age
|
||||
- Prefer clear sections over long prose.
|
||||
- Include work-item ID and title when relevant.
|
||||
- Make assumptions explicit.
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
@@ -23,4 +22,3 @@ Use this skill for manager updates, stakeholder messages, translations, issue cl
|
||||
- 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.
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
@@ -24,4 +23,3 @@ Use this skill for standups, daily scrum updates, end-of-day summaries, and shor
|
||||
- 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.
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
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: ""
|
||||
---
|
||||
@@ -24,4 +23,3 @@ Use this skill when new information may change workspace memory, project state,
|
||||
- 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.
|
||||
|
||||
|
||||
20
GEMINI.md
20
GEMINI.md
@@ -7,8 +7,6 @@ Shared rules and context already live in the normal workspace files. Do not dupl
|
||||
Read these first:
|
||||
|
||||
@./AGENTS.md
|
||||
@./README.md
|
||||
@./agent-memory/README.md
|
||||
@./project-knowledge/00-start/start-here.md
|
||||
@./project-knowledge/01-current/current-work.md
|
||||
@./project-knowledge/01-current/work-items.md
|
||||
@@ -22,16 +20,10 @@ Read these first:
|
||||
- `project-knowledge/` is canonical project memory.
|
||||
- `agent-memory/` is agent operating memory.
|
||||
|
||||
## Gemini-Specific Mandatory Loop (Real-Time Auto-Documentation)
|
||||
## Gemini-Specific Operating Notes
|
||||
|
||||
At the end of EVERY conversational turn, you MUST evaluate the interaction as a senior Obsidian documentation expert:
|
||||
|
||||
1. **Analyze for Memory Impact:** Did the user's prompt or your subsequent action reveal new technical context, resolve an open question, change an architectural assumption, or shift current priorities?
|
||||
2. **Identify Target Canonical Files:** If memory impact is detected, identify WHERE in the `project-knowledge/` directory this information belongs. This is NOT limited to daily logs. It could be:
|
||||
- `01-current/current-work.md` (priority shifts, new blockers)
|
||||
- `02-work-items/*.md` (story updates, bug reproduction steps)
|
||||
- `03-context/` (system architecture, processes, workflows)
|
||||
- `04-people/` (stakeholder involvement)
|
||||
- `06-daily/YYYY-MM-DD.md` (daily findings)
|
||||
3. **Proactive Update:** You MUST use your file editing tools (`replace_file_content` / `multi_replace_file_content`) to inject the new context or CORRECT existing stale context in the appropriate files BEFORE concluding your response.
|
||||
4. **No Explicit Prompt Needed:** Do not wait for the user to say "document this". Auto-document implicitly. Ensure you do not pollute the workspace with unverified guesses; only document confirmed context or active hypotheses.
|
||||
- Keep the hot context small and load additional files lazily based on the active task.
|
||||
- Follow `AGENTS.md` as the shared source of truth for answer-first behavior, memory promotion, and lazy loading.
|
||||
- For analysis, review, translation, or drafting prompts, answer first and persist second unless saving the fact is clearly required to produce a safe answer.
|
||||
- Do not create new canonical notes in the critical path of a simple answer unless the user explicitly asked to save the information or the destination is obvious and non-blocking.
|
||||
- When memory should be updated, prefer the smallest correct change to `project-knowledge/` and avoid duplicating stale and corrected versions.
|
||||
|
||||
Reference in New Issue
Block a user