david.delagneau
dbc1894e27
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People." - Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views. - Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation. - Updated scripts and prompts to reflect the new project-knowledge directory structure. - Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps. - Ensured all references in workflows and scripts point to the new project-knowledge paths.
78 lines
2.4 KiB
Markdown
78 lines
2.4 KiB
Markdown
---
|
|
type: agent-workflow
|
|
status: active
|
|
updated: 2026-04-17
|
|
tags:
|
|
- process
|
|
- ai-prompting
|
|
---
|
|
# 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."
|