82 lines
2.9 KiB
Markdown
82 lines
2.9 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
|
|
|
|
- Write prompts in English by default for GitHub Copilot and other development-machine AI tools unless the user explicitly asks for another language.
|
|
- Prefer first-person phrasing when drafting a prompt the user will paste directly into another AI tool, unless the user asks for a different voice.
|
|
- Keep prompts concise by default; include only the context needed for correct execution.
|
|
- In follow-up prompts to the same AI session, do not restate completed work or who performed it unless that detail is needed for the next step.
|
|
- 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."
|