feat: Enhance AI prompting capabilities with new guidelines and templates for GitHub Copilot
This commit is contained in:
@@ -64,6 +64,7 @@ When drafting messages for a manager or stakeholder:
|
||||
- Before answering prompts about current work, verify `ai/state/current.md` and the latest relevant log in `ai/logs/`
|
||||
- Before answering architecture, process, or historical questions, check the relevant file under `ai/context/systems/`, `ai/context/workstreams/`, or `ai/context/process/`
|
||||
- Before answering Swift, SwiftUI, iOS architecture, testing, or debugging questions, check `ai/context/ios/` and use the project-local iOS skills when available
|
||||
- Before generating a prompt for another AI or GitHub Copilot, check `ai/context/process/ai-to-ai-prompting.md` and make the prompt self-contained
|
||||
- If `ai/inbox/mattermost-latest.md` exists, check it before answering prompts about current status, standups, or supervisor communication
|
||||
- Treat all meaningful user prompts as potential memory updates, not only explicit sync commands
|
||||
- If a Mattermost sync or other context-ingestion step fails, do not update `ai/logs/`, `ai/state/`, or stable context files based on that failure
|
||||
@@ -80,6 +81,7 @@ When drafting messages for a manager or stakeholder:
|
||||
- Prefer updating stable project context over appending generic operational summaries
|
||||
- Do not create daily log entries for tooling activity, sync status, or generic chat noise
|
||||
- For Swift/iOS best-practice answers, distinguish current Apple guidance from project-safe recommendations when Fidelity constraints may change the answer
|
||||
- For Copilot prompts, include only relevant context, tell Copilot what to inspect, and state constraints, non-goals, expected output, and validation
|
||||
- Do not ask the user what should be promoted after a successful sync unless multiple conflicting interpretations are equally plausible
|
||||
- When the user shares relevant new information, update today's log if the information belongs to the daily record
|
||||
- When the user corrects or changes stable context, update the canonical file directly:
|
||||
|
||||
69
ai/context/process/ai-to-ai-prompting.md
Normal file
69
ai/context/process/ai-to-ai-prompting.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# AI-To-AI Prompting
|
||||
|
||||
## Goal
|
||||
|
||||
Generate prompts that can be sent to another AI assistant on the Fidelity development machine, especially GitHub Copilot.
|
||||
|
||||
---
|
||||
|
||||
## Operating Assumption
|
||||
|
||||
This workspace does not contain the product codebase. The target AI has access to the Fidelity codebase on another machine.
|
||||
|
||||
Therefore prompts must:
|
||||
|
||||
- include only the relevant project context from this workspace
|
||||
- tell the target AI what files/modules to inspect
|
||||
- ask for a concrete output
|
||||
- specify constraints and non-goals
|
||||
- avoid pretending the target AI already has this workspace memory
|
||||
|
||||
---
|
||||
|
||||
## Prompt Structure
|
||||
|
||||
Use this structure by default:
|
||||
|
||||
1. Role
|
||||
2. Project context
|
||||
3. Current task
|
||||
4. Relevant ticket/context
|
||||
5. Files/modules to inspect
|
||||
6. Constraints
|
||||
7. Expected output
|
||||
8. Validation requirements
|
||||
|
||||
---
|
||||
|
||||
## Prompt Quality Rules
|
||||
|
||||
- Prefer precise task framing over long background dumps.
|
||||
- Include Jira ID and title when the work maps to a ticket.
|
||||
- Include current constraints such as REST feature flag, GraphQL fallback, auth state, backend-driven behavior, and consumer validation when relevant.
|
||||
- Ask the target AI to inspect code before proposing changes.
|
||||
- Ask for a plan first when the implementation scope is uncertain.
|
||||
- Ask for code changes only when the desired write scope is clear.
|
||||
- Include "Do not assume REST is active by default" for REST migration tasks.
|
||||
- Include "Separate external issue from regression" for AO/Discourse issues.
|
||||
- Include "Validate against Fid4/consumer path when needed" for XFlow integration tasks.
|
||||
|
||||
---
|
||||
|
||||
## Bad Prompt Pattern
|
||||
|
||||
"Fix this issue in XFlow."
|
||||
|
||||
Why bad:
|
||||
|
||||
- no entry point
|
||||
- no auth state
|
||||
- no expected behavior
|
||||
- no ticket context
|
||||
- no validation path
|
||||
- no scope boundary
|
||||
|
||||
---
|
||||
|
||||
## Good Prompt Pattern
|
||||
|
||||
"You are working in the Fidelity iOS codebase. Inspect the XFlowSDK and XFlowViewMaker integration path for `PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`. First identify where XFlow currently exposes SwiftUI through `UIHostingController`, where XFlowViewMaker consumes it, and what feature flag protects the migration path. Do not change code yet. Return a concise plan with affected files, risks, consumer validation needs in Fid4/FTTransfer, and any questions that block implementation."
|
||||
@@ -5,6 +5,9 @@
|
||||
- [communication.md](./communication.md)
|
||||
How to frame technical updates and external communication.
|
||||
|
||||
- [ai-to-ai-prompting.md](./ai-to-ai-prompting.md)
|
||||
How to generate prompts for GitHub Copilot or another AI on the Fidelity development machine.
|
||||
|
||||
- [jira-story-rules.md](./jira-story-rules.md)
|
||||
How to create or reference stories with the right scope and precision.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user